Сообщение от jerri
Надо иметь три байта памяти. Ворос -- где их взять?Код:ld hl, NNNN ; push hl, pop hl ld (XX), hl ld hl, XX+2 ld (hl), NN ; ret call XX ... ORG XX XX: DS 3
Надо иметь три байта памяти. Ворос -- где их взять?Код:ld hl, NNNN ; push hl, pop hl ld (XX), hl ld hl, XX+2 ld (hl), NN ; ret call XX ... ORG XX XX: DS 3
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Речь про то, как отличить АБСОЛЮТНО ВСЕ ВЫЗОВЫ, от нужных.
Вот как здесь, вручную, да можно. Но можно элементарно ошибиться
и записать код по-старому. Со всеми вытекающими последствиями.
Другое дело, можно создать макросы вида CALL, JP, LD и т.п...
Но это не всякий ассемблер позволит и сложность всей этой
макрообвязки получится сопостовимой с написанием собственного
ассемблера...
Так...
Я уже загруз по уши... Ну, можно доходчиво мне объяснить так, чтоб я сказал: да моя прога, что пишу без этого всего не может - завтра же беру релокации и навороты, вставляю - и благодаря этому архиБыстро и легко доделываю свое произведение...
согласен. но аласм+макросы=hitech-c=ma80=m80=СРЕДСТВО РАЗРАБОТКИ
дающее на выходе одно и то же.
а создавать таблицу релокации по двум разным кодам- это еще больший изврат!
гм. интересно, какое из двух слов связки ALASM+macro вызывает приступ аллергии? щаз выясним...
как насчет предложения TASM+macro?
За ma80 не скажу, но вроде там специально ничего не предусмотрено. А с макросами -- тот же ALASM получается.
У hitech-c возможности ограничены только созданием таблицы релокации, для настройки кода на адрес, не более того.
А вот у ZASM -- нет ничего. Макросы есть, но ограниченные,
такого не позволяют.
Тем не менее -- оно работает, и оно доступно. Я беру любойа создавать таблицу релокации по двум разным кодам- это еще больший изврат!
ассемблер и элементарно это делаю. Хоть в GENS, хоть в ZASM.
Вот в ZASM и делал, пока на Hitech не перешёл. Но hitech -- это
в писюке (или CP/M). А ZASM -- на спектруме.
ALASM. ИБО ЗАСТАВИТЬ ПИСАТЬ СЕБЯ ТЕКСТ ИСКЛЮЧИТЕЛЬНОгм. интересно, какое из двух слов связки ALASM+macro вызывает приступ аллергии? щаз выясним...
ЗАГЛАВНЫМИ БУКВАМИ, В ИСКЛЮЧИТЕЛЬНО НЕВОЗМОЖНОМ, В ПЛАНЕ "ЮЗАБИЛИТИ" РЕДАКТОРЕ Я СЕБЯ НЕ МОГУ. Потому, что на рядом стоящем писюке есть нормальный редактор. И есть более-менее терпимый в ZASM.
И вопрос отнюдь не в GUI-интерфейса ZASM'a -- в писюке Vim в
xterm.
TASM последний раз видел в 1997 году. Как раз ZASM 3.0 тогдакак насчет предложения TASM+macro?
появился.
а большее разве нужно? какая стоит цель?
на входе: исходный текст программы
на выходе: объектный код, который в идеале можно грузить по любому адресу (с предварительной настройкой соотвецно)
метод реализации: ЛЮБОЙ!!! в том числе и макросы, кросскомпилеры, ручная обработка, сравнение бинарников.
ну уж таким его создал автор изначально. можно попросить алко чтоб сделал поддержку маленьких букв редактором и компилятором (он различает регистр мнемоник).
Цель такова, что вот есть N релоцируемых программ. Мы их загружаем
в память, настраиваем, и они каким-то образом начинают вызывать функции друг друга (из других программ, модулей, библиотек). При
том, что до загрузки ничего не известно, что по каким адресам располагается. Существует три, уже 100 раз тут писалось, метода:
1) используя функцию диспетчер, аргументом которой является
"идентификатор функции" в "чужом" программном модуле.
Это так называемый вызов через RST в том числе. Хотя можно
и через CALL, как, например, в CP/M -- CALL 0x05, а в регистре
C -- номер функции. Детали реализации скрываются за
функцией-диспетчером -- поэтому, возможно, это слишком
общий метод и его сравнивать с остальными не совсем
корректно. Но вот тормозной он -- это точно.
2) Прямой вызов. Для этого все CALL, JP, и даже LD HL, xxx и т.п.
должны быть пропатчены в вызывающей программе после
загрузки всех модулей. Требует формирования сложных
таблиц для патчей создаваемых сложной системой макросов
поверх ассемблера, или специальным ассебмлером. Требует
дисковой памяти порядка sum(Ki)+sum(Mi), где Ki -- число
вызовов внешних функций в i-том модуле, а Mj -- общее
число экспортирующихся функций в j-том модуле. Памяти
ОЗУ после настройки не требует. Но Ki -- достаточно велико.
3) Вызов через функцию-перенаправитель. Для каждой функции
из вызываемого модуля в вызывающий модуль ещё на этапе
компиляции включается специальная функция, состоящая
из одной команды JP xxx. Все вызовы к функциям "чужого"
модуля адресуются к этим функциям-перенаправителям.
А сами функции-перенаправители патчатся, после загрузки,
так, чтобы инструкция JP xxx указвала на действительный адрес
функции из вызываемого модуля. Данный способ отличается
от предыдущего тем, что вызов тормозней на 10 тактов и
памяти ОЗУ требует порядка sum(Mi)+sum(Nj), где Mi -- общее
число экспортируемых функций в каждом i-том вызываемом
модуле, Nj -- число внешних вызываемых функций в каждом
j-том вызывающем модуле.
Считаю, способ N3 наиболее перспективный. Он позволяет относительно легко в любом ассемблере получить нужный код,
он не накладывает чрезмерных накладных расходов на совершения
вызова функций, не требует много памяти как дисковой, так и ОЗУ.
Хотя по использованию ОЗУ он, проигрывает остальным методам.
Со способом N2 сравнивать бесполезно (0 байт), против способа
N1 проигрыш составляет порядка трёх байт на каждую вызываемую
внешнюю функцию в каждом модуле. При общем числе функций
порядка десятков, максимум сотни-другой, это вполне допустимый,
с моей точки зрения, расход памяти.
Способ N2 исключительно сложен в реализации, и требует
специальной поддержки от ассемблера, поэтому, с моей точки
зрения, в общем случае не применим и имеет смысл в каких-то
специфических случаях, например, когда исключительно критично
время вызова функции.
Способ N1 даёт слишком большие накладные расходы на вызов
функий и поэтому, аналогично, имеет смысл, опять же с моей точки
зрения, исключительно в специфических ситуациях. Например,
где время некритично, но очень критичен объём занимаемой
программной памяти.
Короче что-то мы отвлеклись от темы и полезли в дебри.
Надо уже что-то начинать.
Давайте откроем отдельную тему и назначим координатора, который прислушиваясь к мнению остальных будет выбирать из множества решений некоторое одно.
И остальные будут руководствоваться решениями координатора (иначе не будет никакой коллективной работы).
Если вы ещё с нами, тогда вперёд, иначе не вперёд ^_~
Для начала выберем координатора. Предлагайте кандидатуры, а CityAceE пескай выберет кого- нибудь одного.
1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Наиболее известное - TargeT. Шарю в написании больших проектов (правда не на спеке, но думаю опыт пригодится).
Я за твою кандидатуру. Ведь дело даже не в опыте, хотя он безусловно очень важен, а ещё и в заинтересованности (увлеченности)...
С уважением, Станислав.
Тебе начинать хоть прямо сейчас никто не мешает, не думал?
Для этого не нужно ровно ничего.
Иными словами давайте поиграем в коммунизм. Я против коммунизма. Он даёт исключительно советские решения на выходе.Давайте откроем отдельную тему и назначим координатора, который прислушиваясь к мнению остальных будет выбирать
Вот этого я и боюсь. Одно, исключительно советское в худшемиз множества решений некоторое одно.
смысле этого слова: ни с чем не совместимое, и исключительно горбатое. И избавиться от него потом ну никак нельзя будет.
Ключевое слово *ОДНО*. Я бы предоставил свободу выбора
авторам программ. По крайней мере можно было бы посмотреть
какое решение приживётся эволюционным путём, а не посредством
насаживания свыше. Другое дело -- совместимость. Хотелось бы
иметь некий базовый уровень, от которого могли бы происходить
вариации по разным направлениям, но так чтобы тем или иным способом была возможность преобразования интерфейса к нужному
виду. Хотелось бы отделить интерфейс вообще от деталей его
реализации.
Вот возьми и напиши. Не в ассемблере, а свое видение проблемы организации программных интерфейсив, их несовместимости и возможности преобразования из несовместимых в совместимые,1) Я. Много писал (и сейчас пишу ^_~) на спектруме. Наиболее известное - TargeT. Шарю в написании больших проектов (правда не на спеке, но думаю опыт пригодится).
и наконец проблемы идентификации интерфейсов.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
[