Нет. Почему -- в соседней ветке и пишется же.Сообщение от Vitamin
[/quote]и к чему тут упоминаются извраты с аласмом не понимаю...
зы. а я хочу интерфейс с аласмом для начала! (как вот заявлено) почему он отвергается?лозунги нарушаем-с %)
Речь не про то, чтобы с аласмом было несовместимо.
Речь про то, чтобы НЕ БЫЛО СОВМЕСТИМО ТОЛЬКО С АЛАСМОМ.
Вот и Griv про BGE вспомнил. Это радует. Поэтому предлагаю без фанатизма - начать с аналогии системы аля BGE. просто процедура и описание: что на входе, что на выходе, можно ли из ПЗУ юзать/нет, сколько регистров херит. И всё. Без прибамбасов. А каменты может не надо прям в исходнике ? Рядом, в текстовичке.
имхо вопрос надо ставить не так. то, что в других компиляторах приходится делать вручную или через >|<опу, в аласме можно сделать автоматически. вот и все.
гдето писалось про траблы создания плагинов к RC- создание таблиц релокации. это можно упростить!
В данном случае, вручную -- это значит НИКАК!.
Таблицы релокации можно создать путём сравнения версий программ
откомпилированных по разным адресам. Кроме того, некоторые
компоновщики штатно умеют (тот же hitech-c). А вот таблицы патчей
для CALL -- это никто не умеет, ALASM+макросы == свой собственный,
ни с чем не совместимый, ассемблер.
MA80 (МОА) и M80 (CP/M) прекрасно умеют макросами создавать таблицы патчей.
Как пример см. драйвер электронного диска под ISDOS by MOA.
хех, вспомнил - в древнючем zx-review была софтинка, которая строила такие таблицы на базе двух скомпиленых под разные адреса блоков одного и того же исходника и присобачивала настройщик. вот только блоки должны умещаться в 48к памяти, да и все равно это полуручная работа
иКод:org #6000 <код> org ($+255)&#FF00 label ds 256
Вот и сравнивай...Код:org #789A <такой же код> org ($+255)&#FF00 label ds 256
--- Кто съел всю уху?
нормальные люди больше одного org'a в одной проге не юзают (object save не работает как минимум). я делаю так:
defs $-(($-1)&ff00) (мож накосячил - не помню =) у меня макрос сто лет назад написан)
а чаще так:
;macros lib
_ORGA equ 0
defmac _ORGG
\0 equ _ORGA
_ORGA equ (_ORGA+\1)
endmac
;end maclib
;prog:
_ORGA=$
_ORGG buf1,#0100
_ORGG buf2,#0300
округление до ровных адресов в макросе добавить по вкусу...
а ты правильно под релокатор пиши!
таблицы такие - генерить на месте или двигать
адрес программы тоже легко узнать
С уважением,
Jerri / Red Triangle.
Нормальные люди вообще DEFS для кода отписываемого на
диск не юзают. Я конечно понимаю, что hrust есть великий
рулез, но тем не менее, ещё с тех времён когда кроме mpack
ничего приличного не было, существовало нормальное решение,
когда все эти DEFS и извраты вокруг ORG затрагивали часть
области данных не отписываемую на диск. Для инициализации
писался код. И кроме того, вместо статического распределения
НИЧЕМ НЕ ХУЖЕ тривиальный аллокатор типа "стек", который
растёт вверх от конца программы. Или даже стек обыкновенный,
для чего он размещается не под телом кодового блока,
а в самом конце памяти. Делается просто: кодовый блок
размещается в REM-строке бейсик программы. А CLEAR ставится
на самый верх памяти. Суть в том, что в двух разных состояниях
программы отдельные статически выделенные блоки памяти
НЕ ИСПОЛЬЗУЮТСЯ и память тратится впустую. (Вот чего вечно
от спектрумистов слышно, что им памяти не хватает). Нормальный
аллокатор решает эту проблему. Её решает даже выделение
памяти на стеке. И выравнивание можно динамически, на ходу
любое выбирать.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием