ZX ассемблер (и не только?) с библиотеками

[lvd]

Сделал Библиотеку, т.е. собрал их в одно файло, с заголовком-описанием. Или еще как. А хочешь, и так и эдак. :-)

ЗАЧЕМ всё собирать в ОДНУ либу? Или ты имел в виду - взял туеву хучу сторонних либ и сидишь на них делаешь? Так и получится елозиво по диску тогда... =)

Тем, что перекомпилировать нужно, не дай бог дам еще конфликты по именам меток и пр. будут... И понеслась - начинаем колбасить чужой код со всеми вытекающими отсюда последствиями...

У тебя начались конфликты ТВОИХ имён с именами сторонних либ (будь то IF ?label или объектники)? ССЗБ, что ещё сказать... =) ...блин, вообще, будь то объектник, или дллка на пц, или ещё что - в любом случае к ней прилагается в том или ином виде список имён - и конфликты начнутся в любом случае.

Мн... была когда-то в ZX-Ревю опубликована процедурка, которая по таблице меток поправляет код (делает его фактически релоцируемым). Аналог EXE для, скажем, DOS. И методика создания таблицы была описана достаточно просто... Такое можно было бы и в ОСь для ZX включить...

И собственно работала она примитивно - для начала брались 2 бинарника под разные адреса (ст и мл байты разные) и сравнивались. Потом генерилась табличка - где что поправить - и правилось. Куда при этом пойдёт не то что org ($+255)&#FF00, а даже просто add a,.label:ld l,a:adc a,'label:sub l:ld h,a , я уж промолчу... ...будет как в зхасме от аига %) И нах такое счастие? =)))

На вкус и цвет... :-)

Угу &^)

[shade]

ЗАЧЕМ всё собирать в ОДНУ либу? Или ты имел в виду - взял туеву хучу сторонних либ и сидишь на них делаешь? Так и получится елозиво по диску тогда... =)

Имелось ввиду: объектники сгруппированы по Lib-ам. Libs, естественно, больше чем одна, но и меньше, чем объектников. Елозиво - только перед тем, как запустишь. Да и то: 1) считать заголовки библиотек 2) считать необходимый код. Естественно, дольше, чем один исходник - за все приходится расплачиваться раньше или позже. Что получается как advantage? См. "зачем нужна раздельная компиляция/библиотеки".
Тем более, если в твоем исходнике сть ошибки времени компиляции, то до "елозива" не дойдет. А скомпилируется быстрее.
Кстати, тоже неплохая идея иметь библиотеки исходников, подгружаемые в первый раз и подстраиваемые для компиляции твоей программы. Оба варианта библиотек имеют и свои плюсы и минусы. А не нравится - вообще не ешь :-) (это из серии "чего-то мне сегодня наша бабушка не нравится...")

У тебя начались конфликты ТВОИХ имён с именами сторонних либ (будь то IF ?label или объектники)? ССЗБ, что ещё сказать... =) ...блин, вообще, будь то объектник, или дллка на пц, или ещё что - в любом случае к ней прилагается в том или ином виде список имён - и конфликты начнутся в любом случае.

Вспомним С(С++). При использовании пре-компилированного кода, конфликты времени компиляции возникают только для "заголовков". В данном случае - для имен меток начала библиотечных кусков кода (бог с ним, буду называть их по-старинке - процедурами, ок?)
А вот внутренние метки "процедур" - в случае раздельной компиляции никого не трогают. Их просто нет, как элементов синтаксиса кода.
Подстройка библиотек исходников также должна переименовывать/создавать уникальные метки... Ну, это очевидные детали.

Возможны еще проблемы времени линковки (там, ambiguty и т.п., но это - то же самое, только в профиль)

И собственно работала она примитивно - для начала брались 2 бинарника под разные адреса (ст и мл байты разные) и сравнивались. Потом генерилась табличка - где что поправить - и правилось. Куда при этом пойдёт не то что org ($+255)&#FF00, а даже просто add a,.label:ld l,a:adc a,'label:sub l:ld h,a , я уж промолчу... ...будет как в зхасме от аига %) И нах такое счастие? =)))

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

[Vitamin]

звиняюсь, если повторюсь, но советую глянуть мою разработку- модульную библиотеку.
подключаем необходимый заголовочный файл, пишем исход, заменяя все адресозависимые команды на соответствующие макросы и получаем полностью релоцируемый код, включающий:
-символьные имена для импортируемых точек (для связи с другими модулями)
-символьные имена для экспортируемых точек (функции, переменные, константы)
-поддержку команд типа
ld h,'address
ld a,.another_address
(естесно, замененных макросами)

[Proteus]

На спектруме мне кажется библиотеки в принципе не нужны. Если я ими пользуюсь в PC, то это происходит по двум причинам. Прога большая ждать каждый раз когда она скомпилируется не хочется. Вторая удобно разносить функции по разным файлам, потому что прога большая, функций много и все ни друг на друга ссылаются и для того чтобы функции которые заданы могли ссылаться на те которые ниже их по тексту, приходится обозначать их заголовки (притом настолько часто что прога начинает напоминать свалку и исправлять что-то тоже неприятно).

На спектруме программа не такая большая и собирать её приятней если исходник ввиде одного текста чтобы она размеров не теряла. А ALASM (насколько я помню) компилировал всё настолько быстро, что когда прога состояла из нескольких исходниках каждый из которых чуть ли не всю память занимает, но дисковод между подгрузкой исходников просто потухнуть не успевал. Если и делать библиотеки то наверное лучше не ввиде объектных файлов, а ввиде исходников. Просто сделать кучу файлов с функциями, так чтобы асм. мог включать в программу не всё, а только нужные... а саму библиотеку заменить каким нибудь файлом со списком процедур....

[lvd]

звиняюсь, если повторюсь, но советую глянуть мою разработку- модульную библиотеку

А где глянуть-то? =)

[shade]

звиняюсь, если повторюсь, но советую глянуть мою разработку- модульную библиотеку.
подключаем необходимый заголовочный файл, пишем исход, заменяя все адресозависимые команды на соответствующие макросы и получаем полностью релоцируемый код, включающий:
-символьные имена для импортируемых точек (для связи с другими модулями)
-символьные имена для экспортируемых точек (функции, переменные, константы)
-поддержку команд типа
ld h,'address
ld a,.another_address
(естесно, замененных макросами)

Конечно, спасибо я уже смотрю... :-)
Я достаточно давно не работал на Speccy, вот, решил вернуться к юности и нужно время чтобы "въехать" во все, что изменилось.
Хотя, к моему удивлению, в большинстве своем, люди остались все те же :-)

Спасибо еще раз :-) Я думаю, еще побеспокою своими комментариями на этот счет :-)

[Advertiser]

[shade]

На спектруме мне кажется библиотеки в принципе не нужны. Если я ими пользуюсь в PC, то это происходит по двум причинам. Прога большая ждать каждый раз когда она скомпилируется не хочется. Вторая удобно разносить функции по разным файлам, потому что прога большая, функций много и все ни друг на друга ссылаются и для того чтобы функции которые заданы могли ссылаться на те которые ниже их по тексту, приходится обозначать их заголовки (притом настолько часто что прога начинает напоминать свалку и исправлять что-то тоже неприятно).
На спектруме программа не такая большая и собирать её приятней если исходник ввиде одного текста чтобы она размеров не теряла. А ALASM (насколько я помню) компилировал всё настолько быстро, что когда прога состояла из нескольких исходниках каждый из которых чуть ли не всю память занимает, но дисковод между подгрузкой исходников просто потухнуть не успевал.

Если нет таких проблем как на PC - то это просто счастье.
В небольшие программы, нет слов, можно и в исходном коде вставить.
А ежели ты гаму пишешь на несколько спектрумовских страниц?
Хотя, наверное, это скорее исключение, чем правило.
Но - по моему опыту, - именно трудность разработки больших программ часто является причиной того, что их даже не начинаю разрабатывать вообще. Идей много, а довести слабо-структурированный проект до конца - практически без шансов.

Удобные средства разработки, позволяющие эффективно реализовывать объемные задачи - не панацея, но огромное подспорье. (Фу-ты, прямо рекламная фраза какая-то, но так ведь оно и есть...) И code reuse - это одно из основополагающих средств.

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

Конечно. Иногда это удобнее.
Вообще, наверное, неплохо бы собрать с народа список требований/фич (как по-русски нелиепо-то :-) ) и посмотреть, что есть, а что нет. А еще лучше сделать опросник типа "Что Вам помешало написать программу своей мечты? (Личные причины просьба не приводить)" :-)

Смех-смехом, но, елки-палки, не глупее же Sinclair-истов же люди на PC всякие штуки придумывают... может и подзанять что, а?

[Proteus]

Удобные средства разработки, позволяющие эффективно реализовывать объемные задачи - не панацея, но огромное подспорье. (Фу-ты, прямо рекламная фраза какая-то, но так ведь оно и есть...) И code reuse - это одно из основополагающих средств.

ALASM удобное средство =)) Там подгрузил себе исходники на разные страницы и всё хорошо. Меня на профике это очень радовало. Если страницы за пределами 128k. Там во первых и компилировать всё быстрей можно и самое главное запускать. Если что-то и грохнется во время работы, то комп. просто сбрасываешь, исходники в памяти так и остаются. Загрузил alasm и пиши дальше.... Вот его заставить неиспользуемые процедуры выкидывать, это лучше любых линковок будет (хотя может он и умеет уже , хз. у меня версия старая)...

[bugsy]

уже давно умеет.
в так называемом файле-библиотеке нужно прописать макро текст с проверкой "а была ли использована эта процедура?" и если всё-таки была - то ассемблировать.

[Vitamin]

А где глянуть-то? =)

http://www.zxdocs.fatal.ru

Конечно, спасибо я уже смотрю... :-)
Я достаточно давно не работал на Speccy, вот, решил вернуться к юности и нужно время чтобы "въехать" во все, что изменилось.
Хотя, к моему удивлению, в большинстве своем, люди остались все те же :-)

Спасибо еще раз :-) Я думаю, еще побеспокою своими комментариями на этот счет :-)

да не за что. хочется узнать мнение народа на этот счет и выслушать предложения насчет дополнения/расширения. если в итоге дело получится, можно будет попинать алко на предмет внедрения поддержки модульной структуры в аласм (типа инклюда и инкбина только для модулей).