Pull to refresh

Comments 19

Прикольная штука.


Есть такой симулятор Simics от интела. Он умеет даже в обратную сторону откатывать на любое количество шагов, даже с операционными системами, типа линукс, виндоус. Рекомендую потыкать, он стал открытым.


На хабре даже статьи были по теме.

На любое количество шагов ни один отладчик чего-угодно неспособен отматывать. Память не бесконечна. Всегда есть лимит.

Если вопрос симуляции процессора Интел, находящегося в разработке, вам напихают памяти сколько будет нужно. Но это не так много, как кажется.

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

Не вижу проблем. Если вы отлаживаете BIOS, или загрузку ОС, то это бесценно. И, потом, вам же не требуется прям от начала времён лог вести.

Спасибо!

Отдельно github ещё не открывал. Пока только в gist как эксперимент для личных нужд.

а почему бы отладчик на железном процессоре не модифицировать (какой-нибудь x64dbg), чтобы он историю сохранял? или я чего-то не понял?

Инженеры не предусматривали непосредственного произвольного программного доступа ко всему Регистровому Файлу.

Для чего нужен непременно "произвольный программный доступ"?

Гарвардская архитектура разделяла не только код от данных, но и стек (сам i8080 сигнализирует о доступе к стеку, например, позволяя строить, хотя не "гарвардский"). Но Принстонская взяла вверх.

Почему тогда в отладчиках, на ряду с раскруткой стека, не имеем и раскрутку регистрового файла? (Хотя, на сегодняшний день это уже не актуально.)

Я думаю вы уже знакомы с эмулятором Bochs и его встроенным отладчиком. Я хотел бы предложить поучаствовать в проекте Bochs и сделать его эмулятор и отладчик лучше.

Я кстати, походу последний Bochs maintainer а без контрибуторов проэкт загнется.

Можно примеров, для которых необходима именно такая техника, и более традиционные методы не годятся?

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

onlinegdb.com, например, работает больше как реальный, а следовательно, имеет множество бюрократических нюансов (программа компилируется и т.д.).
А в случае, когда на пальцах нужно показать, как взаимодействует пяток-другой инструкций третьему лицу, такое средство не подходит.

Вот и пришла мысль сделать именно бутафорский симулятор, чтобы наглядно показывал что и где в конкретном коде подводит.

P.S.: Verilog, конечно, для инженеринга незаменим вместе с GTK-wave, но Logisim позволяет более наглядно увидеть весь процесс в целом.
Просто, дело вкуса! ;-)
Это симулятор - своеобразный Logisim для изучения ассемблера.

Отличный проект!
Есть ощущение, что help->about должен быть поверх "Graphics display", а не под ним.
Мне было бы интересно посмотреть на бенчмарки для оценки производительности данного решения, чтобы без экспериментов понимать подходит/не подходит ли оно для конкретной задачи.

Идея симулятора появилась тогда, когда появилась необходимость переделать мой старый MMX-алгоритм под SSE для третьего лица, не имея под рукой среды разработки/отладки. И нужно было понять, почему у третьего лица конкретно этот фрагмент кода падал.
В онлайн-эмуляторах отлаживать SSE-код, переделанный из MMX - удовольствие так себе.
Пришлось наспех набросать симулятор с поддержкой только конкретных инструкций. Что, в итоге, помогло дистанционно интуитивно отладить код.

О высокой производительности речи не шло, так как главное было - понять, что где происходит.

Sign up to leave a comment.

Articles