Ассемблер для Intel 8080 на TypeScript

[begoon]

Относительно org вычисляются метки, а не адреса переходов. То есть org задает абсолютное смещение для все меток до следующего org.

Так как в i8080 все переходы абсолютные, такой логики достаточно.

[Lavr]

Относительно org вычисляются метки, а не адреса переходов.

Интересно, однако... Значит JMP METKA и CALL METKA - здесь METKA не адрес перехода?

[DmitryMilk]

Относительно org вычисляются адреса переходов. И какой из org берётся за точку отсчёта теперь?
Если у меня на один и тот же адрес jmp после первого org а потом после второго org? (ну или call...)

А в чем проблема-то с несколькими ORG? Адреса меток же по идее должны вычисляться на первом проходе, адрес метки определяется тем ORG, после которого она идет. А после какого ORG расположен CALL или JMP, переходящий по этой метке - не важно, т.к. к моменту второго прохода адреса всех меток уже полностью определены.

Я вот сейчас пишу под Z80, используя sjasm - вот там у меня вообще эквилибристика с метками - и определение одних меток через другие через EQU (смещения в бинарных данных), и даже есть ORG, в котором стоит не прямой адрес, а метка, определенная через EQU от другой метки

[begoon]

Как я уже писал, org - это просто статическое смещение в коде после него, включая, естественно, значения меток.

Можно иметь сколько угодно org’ов.

Конкретно в моем ассемблере есть дополнительные свойства org’ов, которые просто были моим решением.

Например, секции не могут пересекаться по адресам, то есть org’ом в целом нельзя пойти назад.

Или, адреса в org’ах используются при ренерации нескольких выходных файлов, если таковой режим (—split) задан.

Но обычно, если нужен единый файл, то дырки между секциями зануляются.

Все подробнейшим образом описано в документации.

[DmitryMilk]

а эти что дают? Только лишние сущности, КМК.

Я писал под MASM как раз с использованием вот таких конструкций вместо меток и условных переходов - это весьма удобно. Если еще использовать и отсутпы вложенности - ощущается, будто пишешь на ЯВУ.

[begoon]

Именно для этого я if/else и добавил, которые могут быть вложены. И уже не надо вручную делать метки-выходы из условий.

А в сочетании с proc/endp/return для опционального сохранения и восстановления регистров, все еще удобнее.

[Alekcandr]

Добавил поддержку if/else по флагам.

На мой взгляд все эти хитрые конструкции сильно ломают совместимость с классическими ассемблерами. И что мы имеем в сухом остатке? 1000 и 1 ошибку при портировании кода на классический ассемблер.

Впрочем, это дело автора ассемблера, как вариант может он пишет ассемблер исключительно для себя.

[begoon]

Я б сказал, что это больше дело программиста.

Можно использовать чисто классические конструкции. Соображения совместимости на 100% валидны.

Я, например, люблю синтаксис нескольких команд в строке через « / », ибо сильно сокращает вертикальный размер кода, но в плане общей совместимости это точно нет.

[Alekcandr]

Я б сказал, что это больше дело программиста.

Вот, вот программиста

Случай из жизни. Есть исходник, под хитрый ассемблер, к тому же платный. Как перенести код? Простая задача становится не только сложной, но и финансово затратной (купить ассемблер для разового использования).

Я, например, люблю синтаксис нескольких команд в строке через « / », ибо сильно сокращает вертикальный размер кода, но в плане общей совместимости это точно нет.

Это как раз по мне не проблема при переносе.

Ладно я никого не собираюсь поучать, как делать "личный" ассемблер или язык программирования.

[Lavr]

Случай из жизни. Есть исходник, под хитрый ассемблер, к тому же платный. Как перенести код?

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

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

[Lavr]

Относительно org вычисляются адреса переходов. И какой из org берётся за точку отсчёта теперь?
Если у меня на один и тот же адрес jmp после первого org а потом после второго org? (ну или call...)

А в чем проблема-то с несколькими ORG? Адреса меток же по идее должны вычисляться на первом проходе, адрес метки определяется тем ORG, после которого она идет. А после какого ORG расположен CALL или JMP, переходящий по этой метке - не важно, т.к. к моменту второго прохода адреса всех меток уже полностью определены.

Меня всегда удивляет, когда люди такой глупый вопрос задают: А в чем проблема-то ... ?
А я разве где-то написал, что есть проблема?
Мне конкретно было интересно, как автор реализовал множественные ORG.

Автор мне пояснил, хотя что-то навёл тень на плетень "с адресами переходов / метками".

Почему мне это интересно? Когда я писал свой собственный ассемблер для себя, я ввёл специальный оператор, определяющий байт заполнения.
И в некоторых случаях я его выбираю не 00Н, как у Демина, а 0FFH.

А проблемы никакой нет. Ни у меня ни у автора. Просто бывают ассемблеры, которые уже второй ORG не воспринимают...