Меню на РАПИРе (Страница 2 из 2)

Попробую, но я вот о чём думаю:  у меня сейчас эмуль умеет только останавливаться на обращение к заданному адресу. Есть два адреса: остановка по запросу опкода и остановка по любому запросу. Эмуль останавливается, я смотрю его состояние, если это не искомое - нажимаю "g" и работа продолжается.

Я так ощущаю, что нужно маленько расширить функционал точек остановки. Но как ?
- можно сделать только сравнение с заданным числом и направление операции (запись/чтение)
- можно сделать сравнение с диапазоном
- можно сделать сравнение по маске (val & XX == YY)
- можно сделать сравнение с 2-4 числами (остановка при совпадении с любым)
- можно сделать несколько точек (две? три?), каждая со своими возможностями (пока склоняюсь к этому варианту).

- и самый сложный вариант: вписывать какой-то язык запросов. Массив памяти (как  с физической адресацией так и отображение через контроллер озу), какой-то простой синтаксический анализатор сложных условий, массив регистров, массив портов, состояние шины (запись, чтение, ещё что-то).... И текстом писать условия остановки.

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

Если раскопки будут длительными, то лучше сделать это заранее, чем потом сидеть подолгу над каждой точкой.

> То есть, сейчас приходится вообще все обращения к адресу смотреть в поисках нужного?
> Сурово.

Минимально сурово. Задаём адрес дампа, нажимаем 'g' - виртуалка запускается.
Через секунду останавливается, смотрим дамп.
Глазом на конкретном байте замираем, если не то значение - снова 'g'.
Ну так минут за 15 я находил нужные точки.

--

Я давно хотел расширить механизм break point.

Сегодня, часов за 6, написал чуть больше 20 строк в виртуалке и исправил ещё 40 в мониторе виртуалки.
Раньше было компактно, в нескольких частях виртуалки такой код:

 cmpw    cpu_BP_by_ARG, %bx
 seteb    cpu_BP_by_Arg_Flag

- ни одного перехода. Если адрес совпал - ставим флаг.
И всё,  где-то в начале цикла обработки команды этот флаг проверялся и BP срабатывала.
А теперь вместо этих двух строк почти 20 и ещё несколько заметных изменений.

Виртуалка довольно таки заоптимизирована: например, если декодер адреса видит, что адрес не пересекает границы типов памяти (т.е. физически данные лежат подряд), он экономит такты на том, что цепочку виртуальных "дешифраторов шины" пробегает только один раз для получения сразу 2-4 байт (т.е. из физической памяти выгребает сразу 32 бита).
Но это требует отдельных веток исполнения и на каждой стоит своё обращение к контролю break point.

А поскольку это всё писалось лет 10 назад, приходится сильно напрягать мозги и память :))

--

Cделал так:
есть две break point по данным (не опкодам), каждая может быть настроена на срабатывание на чтение, на запись или на то и другое. И каждой можно задать диапазон значений вида XX <= значение <= YY.
То есть полный интервал XX = 00, YY = FF, и дальше можно сжимать.
Маски не стал делать - они всё равно на практике бывали нужны только как упрощённый вариант диапазона.

--

Результат в аттаче

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

Если это битый стек и он ломается, можно попробовать найти некую крупную процедуру, которая реализуют полную модификацию кадра стека, и затем, при её прохождении, снимать дампы памяти. Это не автоматически, но если там несколько десятков раз будет достаточно, то это минут 20 займёт, не больше.

А потом написать какой нибудь парсер дампа памяти, который будет для всех дампов проверять корректность стека (непротиворечивость, корректность всех указателей).

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

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

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

Если будет польза, можно попробовать одновременно работать: я дам доступ к эмулятору (PuTTY или R.M.S. или ещё что нибудь подобное), ты можешь что-то в нём смотреть, а я буду подсказывать как и что можно сделать.

Некое подобие анализатора кучи я сделал. К сожалению, получить полную картину он не дает. Таблица ASP содержит ссылки только на свободные блоки памяти. Ссылки на занятые блоки известны только подпрограммам, которые с этими блоками работают.

В теории, часть ссылок лежит прямо в занятых блоках памяти. Например, если создается кортеж, то для каждого его элемента память выделяется отдельно, и, найдя блок памяти с этим кортежем, можно понять на какие еще блоки памяти он ссылается. Вот только непонятно, как найти блок с кортежем :) Ну и еще такая мелочь - есть документированные типы блоков, а есть системные. Их формат неизвестен.

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

С выбором процедуры тоже есть сложности. Во-первых, она находится во втором дополнительном 4К массиве банка 0 ПсевдоПЗУ. Отладчик сможет это определить, или будет срабатывать при любом номере банка и доп. массива?
Во-вторых, эта процедура относится к целочисленному умножению. Может быть, будет срабатывать часто.

Срабатывания нужны не все, а только те, которые происходят после выбора пункта меню "3. музыка" и до падения. Если повезет, то десятка в два дампов уложимся. Если срабатываний будет больше - придется придумывать что-то еще.

Нужный адрес D194.

---
Кстати, файл с вот таким заголовком:

- это тоже исходник Рапиры.

Нет, похоже, что не появились :(
Тут какая-то сборная солянка из компонентов ИКП-7: загрузчики, разные части DOS, сборочные файлы.
Много исходников AGAT COPY и AGAT AUTHOR, возможно даже полные. Есть какие-то куски от Бейсика.
От Рапиры есть только INITMEM, драйвер принтера и части DOS.

Определенная ценность у этого есть, но собрать ни Рапиру, ни полный ИКП не получится :)

Так, D194 в первом массиве 0 банка - это середина BNE, в первом массиве 1 банка - вообще таблица с данными, во втором массиве 1 банка - не могу понять, что (он не дизассемблировался полностью, потому что непонятно, как процедуры вывода графики, которые там находятся, связаны с остальным кодом).

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

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

Образ же для семерки, откуда 128 кб?

А так, да, нужно то, что видит процессор (64 кб).

---

Кстати, мне тут подумалось, что в эмуляторе хорошо было бы иметь счетчик тактов ЦП. Какой-нибудь int64, чтобы он просто от сброса считал такты. И в момент срабатывания брейкпойнта можно было его посмотреть.
И еще сделать возможность остановки по достижению определенного значения этого счетчика.
Тогда можно было бы просто отматывать по 10000 тактов назад и смотреть - сломалось/не сломалось.