-
Попробовал доописать .ENTER... Блин, юные хакеры из DEC. Самомодифицирующийся код - да без проблем :) Попробую использовать EDIT для экспериментов-отладки :)
- - - Добавлено - - -
Очередной второй шаг
Попробовал доописать .ENTER. В целом предсказуемо отработал без проблем, но выявились недочёты в поведении - не фатальные - при необходимости комбинацией команд Сброс - доп команды - Код всё устраняется, но.. хотелось бы меньше нажатий кнопок-щелчков мыши. Так что запущен процесс устранения, а потом буду доописывать следующий макрос. И смотреть на результат :)
В позапрошлом сообщении ошибся - это был не очередной первый, а очередной второй шаг :)
Первый шаг - чисто кодом
Второй шаг - data driven
Третий шаг - описание во внешнем файле
До третьего надо наиграться с разными вариантами во втором :)
-
Отработку команды Сброс сделал более логичной и поправил визуализацию макровызова, если команда, входящая в его состав как-то меняется. Например, непосредственный аргумент-число меняется на ссылку. Ну и пару косяков-ошибок поправил.
Можно двигаться дальше с добавлением описаниев макросов.
-
Изначально была заложена идея реагирования парсера макро-вызовов на ключвевые команды. Пока ключевая команда только одна - EMT. Точнее, пока только она и используется в блоке описания, но даже сейчас можно использовать какую угодно команду. Но даже в RT 1.15 есть макровызовы, которые используют одинаковый код в EMT и отличаются аргументами. Парсер на основании описания успешно справляется с такими вариантами :)
Пример - .FETCH/.RELEASE
Будет добавлен функционал, когда макро-вызов использует и блок данных (типа AREA у RT или $ вариант у макросов RSX)
11 макросов из примервно 34-ух (когда все опишу - будет понятно - сколько их в макро-библиотеке)
- - - Добавлено - - -
Вдогонку. Когда описание будет перенесено во внешний файл, можно будет настраивать парсинг и под кастомный вариант, как скажем, в EDIT - когда у него свои макровызовы :)
- - - Добавлено - - -
23 макроса описано, 10 осталось - по три варианта .READ и .WRITE и по два .TTYIN и .TTYOUT.
.READ и .WRITE проще (думаю, сегодня сделаю), .TTYIN и .TTYOUT посложней, - над ними ещё подумать надо
-
29 макровызовов
Остались четыре .TTYxxx
Думаю, что начну добавлять макросы из RT 2.x, а в процессе допилю поддержку .TTY, благо они не изменялись.
Ну и поскольку придумал сценарий, где может понадобиться кнопка MCALL, то добавлю и её.
Так же можно начинать обдумывать третий шаг - вынос описания макросов во внешний файл
-
Пока отлаживал генерацию макросов для RT-11 v1.15, смотрел на дизасм PIP и EDIT и по EDIT возникло непонимание. Решил, что битый EDIT.SAV. Но поскольку доскональный дизасм было лениво проводить, решил проверить по быстрому другим путём. Так что встречаем сеанс работы с первой версией RT-11 :)
Код:
.BOO/FOR RK0:
@ 000006
@0G
RT-11 V01-15
.R EDIT
*EWTEST.MAC$$
*I
.TITLE TEST
.MCALL .PRINT
.MCALL .EXIT
START:
.PRINT #DEMO
.EXIT
DEMO: .ASCIZ /RT11 V1.15/
.EVEN
.END START
$$
*EV$$
V01-24
*EX$$
.R PIP
*/L
DTMON .SYS 34 25-JUL-73
MONITR.SYS 34 25-JUL-73
LP .SYS 2 26-JUN-73
RK .SYS 2 28-JUN-73
PR .SYS 2 22-JUL-73
PP .SYS 2 26-JUN-73
DT .SYS 2 26-JUN-73
TT .SYS 2 26-JUN-73
LP .132 2 26-JUN-73
SYSMAC.SML 8 26-JUN-73
PIP .SAV 8 9-JUL-73
EDIT .SAV 15 22-JUL-73
MACRO .SAV 29 26-JUN-73
LINK .SAV 14 9-JUL-73
EXPAND.SAV 12 3-JUL-73
ASEMBL.SAV 21 26-JUN-73
PATCH .SAV 5 26-JUN-73
ODT .OBJ 9 26-JUN-73
PIPC .SAV 12 25-JUL-73
TEST .MAC 1
4570 FREE BLOCKS
*^C
.R MACRO
*TEST=TEST
ERRORS DETECTED: 0
FREE CORE: 19465. WORDS
*^C
.R LINK
*TEST=TEST
*^C
.R PIP
*/D
*/L
DTMON .SYS 34 25-JUL-73
MONITR.SYS 34 25-JUL-73
LP .SYS 2 26-JUN-73
RK .SYS 2 28-JUN-73
PR .SYS 2 22-JUL-73
PP .SYS 2 26-JUN-73
DT .SYS 2 26-JUN-73
TT .SYS 2 26-JUN-73
LP .132 2 26-JUN-73
SYSMAC.SML 8 26-JUN-73
PIP .SAV 8 9-JUL-73
EDIT .SAV 15 22-JUL-73
MACRO .SAV 29 26-JUN-73
LINK .SAV 14 9-JUL-73
EXPAND.SAV 12 3-JUL-73
ASEMBL.SAV 21 26-JUN-73
PATCH .SAV 5 26-JUN-73
ODT .OBJ 9 26-JUN-73
PIPC .SAV 12 25-JUL-73
TEST .MAC 1
TEST .OBJ 1
TEST .SAV 2
4567 FREE BLOCKS
*^C
.R TEST
RT11 V1.15
.
Из занимательного - при работе на полной скорости под эмулятором Патрона - видимо дурит RK (или драйвер - не разбирался), что сопровождается фейерверком проблем, который начинается с того, что портится системный диск :)
С редактором EDIT имел дело только под DOS/Batch-11 в 1984 году, некоторые вещи вспомнились, некоторые - пришлось глянуть в документацию :)
- - - Добавлено - - -
А, да, ещё - до какого-то момента в PIP был функционал, которые потом разделили на PIP и DUP. То есть, скажем, создание системного диска и перезагрузка системы - это был PIP :)
-
После долгой борьбы за использование новых возможностей компилятора и .NET и в ImageUtils и DisAsm-11 для .NET 4.x решил всё таки отказаться от поддержки .NET 4.x.
Так что новые версии пойдут (на текущий момент) только под .NET 6.
И насколько я понял из написанного у MS, это означает Windows 7 sp1 и Windows 2012 минимум. Позднее проверю, на какие версии Windows может встать .NET 6
-
В общем.. Идея, которая нарисовалась в голове, с ходу (даже в .NET 6) не взлетела. Вернулся к предыдущей точке, в том числе - и к поддержке .NET 4.x. Буду ещё думать.
И пока переключусь на PDP-2011, там тоже есть задумки, посмотрим, как с ними получится...
-
Наткнулся на статью на хабре - как дизассеблили (из байт кода) одну прогу на питоне. Пара кусков текста оттуда (лично я IDA не использую, так что написанно - чисто на совести авторов):
"Лично я не догадался, пока не увидел, что функция pyarm, вызываемая между этими двумя действиями, весит целых 50 (!) КБ. Чтобы вы понимали – 1 машинная инструкция на x86-x64 занимает в среднем 4-5 байт, то есть наша функция выполняет более 10 тысяч операций, при этом её декомпилированный код занимает ~146 тысяч строк."
...
Ситуация осложняется размером функций – IDA Pro работает в однопоточном режиме, и если вы попытаетесь переименовать какие-либо переменные в функции pyarm, чтобы обозначить места соответствия с настоящей _PyEval_EvalFrameDefault, то каждый такой небольшой манёвр обойдётся вам в несколько лет (интерфейс IDA Pro зависнет на 3-10 минут при каждом изменении декомпилированного кода)."
То есть получается, что переименование некоего объекта в IDA - проход по всему дизассеблированному тексту и изменение. Ндя.. У меня в DisAsm сделано по другому - вместо получения дизассемблированного текста и работы с ним - на ячейки (байты и слова) выставляются аттрибуты и при отображении на экран (или вывод в генерируемый исходник) DisAsm анализирует аттрибуты и по ним генерирует исходник. Поэтому при изменение метки (а это изменение аттрибута) выполняется мало действий (и я собираюсь сделать их ещё меньше). А когда будет отображаться или выводиться исходник - идёт просмотр - о, текущая команда ссылается на ячейку - а на той ячейки метка есть? - нет - генерируем метку по умолчанию, да - берём заданную метку и подставляем. Всё. Никаких поисков и изменении (будущего) исходника при смене метки :)
-
Видимо, устал от PDP-11X, так как совсем не хотелось что-то делать и думать.
Ну ок, в силу некоторых обстоятельств переключился на XXDP :) А что бы понять - чего там не работает в программе - подсунул в дизасм. А он того.. лабуду лепить начал и падать :) Ну понятно, не постоянно и неповсеместно, но.. всё таки :)
Так что некоторое время шуршу в его коде. Всё замеченное было вычисленно и поправлено. Пока в дизасме одной утилиты (а может и что-то ещё отдизассемблю) из XXDP
-
А как бы заполучить этот ДизАсм11? Товарищ Хунта, поделитесь екзешником. Вещь судя по картинкам нормальная, годная. А где екзешник лежит - неясно.
