Комментарии 8
Кстати, для написания декодеров был очень неплохой инструмент Machine Code Toolkit. Я на нем делал декоден ARM и еще одного 'экспериментального процессора.
К сожалению, он и язык, на котором он написан, последнее время не поддерживаются.
К сожалению, он и язык, на котором он написан, последнее время не поддерживаются.
Спасибо за ссылку! Уже не знаю почему, но я на проект NJ MCT в своих изысканиях не натыкался.
К сожалению, он и язык, на котором он написан, последнее время не поддерживаются.Как я понял, проект забросили где-то в 1998 году. По меркам работ про декодеры это не так уж давно. Вот то, что проект написан на ML — это препятствие (для меня) посерьёзнее. Но оно тоже преодолимое, приходилось иметь дело с разными «странными» языками, да простят меня адепты оных.
Я про NJ MCT узнал, когда работал в лаборатории Касперского, где пытались использовать сделанный на нем декомпилятор. Потом применил его в «Институте Точной Механики» в разработке модели своего процессора (вместе с SystemC).
ML — язык не сложный. Даже есть ветки, которые развиваются (PolyML, MosML). Но ими собирать MCT я не пробовал. С последней на 2008 год версией SML NJ он работал очень плохо, пришлось сильно допиливать и его и даже компилятор. Но потом им пользовались люди не знающие ML — C-шники и немного аппаратчики.
ML — язык не сложный. Даже есть ветки, которые развиваются (PolyML, MosML). Но ими собирать MCT я не пробовал. С последней на 2008 год версией SML NJ он работал очень плохо, пришлось сильно допиливать и его и даже компилятор. Но потом им пользовались люди не знающие ML — C-шники и немного аппаратчики.
теоретически еще можно llvm заюзать — там есть семейство классов, отвечающих не за llvm'ный ассемблер, а целефой.
Можно добавить то, что бинарную трансляцую очень часть используют эмуляторы различных консолей.
В том числе и самых допотопных, ибо даже на современном железе интерпретация консоли 20-30 летней давности может привести к лагам (к примеру некратная частота эмулируемого процессора по отношению к хосту может вести к рассинхрону).
В том числе и самых допотопных, ибо даже на современном железе интерпретация консоли 20-30 летней давности может привести к лагам (к примеру некратная частота эмулируемого процессора по отношению к хосту может вести к рассинхрону).
к примеру некратная частота эмулируемого процессора по отношению к хосту может вести к рассинхрону.
В таких случаях это означает, что исходные приложения были написаны с завязкой на определённые значения длительностей некоторых операций, т.н. «синхронизация на sleep'ах». В таком случае симулятор должен моделировать задержки ключевых операций достаточно точно, чтобы гостевое приложение «не заметило» обмана. Для создателя модели это часто превращается в жуткую мороку, т.к. подобные аспекты работы железа могут не быть отражены в спецификациях.
То, что модель — это интерпретатор или ДТ, в принципе не определяет того, будут лаги или нет. Симулируемое время и время реальное связаны с друг другом только одним фактом: они оба монотонно возрастают. При условии, что симулятор написан честно и сам не использует «синхронизацию на sleep'ах».
В целом есть такой принцип: «корректные программы легко симулировать» — если ПО написано только на основе спецификаций, не использует информацию о длительностях операций и т.п., то внутри симулятора оно будет работать правильно.
Тема необходимости функциональных симуляторов не раскрыта. Я вот не очень представляю, кому они могут быть полезны. Вот к cycle-accurate симуляторам вопросов у меня нет — там тебе и сайд-эффекты от промахов кэша, и от неправильно предсказанных переходов, и от латентности памяти. Вот это симуляторы так симуляторы. Если они еще и работают хотя бы порядка на три быстрее, чем RTL-симуляторы, то цены им нет! А функциональные симуляторы — так, баловство (имхо, разумеется).
>> Тема необходимости функциональных симуляторов не раскрыта.
Хороший вопрос. Одна из областей их использования — разработка ПО до доступности железа, а точнее, совместная разработка (software/hardware codevelopment). Например, запуск Андроида для ARM с помощью SDK от Google на обыкновенном ПК c процессором IA-32 — это использование симуляции. Другой пример — Intel SDE и Wind River Simics включают в себя поддержку будущих инструкций Intel, и на них можно тестировать своё ПО заранее. Третий пример — Apple Rosetta, слой совместимости для PowerPC, который был использован при переводе Макинтошей на архитектуру Intel для того, чтобы старые приложения работали без перекомпиляции.
Разработка Firmware, BIOS, UEFI-прошивок, драйверов, компиляторов для новых архитектур ведётся на симуляторах и позволяет к моменту доступности первых железок иметь уже что-то более-менее отлаженное со стороны софта. Всё вместе — укорачивает цикл разработки и приближает момент выхода продукта на рынок.
Даже некоторые осторожные оценочные предсказания производительности можно получить на функциональной модели. Конечно, они будут далеки от той точности, которую дают потактовые модели. Но скорость работы функциональной симуляции иногда важнее.
Я планирую в ближайшее время опубликовать ещё одну заметку про симуляцию, там будет дан пример того, когда точности функциональных моделей хватает, чтобы сэкономить на числе сожжённых чайников.
Хороший вопрос. Одна из областей их использования — разработка ПО до доступности железа, а точнее, совместная разработка (software/hardware codevelopment). Например, запуск Андроида для ARM с помощью SDK от Google на обыкновенном ПК c процессором IA-32 — это использование симуляции. Другой пример — Intel SDE и Wind River Simics включают в себя поддержку будущих инструкций Intel, и на них можно тестировать своё ПО заранее. Третий пример — Apple Rosetta, слой совместимости для PowerPC, который был использован при переводе Макинтошей на архитектуру Intel для того, чтобы старые приложения работали без перекомпиляции.
Разработка Firmware, BIOS, UEFI-прошивок, драйверов, компиляторов для новых архитектур ведётся на симуляторах и позволяет к моменту доступности первых железок иметь уже что-то более-менее отлаженное со стороны софта. Всё вместе — укорачивает цикл разработки и приближает момент выхода продукта на рынок.
Даже некоторые осторожные оценочные предсказания производительности можно получить на функциональной модели. Конечно, они будут далеки от той точности, которую дают потактовые модели. Но скорость работы функциональной симуляции иногда важнее.
Я планирую в ближайшее время опубликовать ещё одну заметку про симуляцию, там будет дан пример того, когда точности функциональных моделей хватает, чтобы сэкономить на числе сожжённых чайников.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программная симуляция микропроцессора. Коробка передач