Дизассемблер 3.

Это не полноценный ноут - в смысле он маленький очень, скорее нетбук.
Насчёт ОС они правильно подметили - невозможность поставить Окна покупателей не порадует.
Так и вижу как ребёнок сидит и Линукс инсталлит, потом конфиги правит, дрова пересобирает
А вот это

по моему ерунда.
Нафиг оно Microsoft надо?
Никто не будет портировать ОС на другую архитектуру ради того, что так захотелось какой-то компании...

 

cppasm

мс нужны деньги. и только. а детский обучающий комп - это они и есть. сама вынь - обучающе-игровая ось переросток

кроме того вынь се изначально пашет на арм. думаю, они порта дх хотят или еще чего

в современных дистрибах все это делается автоматом, а дрова под нот/нет это отдельная песня. и иногда их легче пересобрать, чем найти собранные, например при переходе с хом на про едишн той же версии выни.

 

Оно у них и так портировано.

 

Портировано что?
Win CE это всё-таки немного не то же самое что полноценная Windows XP.
Смотря для чего эти устройства в общем предназначены.
Если чтоб дети книжки с экрана читали и для пасьянсов - то там любой ОС хватит.
Для игрового ПК Win CE не хватит.
Или есть порт WinXP под ARM?
Где почитать можно если да?
Ходили слухи что они семёрку портируют.
Но это были только слухи - семёрки под ARM не будет.
http://itsecure.org.ua/news/2009-06-05-1788

Пересборка драйверов и правка их конфигов - нет.
Хорошо ещё если есть что пересобирать.

Согласен.
Какой процент от рынка будут составлять эти устройства? По-моему меньше 1%.
Мне что-то кажется что затраты на портирование и адаптацию не окупятся.
В общем я согласен с тем что написано в статье, на которую я выше ссылку дал.

 

такую тему похерили ((
а ведь тема была про третий дизассемблер

 

прицеплю, ато теряется вечно. а тут и темка подходящая.

 

Mika0x65

если дизасм для "полевых условий")) то лучше для каждой инструкции свой ID...
если по тексту вашего дизасма для каждой инструкции предусмотрен "opsize", то однозназно писать размер в структуру, так легче обрабатывать код и это сможет улучшить последующую обработку инструкции...

 

ид инструкции можно задавать как hash(lower(<общепринятое название инструкции>)). иногда может быть полезно

 

t00x
Не только для "полевых". Если, конечно, мы об одном и том же говорим . Скорее даже наоборот -- будет использоваться стационарно. Однако, это не значит, что я не стремлюсь к компактности.

qqwe
А когда такое может пригодиться?

В общем, большинством голосов добавлю поле opsize. Видимо, так удобнее.

 

Mika0x65

Хотелось бы выразить свое мнение по теме subj.

Как мне представляется, текущее состояние кодировки команд x86 является отражением более абстрактного уровня вида:

{Тип операции}{Операнд(ы)}{...etc}

Зачастую инженера докодировали команды так как им было удобнее (или были ограничены тем что уже было закодировано). Пример - инструкции из серии 0x0F или команды оптимизированные под EAX.

Так что вроде как Вы просто пишете отражение текущей кодировки как она есть без попытки обобщения?

Возможно поиграццо с битами: допустим 0x0100 - это PUSH, а биты 0-7 отведены под расширение - например 0x01 означает "FLAGS", etc.

Т.е. ВСЕ команды вида PUSH gs:[ebx*8] или же PUSHD будут иметь общий 0x0100.,,, как-то так...

 

PSR1257
Отчасти у меня так и работает: все команды 'push' имеют ID 'ID_PUSH' независимо от типа операндов. Т.е. ID_PUSH будет и у 'push eax' и у 'push edi' и у 'push [ebp + 0x8]'. 'pushf' можно назвать исключением. +есть понятие группы инструкций. 'pushf' входит в группы: 'GRP_GEN | GRP_STACK | GRP_FLGCTRL', а 'push' в группы 'GRP_GEN | GRP_STACK'.