Вид для печати
Вроде и вектора-призраки привёл в чуйства :)
- - - Добавлено - - -
Добавил описание макровызова .LOAD - я в тот момент ещё вспоминал - как я макросы реализовал, этот показался сложным и я отложил его.. :)
Поправил (возможно, не всегда корректно) числа в ссылки.
.MAC по результат сборки и восстановления исходника по прежнему совпадает :)
Через какое-то время сравню с .MAC, который я начал делать до добавления генерации макровызов (сделал их руками) - посмотрим, что будет на предмет совпадения :)
Проверка ручной генерации и генерации в DisAsm-11 макровызовов пройдена успешно :)
На самом деле, макросы XXDP ещё надо проверить по исходникам монитора - много макросов БЕЗ аргументов и по крайне мере в отношении некоторых точно известно (исходники мониторов), что аргументы передаются. Ну это постепенно.
В процесс проверки восстанвливаемых текстов из LDA добавил доп проверку. Теперь утилитой LDAUtils делаю двоичные файлы и сравниваю так же их. Пока сюрпризов нет - если сравнились результаты автоDisAsm-а, сравниваются и двоичники.
- - - Добавлено - - -
Наткнулся на неточность в поведении DisAsm - если поменять метку, на которую ссылается команда, то всё ок, в команде метка также меняется, но если эта команда часть макровызова - то в макровызове не меняется. Технически обходится элментарно, но... надо будет посмотреть и поправить :)
На самом деле, есть ещё один зависимый от PDP-11 модуль - генератор исходника. Но надо было время немного поиграться-потестировать с тем, что уже было сделано плюс - подумать над тем - как избавить его от зависимостей :)
Первый шаг сделан - в окнах показывается теперь более-менее полноценный исходник
Добавленное удалено из процессе генерации исходника. Но там есть ещё нюансы, в частности - файлы с перекрытиями. Поэтому - то, что было очевидно - вырезано, дальше буду смотреть и думать
По результатам доработок, а так же экспериментов с .TSK с перекрытиями - внутренние переработки.
Скорее всего, по результатам будет версия DisAsm-11, генерирующая несколько файлов для программ с перекрытиями (по файлу на каждое перекрытие). Там ещё остаётся много вопросов, но - постепенно буду двигаться :)
Возможно, по результатам попробую добавить так же в .SAV
Как это (может) (будет) выглядет
Пока ещё пристрелка, есть ошибки и не всё работает, но - дерево перекрытий слево уже не только просто демонстрация :)
Дальше - пошёл спать :)
Переделка внутреннего механизма ссылок.
Не помню уже, почему было реализовано так, как было реализовано (это ещё из первой версии дизасма), но для работы с оверлеями, как оказалось, не сильно удобно.
Поэтому (для начала) изменил сам механизм хранения ссылок, а сейчас в процессе размышления, как лучше сделать для поиска ячейки по адресу - просто поиск, естественно, есть, теперь поиск и по другим перекрытиям - но в нём есть нюансы. По дереву вниз - без проблем, а вот вверх по дереву...
Внутренние переделки.
Внешне почти не заметно
Изменилась взаимосвязь внутренних объектов - теперь проще будет искать по перекрытиям. По крайне мере - я так надеюсь :) Так как до поиска ячеек по перекрытиям пока не добрался - всякие внутренние переделки, эксперименты и переделки по результатам переделок..
Продолжается зачистка ядра DisAsm-а от PDP-11 зависимостей, в первую очередь - интерфейса (графического и командной строки). Есть ещё большая зависимость в генераторе .MAC файла (в первую очередь - от .SAV), его в планах переделать (.SAV - по аналогии с .TSK), что бы он стал просто циклом прохода по всем ячейкам и вывода их содержимого в файл - примерно как оно сейчас выводится в окошках. Так что пока ничего нового...
Наверное, самая большая переделка за последнее время.
- Переделано отображение информации об оверлеях (основное окно дизасма и окна операндов)
- Количество окон операндов теперь динамическое (если процессор не двухоперандный :) )
- Внутренние зачистки и рефакторинг
Из существенно недоделанного - столбец ссылок всё ещё расчитан на двухоперандый проц - нужен сделать по аналогии с оверлеями. Ну и генератор исходника нужно допилить по двум направлениям - избавление от PDP-11 зависимости и генерация файлов для всех оверлеев, а не только корневого :)
Как теперь выглядит окно DisAsm-11 сразу после запуска
После открытия файла визульных изменений нет - пока не добавлю ноль-, одно- или более двух- операндный проц :)
Ну и вторая версия так и не вышла из состоянии беты - плавно перетекла в третью бету :)
- - - Добавлено - - -
Ошибся :) Столбец ссылок - это не ссылки на операнды :) Это ссылки на четный (младший) и нечётный (старший) байты текущей ячеки.. :) Ок, всё что успел надумать - в корзину :)
Как теперь выглядит окно DisAsm-11 сразу после запуска
Сделал столбец ссылок. Потом взгляд упал на... и я понял, что есть ещё поля для ввода меток и комментариев (четный и нечётный байты слова) :) С ними долго провозился - пока восстановил синхронизацию изменений аж в трёх местах..
Могу, конечно, опять про что-то забыть - но вроде только генератор исходника осталось переделать.
И надо бы какой-нибудь ещё проц - не двухкомандный добавить - что бы проверить - насколько работоспособны изменения (для PDP-11, понятно, проверил_
Так что сейчас определённая часть интерфейса отрисовывается, когда... есть что рисовать :)
Уже засыпал, когда пришло в голову - как можно проверить, хотя бы визуальную часть для не двухорперандного и недвухбайтнословного процессора
Как выглядит окно DisAsm-11 для пятиоперандного трёхбайтнасловного "PDP-11" :)
И да - несколько неудалённых зависимостей таки нашлось :)
- - - Добавлено - - -
Написал, показал, а потом неожиданно задумался - а почему только четыре окна слева :) Буду проверять - по идее, должно быть пять :)
- - - Добавлено - - -
Посмотрел исходники - ну, в принципе понятно. Константа по смыслу означала - максимальное количество операндов - а по факту - количество окон дизасма :) То есть по факту всё ок, а по смыслу.. Это исправить лехко :)
Вот теперь правильно и по смыслу и по факту :)
Как выглядит окно DisAsm-11 для пятиоперандного трёхбайтнасловного "PDP-11" :)
После многочисленных перетряхиваний внутренностей DisAsm (что ещё не закончено) были сделаны подвижки и в работе с перекрытиями - начато опробование механизма работы с ссылками не только в пределах родного перекрытия, но и в другие. Механизм, который выглядит простым и логичным - ищём ячейку по адресу ещё и вниз по дереву перекрытий до корня, а так же в других корневых перекрытиях.
Первые результаты
И вот тут я налетел на факт, что я мало знаю о многопользовательских .TSK из RSX.
Напоминание о том, что это такое - это программа, в которой компоновщик собрал две больших части - read-write секции (RW) и read-only секции (RO). И RO часть оформлена наподобие современных dll библиотек, но
- она "встроена" в программу, а не хранится отдельным файлом
- при первом запуске создается область памяти, куда грузится эта секция
- для RW секции запускаемых первого и последующих экземпляров программ для виртуального адресного пространства программы создаётся окно-отображение на эту область памяти (с доступом только на чтение!)
- эта область памяти остаётся в физической памяти до тех пор пока а) есть хоть один запущенный экземпляр программы и б) системе не требуется память для выделения чего то, а свободной памяти нужного размера нет. Причём в случае б система данную область памяти не выгружает, а просто освобождает. А как только эта RO секция опять нужна - она подгружается из .TSK файла
И вот в EDT.TSK это RO часть, если судить по данным в описании этого перекрытия (а оформляется оно как перекрытие) оказалась (значительно!) больше окна, через которое она будет отображаться :eek:
Ну и поскольку обнаружилось это в процессе доработок-отладок поздно ночью - я решил - утро вечера (и ночи) мудреннее и пошёл спать :) Детектив продолжается...Код:Task name : ...EDT
Partition name : GEN
Identification : V03.20
Task UIC : [1,24]
Task priority : 65.
Stack limits: 000256 001255 001000 00512.
PRG xfr address: 123470
Task attributes: CP,-FP,MU
Total address windows: 4.
Task image size : 8096. words
Task address limits: 000000 117777
R-W disk blk limits: 000002 000041 000040 00032.
R-O disk blk limits: 000042 000334 000273 00187. <--- ???? это о размещении в файле образа
......
*** Root segment: ROOT
R/W mem limits: 000000 037421 037422 16146.
R-O mem limits: 120000 172777 053000 22016. <--- размеры окна
Disk blk limits: 000002 000041 000040 00032.
- - - Добавлено - - -
Вдогонку. Нужно ещё продумать механизм генерации меток, на которые идёт ссылка из других перекрытий. Потому как они получаются а) ака глобальные символы и б) существующий алгоритм будет приводить к (потенциальной) генерации одинаковых меток для перекрытий, загружаемых с одного адреса
Вроде бы нашёл правильно число. По крайне мере - внешний вид сразу после загрузки у разных вариантов EDT похожий. Придётся лезть в исходники TKB для окончательного прояснения - что же эти числа значат...
Первый подход к снаряду межоверлейных ссылок
Пока проверка концепии и прояснение нюансов. Нууу... концпция вроде рабочая :) Осталось только сделать вначале оверлея список .GLOBL и.. есть мысль по поводу формата меток :)
Ранее недописанное.
Формат межоверлейных меток в первом приближении сделан, но .GLOBAL на них ещё не выставляется - позже как-нибудь, всё равно ещё оверлеи RSX не готовы к трансляции и уже тем более к сборке программы.
По дизасму CIL и LCL файлов от DOS-11
Сам по себе парсер CIL файлов написан, теперь надо правильно проставить ссылки и выполнить первый проход анализа по модулям. Сделал модули из CIL файлов как оверлеи, где в качестве корневого модуля выступает инфа из каталога CIL файла. Первая доработка концепции оверлеев DisAsm не только под оверлеи RSX, но и под другой вариант оверлеев.
Как будет более менее приличный результат, выложу картинку :)
Парсер вроде ОК, но вот межоверлейные ссылки.. Допиливаю :)
Теперь генерятся исходники для всех оверлеев. По именам файлов ещё надо думать - для PDP11 систем это 6 или 9 символов в имени плюс 3 в расширении.
Проверки пока идут с CIL файлами :)Код:Directory of ForDebug\DisAsm\DOS11\09.20c
28.01.2024 15:16 <DIR> .
24.01.2024 19:25 <DIR> ..
11.12.1972 00:00 19 890 CILUS.LDA
24.01.2024 21:38 40 357 dump.txt
28.01.2024 15:14 1 858 MONLIB.BCL.2.MAC
28.01.2024 15:14 1 873 MONLIB.BCL.3.MAC
28.01.2024 15:14 1 879 MONLIB.BCL.4.MAC
28.01.2024 15:14 1 754 MONLIB.BCL.5.MAC
28.01.2024 15:13 14 743 MONLIB.CF.TBL.MAC
11.12.1972 00:00 89 600 MONLIB.CIL
28.01.2024 15:14 368 MONLIB.CL.L.MAC
28.01.2024 15:14 381 MONLIB.CL.P.MAC
28.01.2024 15:14 3 430 MONLIB.CTO1.MAC
28.01.2024 15:14 3 234 MONLIB.CTO2.MAC
28.01.2024 15:14 6 042 MONLIB.DV.CR0.MAC
28.01.2024 15:14 7 985 MONLIB.DV.CR1.MAC
28.01.2024 15:14 7 459 MONLIB.DV.CR2.MAC
28.01.2024 15:14 10 286 MONLIB.DV.CR3.MAC
28.01.2024 15:14 12 478 MONLIB.DV.CT.MAC
28.01.2024 15:14 1 170 MONLIB.DV.DC.MAC
28.01.2024 15:14 1 218 MONLIB.DV.DF.MAC
28.01.2024 15:14 2 083 MONLIB.DV.DK.MAC
28.01.2024 15:14 4 392 MONLIB.DV.DP.MAC
28.01.2024 15:14 4 393 MONLIB.DV.DPB.MAC
28.01.2024 15:14 2 698 MONLIB.DV.DT.MAC
28.01.2024 15:14 8 471 MONLIB.DV.KB.MAC
28.01.2024 15:14 2 701 MONLIB.DV.LP0.MAC
28.01.2024 15:14 3 243 MONLIB.DV.LP1.MAC
28.01.2024 15:14 7 771 MONLIB.DV.MT.MAC
28.01.2024 15:14 1 227 MONLIB.DV.PP.MAC
28.01.2024 15:14 1 076 MONLIB.DV.PR.MAC
28.01.2024 15:14 1 826 MONLIB.EDP.2.MAC
28.01.2024 15:14 1 787 MONLIB.EDP.3.MAC
28.01.2024 15:14 3 541 MONLIB.EM.006.MAC
28.01.2024 15:14 2 822 MONLIB.EM.007.MAC
28.01.2024 15:14 1 758 MONLIB.EM.010.MAC
28.01.2024 15:14 2 011 MONLIB.EM.011.MAC
28.01.2024 15:14 799 MONLIB.EM.012.MAC
28.01.2024 15:14 574 MONLIB.EM.013.MAC
28.01.2024 15:14 2 981 MONLIB.EM.014.MAC
28.01.2024 15:14 3 533 MONLIB.EM.015.MAC
28.01.2024 15:14 3 570 MONLIB.EM.016.MAC
28.01.2024 15:14 3 282 MONLIB.EM.017.MAC
28.01.2024 15:14 2 954 MONLIB.EM.020.MAC
28.01.2024 15:14 3 544 MONLIB.EM.021.MAC
28.01.2024 15:14 3 506 MONLIB.EM.022.MAC
28.01.2024 15:14 2 253 MONLIB.EM.024.MAC
28.01.2024 15:14 3 454 MONLIB.EM.025.MAC
28.01.2024 15:14 1 914 MONLIB.EM.031.MAC
28.01.2024 15:14 1 845 MONLIB.EM.032.MAC
28.01.2024 15:14 1 846 MONLIB.EM.033.MAC
28.01.2024 15:14 1 814 MONLIB.EM.034.MAC
28.01.2024 15:14 1 881 MONLIB.EM.035.MAC
28.01.2024 15:14 2 041 MONLIB.EM.041.MAC
28.01.2024 15:14 2 898 MONLIB.EM.042.MAC
28.01.2024 15:14 3 527 MONLIB.EM.043.MAC
28.01.2024 15:14 3 317 MONLIB.EM.044.MAC
28.01.2024 15:14 3 557 MONLIB.EM.045.MAC
28.01.2024 15:14 3 190 MONLIB.EM.046.MAC
28.01.2024 15:14 2 391 MONLIB.EM.047.MAC
28.01.2024 15:14 2 066 MONLIB.EM.050.MAC
28.01.2024 15:14 3 531 MONLIB.EM.051.MAC
28.01.2024 15:14 2 826 MONLIB.EM.052.MAC
28.01.2024 15:14 3 457 MONLIB.EM.053.MAC
28.01.2024 15:14 3 479 MONLIB.EM.054.MAC
28.01.2024 15:14 2 297 MONLIB.EM.055.MAC
28.01.2024 15:14 3 497 MONLIB.EM.056.MAC
28.01.2024 15:14 3 551 MONLIB.EM.057.MAC
28.01.2024 15:14 1 463 MONLIB.EM.060.MAC
28.01.2024 15:14 3 608 MONLIB.EM.061.MAC
28.01.2024 15:14 3 034 MONLIB.EM.062.MAC
28.01.2024 15:14 3 422 MONLIB.EM.063.MAC
28.01.2024 15:14 1 821 MONLIB.EM.064.MAC
28.01.2024 15:14 3 575 MONLIB.EM.065.MAC
28.01.2024 15:14 3 314 MONLIB.EM.066.MAC
28.01.2024 15:14 2 102 MONLIB.EM.067.MAC
28.01.2024 15:14 3 550 MONLIB.EM.071.MAC
28.01.2024 15:14 1 624 MONLIB.EM.077.MAC
28.01.2024 15:14 3 245 MONLIB.IN.001.MAC
28.01.2024 15:14 1 968 MONLIB.KB.AS.MAC
28.01.2024 15:14 1 856 MONLIB.KB.AS2.MAC
28.01.2024 15:14 1 903 MONLIB.KB.AS3.MAC
28.01.2024 15:14 1 829 MONLIB.KB.BE.MAC
28.01.2024 15:14 1 753 MONLIB.KB.BE2.MAC
28.01.2024 15:14 1 881 MONLIB.KB.BE3.MAC
28.01.2024 15:14 1 833 MONLIB.KB.BE4.MAC
28.01.2024 15:14 1 701 MONLIB.KB.DA.MAC
28.01.2024 15:14 1 850 MONLIB.KB.DA2.MAC
28.01.2024 15:14 1 806 MONLIB.KB.DA3.MAC
28.01.2024 15:14 1 858 MONLIB.KB.DA4.MAC
28.01.2024 15:14 1 877 MONLIB.KB.DU.MAC
28.01.2024 15:14 1 893 MONLIB.KB.DU2.MAC
28.01.2024 15:14 1 506 MONLIB.KB.DU3.MAC
28.01.2024 15:14 784 MONLIB.KB.DX1.MAC
28.01.2024 15:14 1 804 MONLIB.KB.EC.MAC
28.01.2024 15:14 1 603 MONLIB.KB.EO.MAC
28.01.2024 15:14 1 864 MONLIB.KB.KI.MAC
28.01.2024 15:14 1 594 MONLIB.KB.KI2.MAC
28.01.2024 15:14 1 707 MONLIB.KB.ME.MAC
28.01.2024 15:14 1 722 MONLIB.KB.MO.MAC
28.01.2024 15:14 1 942 MONLIB.KB.MO2.MAC
28.01.2024 15:14 1 681 MONLIB.KB.OD.MAC
28.01.2024 15:14 1 633 MONLIB.KB.OW.MAC
28.01.2024 15:14 1 559 MONLIB.KB.SA.MAC
28.01.2024 15:14 1 889 MONLIB.KB.SA2.MAC
28.01.2024 15:14 3 238 MONLIB.KB.SA3.MAC
28.01.2024 15:14 1 550 MONLIB.KB.TE.MAC
28.01.2024 15:14 1 856 MONLIB.KB.TF.MAC
28.01.2024 15:14 1 861 MONLIB.KB.TF2.MAC
28.01.2024 15:14 1 858 MONLIB.KB.TS.MAC
28.01.2024 15:14 1 863 MONLIB.KB.TS2.MAC
28.01.2024 15:14 1 659 MONLIB.KB.WA.MAC
28.01.2024 15:14 1 890 MONLIB.KBL.2.MAC
28.01.2024 15:14 1 813 MONLIB.KBL.3.MAC
27.05.2021 13:56 69 120 MONLIB.LCL
28.01.2024 15:14 3 598 MONLIB.LD.001.MAC
28.01.2024 15:14 3 433 MONLIB.LD.002.MAC
28.01.2024 15:08 24 063 MONLIB.MAC
28.01.2024 15:14 3 238 MONLIB.OPN1.MAC
28.01.2024 15:12 55 238 MONLIB.RM.001.MAC
28.01.2024 15:14 49 097 MONLIB.TM..MAC
27.05.2021 13:56 15 360 SYSLOD.CIL
27.05.2021 13:56 13 312 SYSMAC.SML
121 File(s) 693 281 bytes
2 Dir(s) 39 142 969 344 bytes free
Лучше, конечно, писать в правильной теме :)Цитата:
Сообщение от Woxem
Теперь по вопросам.
Все мои программы разрабатываются, в первую очередь, под мои хотелки. А поскольку хотелки часто обширны - реализовать их с подходом - сели и написали - крайне тяжело. Часто нужно долго курить документацию (и не только на PDP-11), отлаживать ошибки и подход в целом, а так же - хотелки со временем и опытом (могут и) меняются. Поэтому ответ на вопрос "вы закончили?" в отношении любой моей поделки с вероятностью под 100 процентов - нет, в процессе :)
Что касается DisAsm. Была начата доработка для работы с одним из вариантов программ с оверлеями DOS-11, но попутно были изменения во внутренностях пользовательского интерфейса и на текущий момент он несколько СЛОМАН - не работают клавиши-команды типа C, D, Z, а так же ввод символов таких клавиш в комментариях.
Плюс - DisAsm и ImageUtils используют приличное количество общего кода, а в процессе добавления функционала в DisAsm мне понадобилась возможность переносить файлы с PC в DOS-11, поэтому на определённом этапе доработок DisAsm я переключился на ImageUtils (где пока и нахожусь). Так что, возможно, что в DisAsm не работает что-то ещё.
Когда вернусь к DisAsm для доработок и фиксов - НЕ ПРЕДСКАЗУЕМО - так как свободного времени на хобби очень мало.
Так что
- если требуется функционал дизасма образов памяти (ака ПЗУ) или SAV файлов - ничего нового нет, можно использовать старую версию. Могу выложить последний вариант (до переделок) с рабочего компа, но это вариант, который использует .NET 7, то есть нужна Windows, которая его поддерживает и нужно устнановить на неё поддержку .NET 7
- если по любой причине хочется новую версию - выложить могу - но без каких-либо гарантий - проверять и фиксить ошибки сейчас времени нет.
Руки наконец дошли до DisAsm, а точнее - до сломанных клавиш-команд. После гугления и экспериментов стала более-менее понятно, что сломалось (ответ - что-то недоделанное (возможно) в .NET) и даже сумел прилепить костыль, что бы заработало. Из оставшегося неработающего - enter и esc в полях ввода комменатриев, но скорее всего - причина понятна. Пока тестирую остальные команды, как доберусь до enter/esc - посмотрю, прав ли.
- - - Добавлено - - -
Ну, вроде привязку шот-катов пофиксил. Опять возвращаюсь к DOS-11 :)
Как ни странно, но в процессе перерыва занимался не программированием в другом виде (ака FPGA), а некоторым наведением порядка на компе. Ну и последние где-то четыре дня в процессе засыпания в голове крутилась одна мысль. Которую я рассматривал с разных сторон, пока, наконец, мысль не созрела :)
Это предыстория :) Дальше история :)
В какой-то момент в DisAsm были добавлены служебные ячейки, которые позволили описывать разное - не только команды и метки (которые генерятся из дизассемблируемого файла), а всякие .TITLE, .IDENT. Ну и блочные комменты - они из той же серии. Это позволило приблизить генерируемый файл в нормальному исходнику, но создало некоторые проблемы - когда нужно было, скажем - из команды, сослаться на другую ячейку - с командой или данными. Для чего её сначала нужно было найти. Раньше было просто - все ячейки с данными из файла - простой массив, который содержал только их - и по адресу, связанному с ячейкой, можно было просто вычислить её индекс в массиве и выйти на неё. Быстро.
Но теперь среди ячеек мало того, что встречаются служебные (без адреса и/или данных) - так ещё и они добавляются-удаляются на ходу (чего не происходит с ячейками из файла). Соотвественно - найти уже так просто не получается.
Технически - это не мешало процессу дизасма, а только замедляло поиск нужной ячейки и на какое-то (долгое) время я на это забил.
Но это не значит, что мне это нравилось :)
Вот собственно - на эту тему мысли в голове и крутились :) И с четверга на пятницу (возможное) решение - как ускорить поиск - вызрело. До состояния, в котором я уже не видел с ходу проблем с его реализацией и использование.
В общем, в пятницу вечером набросал и слегка проверил, а сегодня допроверял и дофиксил. Не скажу, что все ошибки нашёл и пофиксил, но, по крайне мере, при запуске некоторого количества автоматических тестов DisAsm бодро отрабатывает, не валится, и результаты вроде ок :)
Ессссвенно, было интересно - ускорилось и если на да - насколько. Поэтому один из автоматических тестов (дизасм EDT.TSK) был переделан под оценку времени.
Результаты
Старый вариант - 21 секунда
Новый варант (debug) - 24 секунд
Новый варант (release) - 14 секунд
ОЧЕНЬ прилично получилось :)
Ну и видно - насколько медленней вариант debug по сравнению с release :)
Ну а суть алгоритма ускорения - некий вариант кэширования :) То есть - памяти тратится побольше (но "кэш-память" - это простой массив, так что - не сильно много), а работаем побыстрее :)
Тестирование, фиксы ошибк (если найдутся) и доработка продолжается :)
Пока опять не устану от программирования - ибо на работе его никто не отменял
Давнишний недоделанный остаток переноса всего зависимого от чего-то кода в спец модули - в генераторе исходника был код под .SAV файлы. Выпилил и перенёс. Теперь вроде такого кода не осталось. Теоретически - можно добавлять другие процессора :) Но пока не до этого :)
- - - Добавлено - - -
И заголовок .SAV пока парсится руками, а не по описанию классом. Вариант, который сейчас обрабатывает DisAsm - простейший (даже оверлеи пока не парсятся), так что пока не стал заморачиваться на создание описания классом. Как-нибудь, скорее всего, когда начну добавлять работу с оверлеями
В процессе тестирования поправил две ошибки.
Одна была известна - если в DisAsm-е открыть файл, а потом, не выходя из него, открыть другой файл - он показывал странное. Оказалось - думал на не то место возникновения. Поправил
Вторая - новая. Оказалось, в процесс доработок сломал сохранение сеанс. Пришлось попотеть над одним моментом, но - тоже поправил.
Пока причёсываю код.
Из мысле, которые в голову - добавить дизасм .OBJ файлов. Но перед этим надо продумать некоторое количество доработок :)
- - - Добавлено - - -
Ещё из мысле. MS слегка выпилила поддержку КОИ-8 из стандартной поставки для .NET 5.x-.., что привело к тому, что DisAsm11X таскает за собой .dll на 700+ кб. Что мне несколько не нравится. Поэтому обдумываю вариант - впилить поддержку КОИ-8 непосредственно в DisAsm.
Ну а в КОИ-8 генерируются всякие текстовые .ASCII
Поставил давно хотимый эксперимент.
Вводная часть.
Сейчас для программ с тем или иным вариантом оверлеев DisAsm создает по три визуализирующих объекта (основное окна дизасма и два окна операндов) на каждый оверлей (или его аналог). Цена - загружается дольше. Ну и, скажем - изменение размеров окна самого DisAsm-а - тоже не быстрая операция. Если, конечно, оверлеев МНОГО :) Плюсы - окна между оверлеями переключаются очень быстро.
Эксперимент.
Ставился на MONLIB.CIL (файл библиотеки операционки DOS-11) - там 117 модулей - ядро и модули-оверлеи.
Сделал вариант, когда визуализирующих объектов всего три - и к ним динамически цепляются массивы ячеек - при переключении между оверлеями или когда аргумент(ы) команды - в других модулях
Итак. Первым указывается время работы первого ("многооконного") варианта DisAsm, а вторым - тестируемый "трёх-оконный" вариант
Время загрузки - 74 секунды против 3 секунд
Размер программы после загрузки - 2.1 Гб против 195 мб
Генерация исходников - 98 секунд против 4 секунд
Размер программы после генерации исходников - 2.9 Гб против 195 мб
Переключение между модулям - практически моментально против около секунды
Комментарий по поводу времени генрации исходников - когда писал код, у меня возникла мысль, что перед генерацией надо вырубить визуализацию, а после - включить - в силу происходящих в процессе генерации вещей показалось, что так будет быстрее. Но, похоже - оказалось показалось. Поэтому был поставлен ещё один эксперимент - не вырубать визуализацию. Время генерации стало 4 секунды :)
В общем, похоже оставлю новый вариант :)
Война с процессом восстановления текущего оверлея и текущих ячеек в нём при открытии файла сохранённой сессии.
Точнее говоря - с действиями, что бы в приложении после восстановления сохранённой сессии вернуть их, в силу некоторых особенностей WPF и .NET.
Но вроде бы победил. В целом. :)
В процессе доработки ImageUtils периодически отвлекаюсь на разное, в частности, на дизасм. И вот, возясь с очередным, понял, что не хватает мне НЕКОЕГО функционала :) Итак
Запускаем DisAsm11, открываем файл
Нажимаем Ctrl/C (видимого результата нет)
Переходим на другую ячейку
Нажимаем F7, а затем Ctrl/C
А затем - искать далее и - вуаля!
Пока ограничился таким - как обычно - надо поиграться и понять - что не так сделал и чего не хватает :)
- - - Добавлено - - -
А, да, вдогонку. Работают также Shift/F7 (продолжить поиск вперёд) и Alt/F7 (продолжить поиск назад). Ctrl/F7 (поиск с заменой) не используется.
Можно ссылку и на disasm?
DisAsm более менее работоспособен (по крайне мере на ошибки пока не налетал), так что да, чуть позже только
Подчистил некоторое количество хвостов - в плане ошибок, неточностей и неудобств. Не все, но, скорее всего, на этом пока остановлюсь (если ошибок опять не найду).
Очень удобно, что стало возможным искать разное :)
Поиск сделан достаточно дубово. Берётся содержимое пятого столбца окна дизасма. Что туда попадёт - можно посмотреть, сделав Ctrl/C и вставив текст куда угодно, хоть в Notepad. Далее - табуляции заменяются на пробел, выкидываются переходы на новую строку, а последовательности пробелов заменяются на один. Получившаяся строка ищется от следующей ячейки (если поиск вперёд) или предыдущей (поиск назад) и до последней/первой ячейки, с содержимом которых повторяется та же операции и результат проверяется на наличии строки поиска как подстроки. То есть - если есть метки - можно искать метку, если есть комментарии - можно искать в комментариях, но по любой части команды (только принимая во внимание, что после запятой, разделяющей операнды - идёт пробел. Ну и любые комбинации. Если очередная ячейка найдена - становится текущей, если не найдена - текущая не меняется.
Никаких вариантов а ля * (любое количество любых символов) или ? (один любой символ). Если и буду делать - как-нибудь, если понадобится.
А вообще странно - чего я давно не сделал поиск :)
Как уже написал в топике про ImageUtils - устал от него и (подтолкнула текущая возня с дизасмом одной проги) продолжил доработку DisAsm-11. Про добавленный поиск уже написал, но на нём не остановился.
Когда-то достаточно давно в DisAsm-11 было добавлено определение макровызовов, которые, ко всему прочему, генерировались в зависимости от операционки для программы. Технически - всё работало, но было два Но. Одно Но было не очень так чтобы Но, скорее - но, но... Неудобно было. Это было Но - но вызвать с клавиатуры или интерфейса распознание макровызова было не возможно. Поэтому было встроен механизм - если идёт анализ кода (при загрузке или по кнопке C) - то идёт попытка и распознать макровызовы. Так что - не сильно не удобно, но.. не удобно :)
Второе Но, даже НО - добавление новых макровызовов в процесс определения было КРАЙНЕ НЕДОБНО сделано. Нужно было добавить объекты-описания на уровне исходников. То есть захотел ещё один макро - редактируй исходники. Но, по ряду причин, было сделано как сделано и в принципе - неплохо работало.
Занялся я дизасмом одной проги под RSX - а для RSX никаких описаний не было. Можно было пойти по старому, проверенному пути, но в голове начала-продолжила крутится мысль об изменения механизма и источника данных для определения макровызово. А в силу некоторых изменений внутри DisAsm-а - стало возможным изменить структуру описания шаблонов для поиска макровызовов и в результате - вынести их из DisAsm-а.
В общем, где-то примерно со среды началась доработка. Сегодня наконец стали появляться визуальные результаты :) Пока всё ещё концепт, но уже неплохо работающий концепт.
Как выглядит на текущий момент.
Загружаем в DisAsm программу
Обращаю внимание, что в левом окне текущая ячейка - начало последовательности макровызова, а в правом верхнем - блок, описывающий макровызов, на который ссылается последовательность из левого окна
Жмём Alt/M и...
Получаем макровызов в левом окне и подстановку-определение блока макровызова в правом верхнем
Из предыдущего механизма была взята визуализация макро-команды (но есть добавки), а подгрузка определений из файла и сопоставления содержимого ячеек памяти с шаблономи - это новое.
Вот тут мне RSX подкинула бяку :) На картинке - неправильное обращение к макросу QIO$, правильно должно быть так:
или даже так можноКод:QIO$ 2440, 15, 15, K00442, 0, <L21640, 2, 0, 0, 0, 0>
Но это ещё предстоит допилить :)Код:QIO$ 2440, 15, 15, K00442, 0, <L21640, 2>
Как выглядит описание шаблонов на текущий момент:
Из автоматических плюсов - с блоками-описаниями макровызовов предыдущий подход работать не умел, здесь появился автоматом.Код:DIR$ ; source operand from instruction ; srcarg
012746 srcarg
[MCallPointer] 000000:000001
104377
QIO$ srcArg1, srcArg2, srcArg3, srcArg4, srcArg5, srcIO1, srcIO2, srcIO3, srcIO4, srcIO5, srcIO6
[byte] 001 ; dic
[byte] 014:377 ; dpb size
0:0 srcArg1 ; function
0:0 srcArg2 ; lun
[byte] 0:0 srcArg3 ; efn
[byte] 0:0
[DPointer] 0:0 srcArg4 ; iost pointer
[CPointer] 0:0 srcArg5 ; ast pointer
[DPointer] 0:0 srcIO1
0:0 srcIO2
0:0 srcIO3
0:0 srcIO4
0:0 srcIO5
0:0 srcIO6
QIOW$ srcArg1, srcArg2, srcArg3, srcArg4, srcArg5, srcIO1, srcIO2, srcIO3, srcIO4, srcIO5, srcIO6
[byte] 003 ; dic
[byte] 014:377 ; dpb size
0:0 srcArg1 ; function
0:0 srcArg2 ; lun
[byte] 0:0 srcArg3 ; efn
[byte] 0:0
[DPointer] 0:0 srcArg4 ; iost pointer
[CPointer] 0:0 srcArg5 ; ast pointer
[DPointer] 0:0 srcIO1
0:0 srcIO2
0:0 srcIO3
0:0 srcIO4
0:0 srcIO5
0:0 srcIO6
Из неавтоматических плюсов - в шаблоне можно указать тип ссылки (скажем, для DIR$ - что она ссылается на блок-описания макроса - MCallPointer) - и для ячейки автоматом выставится нужный тип, что так же может привести к цепочке последствия - скажем, в случае того же DIR$ автоматом будет попытка определения макроса в блоке-описании, что и можно наблюдать на картинках.
Ещё изменения в работа с шаблонами - теперь можно описать несколько шаблонов - в зависимости от процессора, операционки, типа файла и т.п., а так же можно описать шаблон под дизасм конкретной программы - приведенный выше шаблон сейчас сделан как раз в таком сценарии. Причём, если исходник шаблона был изменён - при попытке обратится к Alt/M DisAsm-11 это увидет - и подгрузит новый вариант.
Что ещё в планах
Изменение принципа работы с шаблонами
Для шаблонов из каталога, где лежит DisAsm11.exe - в начале дизасм-а они будут подгружаться в сеанс и дальше их изменения на текущем дизасме отражаться не будут
Для шаблонов, связанных с дизассемблированной программы - изменения будут определяться, сгенерированные обращения для шаблонов, которые были удалены или изменены - будут аннулироваться, но после подгрузки новых - для ранее сгенерированных обращений будет повторяться поиск шаблона
Возможно (!! пока ешё не определился) будут добавлны также шаблоны уровня каталога - то есть если в каталоге лежит несколько дизассемблируемых программ - для них можно будет создать общие шаблоны. Но пока ценность такого не понятна.
Так же есть мысль добавить возможно переносить комментарии из шаблона в дизасм. Тут вроде всё должно быть не сильно сложно.
Практически наверняка будут ещё аттрибуты (типа MCallPointer) уровня шаблона и уровня заголовка-описания (там, где DIR$) шаблона - но они добавляются из практической необходимости, делать по сценарию - а давайте добавим ещё такой, такой и сякой аттрибут, просто что бы было - не буду :)
Так же теперь появляется возможность описывать не только макровызовы, но и определять всякие стандартные процедуры, скажем - те, которые в SYSLIB. Думаю. Механизм в целом будет похож на работы с макросыми, но есть (в визуализации) существенные отличия. Так что тут пока вообще никак :)
В целом же пока работы идут в режиме тестирования - буду накидывать другие макровызовы и смотреть визуализацию, в том числе - перенесу описания из предыдущего варианта, и - искать-исправлять ошибки плюс добавление функционала, что бы старые определения работали полностью
Из реализованного
Для QIOW$ - проверка алгоритма, а не реальная структура макро-вызова :)
Как выглядит шаблон:
Планы дальше - накидывать другие макровызовы и смотреть визуализацию, перенес описаний из предыдущего варианта, искать-исправлять ошибки плюс добавление функционала, что бы старые определения работали полностьюКод:QIO$ srcArg1, srcArg2, srcArg3, srcArg4, srcArg5, <srcIO1, srcIO2, srcIO3, srcIO4, srcIO5, srcIO6>
[byte] 001 ; dic
[byte] 014:377 ; dpb size
0:0 srcArg1 ; function
0:0 srcArg2 ; lun
[byte] 0:0 srcArg3 ; efn
[byte] 0:0
[DPointer] 0:0 srcArg4 ; iost pointer
[CPointer] 0:0 srcArg5 ; ast pointer
[DPointer] 0:0 srcIO1
0:0 srcIO2
0:0 srcIO3
0:0 srcIO4
0:0 srcIO5
0:0 srcIO6
QIOW$ srcArg1, srcArg2, srcArg3, <<srcArg4>>, <srcArg5>, <<srcIO1, srcIO2>, <srcIO3, srcIO4>, srcIO5, srcIO6>
[byte] 003 ; dic
[byte] 014:377 ; dpb size
0:0 srcArg1 ; function
0:0 srcArg2 ; lun
[byte] 0:0 srcArg3 ; efn
[byte] 0:0
[DPointer] 0:0 srcArg4 ; iost pointer
[CPointer] 0:0 srcArg5 ; ast pointer
[DPointer] 0:0 srcIO1
0:0 srcIO2
0:0 srcIO3
0:0 srcIO4
0:0 srcIO5
0:0 srcIO6
Ну, технически это не что-то новое, в старом варианте что-то (похожее) было, но в новом реализовано по другому.
Как это выглядит на картинке
И в шаблоне
Варианты для команд из макросов я добавил в самом начале этой доработки, но вот проверка на совпадение с шаблоном и подготовка данных для визуализациии - потребовали некоторого количества кода. Сама визуализация отработала сразу :)Код:MRKT$S srcEF, srcTM, srcTU, srcAST
01xx46 srcEF | 005046
01xx46 srcTM | 005046
01xx46 srcTU | 005046
01xx46 srcAST | 005046
012746
[byte] 27 ; dic
[byte] 5 ; dpb size
104377
Развлечения продолжаются... :)
- - - Добавлено - - -
Глядя на картинку выше - так и хочется всё это дело описывать и мнемониками команд, но.. к такому подвигу пока не готов :)
Возможно(!) - для стандартных процедур и кусков кода сделаю что-то промежуточное - будет браться листинг и допиливаться под шаблон с сохранением какой-то информации, но... пока не думал на эту тему
Приведённой выше картинки и шаблону не верить - сразу две ошибки - в шаблонке и в обрабатывающем коде :)
Правильно должно быть так:
:)Код:N14576:
MRKT$S #30, R0, #2
Набросал несколько макросов, исправил несколько ошибок :)
- - - Добавлено - - -
В целом - я не знаю, сколько бы описывал эти три макроса при старом подходе.
При новом (если не считать посаженные ошибки) на шаблон макроса уходит меньше минуты :)
19 макросов. Копирую исходник из RSXMAC.SML, дальше беру как образец уже описанный макрос и подрихтую его под новый.
Основное время уходит на проверку результата, так как механизм ещё отлаживается и пока никаких сообщений - что не понравилось в шаблонах :) Или загрузит новые или нет. Или найдёт подходящий или нет :)
- - - Добавлено - - -
В общем и целом - механизм достаточно отлажен и пока чего-то ещё кардинального добавлять вроде не требуется.
Так что попробую добавить отслеживание изменений шаблонов (тех, которые были использованы для генерации макровызово) и автоматическое сначала аннулирование, а затем повторный поиск.
Ну и продолжу добавлять новые шаблоны.
Немного в сторону - некоторые разборки с git - хочу всю ветку, сделанную для проверки нового подхода, перенести в master. Был бы один коммит - вообще не вопрос, а тут несколько и хочу все сохранить. Не сильно большой спец по git, поэтому займёт некоторое время :)
Оказалось, сделать просто - но из командной строки :)
Продолжил развлекаться с шаблонами и дальнейшей разработкой :)