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

Тема в разделе "WASM.ASSEMBLER", создана пользователем Mika0x65, 17 ноя 2009.

  1. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    Мое почтение всем.

    Дописываю (вроде бы) дизассемблер. Появился такой вопрос. В выходную информацию помещается ID инструкции, но пока нет размера операции самой инструкции. Поясню: т.к. операнды могут быть разных размеров, информация о размере операнда сохраняется в выходной структуре операнда. В инструкции он, вроде как и не нужен. Однако, есть инструкции без операндов, размер которых все же важно знать. Например, pushf{w|d|q}, pusha{d}, c{bw|wde|dqe}, стринговые инструкции. Как по-вашему правильнее сделать -- выразить размер неявного операнда с помощью ID инструкции, т.е. появятся ID_PUSHFW, ID_PUSHFD, ID_PUSHFQ или же иметь только один ID_PUSHF и поле 'opsize' в выходной структуре инструкции? Я больше склоняюсь ко второму варианту, т.к. он более универсален, но хочется услышать vox populi.

    Заранее благодарен.
     
  2. Mikl___

    Mikl___ Супермодератор Команда форума

    Публикаций:
    14
    Регистрация:
    25 июн 2008
    Сообщения:
    3.787
    Mika0x65
    На сколько я помню PUSHA, PUSHAD и PUSHAW – это одна и та же команда с кодом 60h. В зависимости от текущего режима (16- или 32-разрядного) компилятор вме­сто команды PUSHA подставит либо команду PUSHAD, либо команду PUSHAW. Команды PUSHAD и PUSHAW в зависимости от текущего ре­жима будут предваряться или нет префиксом изменения разрядности опе­рандов (66h). TASM, в отличие от MASM, различает PUSHFD/PUSHFW и POPFD/POPFW. В MASM'е нет команд PUSHFW и POPFW и 32/16-разряд­ные различия между командами PUSHFD/PUSHF и POPFD/POPF.
    инструкция режим use16 use32
    PUSHA PUSHAD 6660h 60h
    PUSHAW 60h 6660h
    POPA POPAD 6661h 61h
    POPAW 61h 6661h
    PUSHFD 669Ch 9Ch
    PUSHF/PUSHFW 9Ch 669Ch
    POPFD 669Dh 9Dh
    POPF/POPFW 9Dh 669Dh
     
  3. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    Mikl___
    Да, при определении размера операндов я учитываю наличие префиксов и выбранный режим дизассемблирования. Но вопрос не в этом -- меня интересует, как лучше будет выдавать результат: как ID_PUSHF{X} и без размера операнда, или же с как ID_PUSHF с размером операнда.
     
  4. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    ну если результат в структуре и в ней есть поле размера операнда, то было бы логично устанавливать его для каждой команды без исключений
     
  5. Mikl___

    Mikl___ Супермодератор Команда форума

    Публикаций:
    14
    Регистрация:
    25 июн 2008
    Сообщения:
    3.787
    Mika0x65
    Наверное стоит указывать размер PUSHFW/PUSHFD/PUSHFD а в случае с инструкциями c{bw|wde|dqe} указывать объязательно, но это всё IMHO
     
  6. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    qqwe
    Пока что его нет :). Поэтому и спрашиваю, какой вариант лучше.
     
  7. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    ну так сделайте раз такой вопрос встал. всегда лучше решать вопросы глобально, а не в виде кучи исключений и заплаток. тем более, что есть еще и 64, а может и до 128 доживем
     
  8. Mikl___

    Mikl___ Супермодератор Команда форума

    Публикаций:
    14
    Регистрация:
    25 июн 2008
    Сообщения:
    3.787
    qqwe
    пока выйдет 128 разрядов M$oft изымет все упоминания об ассемблере из нета и библиотек как еретические :)
     
  9. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    qqwe
    Я стараюсь экономить в выходной инструкции. Но, похоже, struct INSTRUCTION::opsize таки появится :).
     
  10. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    о.. вы пишете на цпп.. не знал

    вообще, для начала надо сгенерировать условия достаточности вывода. возможно и обсудить его формат. те, если вы сэкономите на какомто флаге - будущим пользователям вашей либы придется каждый раз напрягаться с расшифровкой результатов
     
  11. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    qqwe
    Не на С++, на С.

    Вообще, я стараюсь найти золотую середину, если можно так сказать. Правда, таблицы получились довольно громоздкие, но переделывать уже вряд ли буду.
     
  12. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    Mikl___
    мсофт после-хп-шными фантазиями изрядно подгадили себе рынок. а попытками ограничить нетом разрабов в выборе платформы - и того больше (жадность фраера сгубила). все больше серьезных пакетов портируется на линь, ато и изначально пишется под него, а потом уже портируется на вынь. в настоящее время основное в чем линь уступает выни это дх. как только под линь появится нормальная библиотека для работы с гпу/3д ускорением основной поток пользователей выни - геймеры начнет редеть.

    ну и армы уже догоняют х86 архитектуру и скоро начнут перегонять. один только список производителей, инсталяций и выбор накристальных комплектностей чего стоит
     
  13. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    Mika0x65
    если вы планируете заопенсорсить, то это логический момент чтоб выложить все в инет на свн/хг с открытым доступом, набрать комитчиков и разрешить присылать диффы, как это обычно и делают
    пример
    http://www.lua.org/bugs.html
     
  14. cppasm

    cppasm New Member

    Публикаций:
    0
    Регистрация:
    18 июл 2006
    Сообщения:
    923
    Основное чем уступает Линь - отсутствие бинарной совместимости.
    А собирать всё из исходников или лить из репозитариев не многих впечатляет.

    Это по каким интересно параметрам (ассемблер там прикольный :) )?
    ARM хорошая архитектура для своих применений, но сравнивать с х86...
    ARM11 - up to 740 Dhrystone MIPS
    Intel Core2 Duo - Dhrystone ALU score of 24465 MIPS (без учёта SIMD)
    Оно и видно, почти догнал :)
     
  15. Mika0x65

    Mika0x65 New Member

    Публикаций:
    0
    Регистрация:
    30 июл 2005
    Сообщения:
    1.384
    qqwe
    Да, удет OpenSourcem но надо еще кое-что доделать. Пока что очень сыро, поэтому выкладываю "по-тихому". Т.е. есть еще известные мне ошибки, которые надо поправить. Например, те же инструкции с неявными операндами. Если интересно, могу скинуть в личку исходники.
     
  16. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    Mika0x65
    лучше сделайте себе онлайн репу.
    например вот сдесь.
    чем именно тут хорошо - не публикуют дефолтом вашу репу.
    чем хорош хг - тем что полносью писан на питоне и каждый форк - полноценная репа. те очень удобно отводить ветви и если надо - собирать их

    да, ссыль на репу можете и пропостить. кто прочтет один кусочек, ктото другой. выскажутся. итд. а сырость, она всегда имеется. главное чтоб стиль не был совсем ужасным
     
  17. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    cppasm
    вообще то я сужу по приросту поддержки среди производителей и объему и разнообразию предложения. х86 уже давно не пытаются клонировать сторонние фирмы. зато какой спектр поддержки арм. как плат, так и камней разных производителей
    вплоть до полных компов с сопроцессорами, дсп, памятью и полной периферией на кристале. поставил такой один такой камень и достаточно.

    прикольный. особенно арм вариант

    х86 развивается с 72го года? а арм с 83. 10 лет опережения. а вспомните каким х86 был 10 лет назад

    производительность арма ограничена всвязи с требованием к микропотреблению. и может быть увеличена при отказе от него
    с другой стороны, популярность настольных рабочих станций падает. народ предпочитает гаджеты, которые в основном лепятся на армах. итд.
     
  18. cppasm

    cppasm New Member

    Публикаций:
    0
    Регистрация:
    18 июл 2006
    Сообщения:
    923
    Ясно. А я по производительности. Я и говорю что он хорош для своих применений.
    Его клонировать просто проще, вот и делают.
    Так эти 10 лет никуда не денутся, они будут всегда.

    В десктопах и ноутах ARM не будет ещё очень долго, а может и никогда не будет.
    А на встраиваемых устройствах никто и не спорит что у ARM преимущества есть.
     
  19. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    http://www.3dnews.ru/news/noutbuki_olpc_xo_2_protsessori_arm_vmesto_x86/
    вот и первые пташки. прикольно они с кнопками. я аж себе захотел. особенно если недорого

    cppasm
    основная масса покупателей - зеваки и дети. недаром скоро комп станет необязательной приставкой к видеокарте. поэтому хорошая 3д ускорительная либа просто необходима.
    в 95 году народ не хотел хавать вынь 95 изза проблем с запуском дос игрушек и тормозов на вынь игрушках.
    проблема была решена покупкой и внедрением гаме сдк (дх). сейчас это основное направление развития выни (посмотрите на прогресс разных подсистемах).
    обратите также внимание, что народ щас переходит на висту-7рку, в основном, ради доступа к последним дх. и мс это понимает, потому и делает ограничение по версии для последних дх
     
  20. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    cppasm
    прирост производительности х86 вызван требованиями производителей игрушек. с ростом распространенности игровых консолей на арме производительность выростет и на нем

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