Просмотр полной версии : ZX ассемблер (и не только?) с библиотеками
Кто-нибудь может подсказать какой-нибудь ассемблер для ZX, реализующий/поддерживающий идеологию работы с библиотеками/объектниками, существующую на PC?
Есть ли компиляторы других языков, которые это используют/поддерживают?
Кто-нибудь может подсказать какой-нибудь ассемблер для ZX, реализующий/поддерживающий идеологию работы с библиотеками/объектниками, существующую на PC?
Есть ли компиляторы других языков, которые это используют/поддерживают?
А что конкретно ты имеешь в виду? Сборку из объектников? Или может динамическую линковку кода к другому коду ('библиотеке') с исправлением ссылок? Или наоборот, один код вызывает куски из другого, выбирая адресочки каждый раз из таблички?
Далее - "а зачем тебе?" (c) fyrex
PS: в аласме можно компилять процедуры только если на них были ссылки ранее - что-то вроде IF ?label : label <процедура> : ENDIF, подробнее см. доки.
Vitamin разрабатывая многозадачную ОСь как часть проекта внедрил линковщик объектных файлов, там система очень простая я его подтяну он объяснит как это делается
Но разработка есть
документацию искать на http://zxdocs.fatal.ru в разделе Coding->Module
Microsoft M80.COM/L80.COM под CP/M как раз что требуется
А что конкретно ты имеешь в виду? Сборку из объектников? Или может динамическую линковку кода к другому коду ('библиотеке') с исправлением ссылок? Или наоборот, один код вызывает куски из другого, выбирая адресочки каждый раз из таблички?
Далее - "а зачем тебе?" (c) fyrex
PS: в аласме можно компилять процедуры только если на них были ссылки ранее - что-то вроде IF ?label : label <процедура> : ENDIF, подробнее см. доки.
А чтобы можно было код не в виде исходников ре-юзать... и пр., что лежит в идеологии библиотек...
Не, не в динамике... Линковку сделать...
А там и хорошие библиотеки можно было бы всему народу сдать...
А то не надоело ли всем свой опрос клавы, например, изобретать, а? :-)
и набор по работе с буферами графических экранов.
А чтобы можно было код не в виде исходников ре-юзать... и пр., что лежит в идеологии библиотек...
Не, не в динамике... Линковку сделать...
Ясно. А теперь как ты себе представляешь работу с такой линковкой?
1. откомпилял много сорцов в много объектников, сохранил их на диск.
2. слинковал много объектников в память (не дай бог на диск опять!).
Ну и? Устроишь мегатормозное елозиво по диску с созданием-стиранием файлов? и зах оно нужно? =)
А там и хорошие библиотеки можно было бы всему народу сдать...
А то не надоело ли всем свой опрос клавы, например, изобретать, а? :-)
1. библиотеки делаются в аласме - условной компиляцией по условию 'было ли обращение к метке'. Скомпиляются только те процедуры, к которым есть обращение. Чем не библиотеки? =)
2. При известной доле извращизма можно организовать гибрид динамической и статической линковки: к кодовому блоку (~'объектнику') прилагается файл-заголовк (с определениями меток-процедур и с макросами правки меток под адрес, под который блок инкбинится), а сам блок имеет инит, который правит его под адрес уже при запуске проги.
Наиболее разумен 1ый вариант =)
и набор по работе с буферами графических экранов.
ну, и так далее и тому подобное :-)
Ясно. А теперь как ты себе представляешь работу с такой линковкой?
1. откомпилял много сорцов в много объектников, сохранил их на диск.
Сделал Библиотеку, т.е. собрал их в одно файло, с заголовком-описанием. Или еще как. А хочешь, и так и эдак. :-)
2. слинковал много объектников в память (не дай бог на диск опять!).
Ну и? Устроишь мегатормозное елозиво по диску с созданием-стиранием файлов? и зах оно нужно? =)
1. библиотеки делаются в аласме - условной компиляцией по условию 'было ли обращение к метке'. Скомпиляются только те процедуры, к которым есть обращение. Чем не библиотеки? =)
Тем, что перекомпилировать нужно, не дай бог дам еще конфликты по именам меток и пр. будут... И понеслась - начинаем колбасить чужой код со всеми вытекающими отсюда последствиями...
2. При известной доле извращизма можно организовать гибрид динамической и статической линковки: к кодовому блоку (~'объектнику') прилагается файл-заголовк (с определениями меток-процедур и с макросами правки меток под адрес, под который блок инкбинится), а сам блок имеет инит, который правит его под адрес уже при запуске проги.
Мн... была когда-то в ZX-Ревю опубликована процедурка, которая по таблице меток поправляет код (делает его фактически релоцируемым). Аналог EXE для, скажем, DOS. И методика создания таблицы была описана достаточно просто... Такое можно было бы и в ОСь для ZX включить...
Наиболее разумен 1ый вариант =)
На вкус и цвет... :-)
Сделал Библиотеку, т.е. собрал их в одно файло, с заголовком-описанием. Или еще как. А хочешь, и так и эдак. :-)
ЗАЧЕМ всё собирать в ОДНУ либу? Или ты имел в виду - взял туеву хучу сторонних либ и сидишь на них делаешь? Так и получится елозиво по диску тогда... =)
Тем, что перекомпилировать нужно, не дай бог дам еще конфликты по именам меток и пр. будут... И понеслась - начинаем колбасить чужой код со всеми вытекающими отсюда последствиями...
У тебя начались конфликты ТВОИХ имён с именами сторонних либ (будь то IF ?label или объектники)? ССЗБ, что ещё сказать... =) ...блин, вообще, будь то объектник, или дллка на пц, или ещё что - в любом случае к ней прилагается в том или ином виде список имён - и конфликты начнутся в любом случае.
Мн... была когда-то в ZX-Ревю опубликована процедурка, которая по таблице меток поправляет код (делает его фактически релоцируемым). Аналог EXE для, скажем, DOS. И методика создания таблицы была описана достаточно просто... Такое можно было бы и в ОСь для ZX включить...
И собственно работала она примитивно - для начала брались 2 бинарника под разные адреса (ст и мл байты разные) и сравнивались. Потом генерилась табличка - где что поправить - и правилось. Куда при этом пойдёт не то что org ($+255)&#FF00, а даже просто add a,.label:ld l,a:adc a,'label:sub l:ld h,a , я уж промолчу... ...будет как в зхасме от аига %) И нах такое счастие? =)))
На вкус и цвет... :-)
Угу &^)
ЗАЧЕМ всё собирать в ОДНУ либу? Или ты имел в виду - взял туеву хучу сторонних либ и сидишь на них делаешь? Так и получится елозиво по диску тогда... =)
Имелось ввиду: объектники сгруппированы по 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 , я уж промолчу... ...будет как в зхасме от аига %) И нах такое счастие? =)))
Вспомни время, в которое она была написана. Не было тогда такого продвинутого синтаксиса. Можно бы и сейчас было бы адаптировать ее, но вот если бы компиляторы сами строили таблцы релокаци....
звиняюсь, если повторюсь, но советую глянуть мою разработку- модульную библиотеку.
подключаем необходимый заголовочный файл, пишем исход, заменяя все адресозависимые команды на соответствующие макросы и получаем полностью релоцируемый код, включающий:
-символьные имена для импортируемых точек (для связи с другими модулями)
-символьные имена для экспортируемых точек (функции, переменные, константы)
-поддержку команд типа
ld h,'address
ld a,.another_address
(естесно, замененных макросами)
На спектруме мне кажется библиотеки в принципе не нужны. Если я ими пользуюсь в PC, то это происходит по двум причинам. Прога большая ждать каждый раз когда она скомпилируется не хочется. Вторая удобно разносить функции по разным файлам, потому что прога большая, функций много и все ни друг на друга ссылаются и для того чтобы функции которые заданы могли ссылаться на те которые ниже их по тексту, приходится обозначать их заголовки (притом настолько часто что прога начинает напоминать свалку и исправлять что-то тоже неприятно).
На спектруме программа не такая большая и собирать её приятней если исходник ввиде одного текста чтобы она размеров не теряла. А ALASM (насколько я помню) компилировал всё настолько быстро, что когда прога состояла из нескольких исходниках каждый из которых чуть ли не всю память занимает, но дисковод между подгрузкой исходников просто потухнуть не успевал. Если и делать библиотеки то наверное лучше не ввиде объектных файлов, а ввиде исходников. Просто сделать кучу файлов с функциями, так чтобы асм. мог включать в программу не всё, а только нужные... а саму библиотеку заменить каким нибудь файлом со списком процедур....
звиняюсь, если повторюсь, но советую глянуть мою разработку- модульную библиотеку
А где глянуть-то? =)
звиняюсь, если повторюсь, но советую глянуть мою разработку- модульную библиотеку.
подключаем необходимый заголовочный файл, пишем исход, заменяя все адресозависимые команды на соответствующие макросы и получаем полностью релоцируемый код, включающий:
-символьные имена для импортируемых точек (для связи с другими модулями)
-символьные имена для экспортируемых точек (функции, переменные, константы)
-поддержку команд типа
ld h,'address
ld a,.another_address
(естесно, замененных макросами)
Конечно, спасибо я уже смотрю... :-)
Я достаточно давно не работал на Speccy, вот, решил вернуться к юности и нужно время чтобы "въехать" во все, что изменилось.
Хотя, к моему удивлению, в большинстве своем, люди остались все те же :-)
Спасибо еще раз :-) Я думаю, еще побеспокою своими комментариями на этот счет :-)
На спектруме мне кажется библиотеки в принципе не нужны. Если я ими пользуюсь в PC, то это происходит по двум причинам. Прога большая ждать каждый раз когда она скомпилируется не хочется. Вторая удобно разносить функции по разным файлам, потому что прога большая, функций много и все ни друг на друга ссылаются и для того чтобы функции которые заданы могли ссылаться на те которые ниже их по тексту, приходится обозначать их заголовки (притом настолько часто что прога начинает напоминать свалку и исправлять что-то тоже неприятно).
На спектруме программа не такая большая и собирать её приятней если исходник ввиде одного текста чтобы она размеров не теряла. А ALASM (насколько я помню) компилировал всё настолько быстро, что когда прога состояла из нескольких исходниках каждый из которых чуть ли не всю память занимает, но дисковод между подгрузкой исходников просто потухнуть не успевал.
Если нет таких проблем как на PC - то это просто счастье.
В небольшие программы, нет слов, можно и в исходном коде вставить.
А ежели ты гаму пишешь на несколько спектрумовских страниц?
Хотя, наверное, это скорее исключение, чем правило.
Но - по моему опыту, - именно трудность разработки больших программ часто является причиной того, что их даже не начинаю разрабатывать вообще. Идей много, а довести слабо-структурированный проект до конца - практически без шансов.
Удобные средства разработки, позволяющие эффективно реализовывать объемные задачи - не панацея, но огромное подспорье. (Фу-ты, прямо рекламная фраза какая-то, но так ведь оно и есть...) И code reuse - это одно из основополагающих средств.
Если и делать библиотеки то наверное лучше не ввиде объектных файлов, а ввиде исходников. Просто сделать кучу файлов с функциями, так чтобы асм. мог включать в программу не всё, а только нужные... а саму библиотеку заменить каким нибудь файлом со списком процедур....
Конечно. Иногда это удобнее.
Вообще, наверное, неплохо бы собрать с народа список требований/фич (как по-русски нелиепо-то :-) ) и посмотреть, что есть, а что нет. А еще лучше сделать опросник типа "Что Вам помешало написать программу своей мечты? (Личные причины просьба не приводить)" :-)
Смех-смехом, но, елки-палки, не глупее же Sinclair-истов же люди на PC всякие штуки придумывают... может и подзанять что, а?
Удобные средства разработки, позволяющие эффективно реализовывать объемные задачи - не панацея, но огромное подспорье. (Фу-ты, прямо рекламная фраза какая-то, но так ведь оно и есть...) И code reuse - это одно из основополагающих средств.
ALASM удобное средство =)) Там подгрузил себе исходники на разные страницы и всё хорошо. Меня на профике это очень радовало. Если страницы за пределами 128k. Там во первых и компилировать всё быстрей можно и самое главное запускать. Если что-то и грохнется во время работы, то комп. просто сбрасываешь, исходники в памяти так и остаются. Загрузил alasm и пиши дальше.... Вот его заставить неиспользуемые процедуры выкидывать, это лучше любых линковок будет (хотя может он и умеет уже , хз. у меня версия старая)...
уже давно умеет.
в так называемом файле-библиотеке нужно прописать макро текст с проверкой "а была ли использована эта процедура?" и если всё-таки была - то ассемблировать.
А где глянуть-то? =)
http://www.zxdocs.fatal.ru
Конечно, спасибо я уже смотрю... :-)
Я достаточно давно не работал на Speccy, вот, решил вернуться к юности и нужно время чтобы "въехать" во все, что изменилось.
Хотя, к моему удивлению, в большинстве своем, люди остались все те же :-)
Спасибо еще раз :-) Я думаю, еще побеспокою своими комментариями на этот счет :-)
да не за что. хочется узнать мнение народа на этот счет и выслушать предложения насчет дополнения/расширения. если в итоге дело получится, можно будет попинать алко на предмет внедрения поддержки модульной структуры в аласм (типа инклюда и инкбина только для модулей).
уже давно умеет.
в так называемом файле-библиотеке нужно прописать макро текст с проверкой "а была ли использована эта процедура?" и если всё-таки была - то ассемблировать.
Чего-то такое вроде смутно помню. (воще я диск virtual tr-dos заказал, если придёт посмотрю что там).. Когда хочешь например что-то из одной проги в другую вставить долго приходится возиться. Вставил главную процедуру потом компилиреушь смотришь чего она ещё просит, вставляешь и т.д. Даже если в памяти все тексты - это гимор страшный. Интересно было бы именно если бы он не информировал , а сам вырезал всё что не используется.
A кто что думает о возможности реализации COM на спектруме?
Именно COM. Библиотеки, я согласен с высказанным мнением, действительно
практически бесполезны. Суть COM в заимствовании ЧУЖОГО кода,
ДИНАМИЧЕСКОЙ компоновке. В возможности ОБНОВЛЕНИЯ части этого
самого кода, ввиду ДИНАМИЧЕСКОЙ компоновки, не затрагивая программы
использующие код. Это основное.
По поводу /библиотек/ возможно стоит посмотреть http://cdwalk.narod.ru/modules.html, но -- ЭТО УСТАРЕВШИЙ (безнадёжно)
интерфейс.
http://www.zxdocs.fatal.ru (http://www.zxdocs.fatal.ru/)
да не за что. хочется узнать мнение народа на этот счет и выслушать предложения насчет дополнения/расширения. если в итоге дело получится, можно будет попинать алко на предмет внедрения поддержки модульной структуры в аласм (типа инклюда и инкбина только для модулей).
Народ, если это напргает, может скажет чего на Чего мешает быть счасливым? (О средствах разработки) (http://zx.pk.ru/showthread.php?t=369) ... :-)
A кто что думает о возможности реализации COM на спектрумесначала ось нужна: каталог интерфейсов, централизованное выделение памяти под внешние (для программы) модули и загрузчик перемещаемого кода.
и guidgen проблемно написать без чтения чтения серийных номеров железок. разве что сделать перепись спектрумистов и каждому дать личный номер :)
A кто что думает о возможности реализации COM на спектруме?
Именно COM.
3.579 MHz вам кажется слишком быстрыми? Тогда уж лучше еще на C++ все писать, одна таблица виртуальных методов сколько памяти сожрет...
Плагины в духе BGE - это по моему максимум для 8-битных платформ
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot