Кроссассемблеры для 8080?

[Lavr]

Прочитав имеющиеся у меня описания, могу сделать вывод, что в "Орионовских" ассемблерах возможны столько действий сложения и вычитания, сколько уместится в текстовой строке на 64 символа. Авторы в описаниях не уделяли внимания этому вопросу, видимо, это было не актуально тогда.

Да это и со стороны пользователя не очень актуально, но с точки зрения автора ассемблера
вопрос озадачивает...
Поскольку я сейчас переделываю упомянутый выше ассемблер под новые изменения в
системе команд, - меня этот вопрос и озадачил...

У меня есть исходные коды ассемблеров "Микрон" и "Асм_МХ" "Специалиста", в них
я не нашел признаков ограничения, но еще в одном исходнике ассемблера нашел, что
вложение ограничено 8-ю знаками...
Если превысить, то выдается ошибка:

Code: Select all

"Expression Too Complex"

Я, честно говоря, считаю, что 8 операций в строке аргумента более чем достаточно,
так что, вероятно, остановлюсь на этом числе...

[Lavr]

Попалась мне тут целая коллекция ассемблеров...

A Collection of CPM and MSDOS based 8080/Z80/8086 Assemblers

К сожалению, мне ни один не знаком...

[Lavr]

могу сделать вывод, что в "Орионовских" ассемблерах возможны столько действий сложения и вычитания, сколько уместится в текстовой строке на 64 символа.

А ни у кого нет случаем корректно дизассемблированного исходника ASM "Микрон"?
Так не охота его декомпилировать в отпуске... а вопрос порешать бы надо, пока время есть...

[esl]

Попался тут zmac
Он умеет .8080

http://members.shaw.ca/gp2000/beamhack3.html

Впечалило пару забавных функций типа подсчёта тактов
И возраст исходника

[Lavr]

Попался тут zmac. Он умеет .8080

Да у меня проблема с обработкой строк, включающих простые выражения, содержащие
сложение, вычитание, скобки и т.д. ...

Если бы сориентироваться на что-то конкретное, я бы и сам уже написал.
Но пока сошлись во мнении, что стандарт - это ассемблер "Микрон", который
обрабатывает строку в 63 символа, каким бы там ни было математическое выражение.

Поскольку в описаниях Ассемблеров об этом говорится вскользь и неявно - хотел выяснить
общее правило на этот счет хотя бы по исходнику.

[esl]

Да у меня проблема с обработкой строк, включающих простые выражения, содержащие
сложение, вычитание, скобки и т.д. ...

не понял вопроса, вроде это zmac нормально с арифметикой работает
и

[Lavr]

не понял вопроса, вроде это zmac нормально с арифметикой работает

Да я понимаю, что многие из них "нормально с арифметикой работают".

Мне нужно ориентировочное правило для понятия "нормально".

То есть, если у меня в строке есть арифметические выражения, какова их примерная
сложность и уровень вложения?

Ну, скажем, я пишу:

Code: Select all

const   db (label1 + label2)/3...

какой сложности может быть это выражение в принципе?

[esl]

не понял вопроса, вроде это zmac нормально с арифметикой работает

Да я понимаю, что многие из них "нормально с арифметикой работают".

Мне нужно ориентировочное правило для понятия "нормально".

То есть, если у меня в строке есть арифметические выражения, какова их примерная
сложность и уровень вложения?

Ну, скажем, я пишу:

Code: Select all

const   db (label1 + label2)/3...

какой сложности может быть это выражение в принципе?

ээ, если речь идёт именно про КРОС, то любой имхо
памяти у кросс платформы хватит то ...

[Lavr]

Ну, скажем, я пишу:

Code: Select all

const   db (label1 + label2)/3...

какой сложности может быть это выражение в принципе?

ээ, если речь идёт именно про КРОС, то любой имхо памяти у кросс платформы хватит то ...

Ну это мы сейчас по 2-му кругу пойдем: сначала "любой", а потом - "спроси у автора"...

Автор Pretty 8080 assembler даже какую-то редкостную книжку выискивал,
чтобы на стандарты сориентироваться...

Когда начинаешь проверять отдельный экземпляр ассемблера, то получается, что и "не любой".
Я брал этот Pretty 8080 assembler за образец того, что мне надо, по ряду причин.
Ну и мне как-то уж поднадоело делать тесты, смотря в исходник и проверяя, где ассемблер выдаст ошибку.
Поэтому я и решил к каким-то границам всё свести - мы здесь пришли к выводу, что можно считать "Микрон"
за некий "стандарт".
Ну хотя бы - безошибочное математическое выражение в 63 символа что-ли... как-то так...

[jdigreze]

Lavr, я вот как то упустил эту тему раньше, так как регулярно пропадаю на несколько месяцев в году.
По моим воспоминаниям, чаще всего длину строки операндов никто не делал больше 255 байт, чаще всего даже меньше. Множество ассемблеров длину операндов ограничивало длиной строки экрана - 80, 64 или даже 32 байта.

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

[Lavr]

По моим воспоминаниям, чаще всего длину строки операндов никто не делал больше 255 байт, чаще всего даже меньше. Множество ассемблеров длину операндов ограничивало длиной строки экрана - 80, 64 или даже 32 байта.

Ну мне в этом случае нужна точна конкретика и я объясню почему на примере.

Скажем, я под "Специалистом" программирую 2 канал таймера на деление 2 МГц до 100 Гц.
Удобно это сделать, на мой взгляд, так:

Code: Select all

BASE EQU 0FFF4H; базовый адрес таймера

        LXI D,2000000/100; делитель для канала 2
        LXI H,BASE+2; укажем на канал 2
        MOV M,E; младший байт делителя - в счетчик
        MOV M,D; старший байт делителя - в счетчик

Видно, где я удобно заюзал арифметику в аргументах.
Но ASM "Специалистa" это не скомпилирует - нет у него деления, к сожалению...

Поскольку компиляторы с ASM-а я писать умею, хотелось бы в этом вопросе тоже прийти к некоторому стандарту.


P.S. Я в общем-то и сам в теории знаю про "дерево", "рекурсивный спуск" и "обратную польскую запись".
Как мы тут договорились, пусть максимальная длина строки будет 64 символа.
А за образец алгоритма я взял исходник Pretty 8080 Assembler - он вроде как хорошо это делает.
Ну и когда я разбирал его алгоритм, выяснил, что он чутка лажает, я написал автору -
тот ответил, что да, есть такой момент... Ну и у меня всё так и осталось нерешенным...

[Lavr]

Вот здесь довольно неплохая статья попалась: Алгоритмы работы Ассемблеров
У неё, правда, нет списка заголовков, и передвигаться по статье надо с помощью стрелок...

По интересующему меня вопросу там, правда, сказано немного:

Адресное выражение может содержать арифметические операции, соображения, касающиеся арифметики в этом случае — те же, что и в адресной арифметике языка C.

[Shaos]

Да каждый автор делает как хочет т.к. это не имеет отношения к ассемблеру как таковому...

[Lavr]

Да каждый автор делает как хочет т.к. это не имеет отношения к ассемблеру как таковому...

Ага... ну да, только "в среднем по больнице" наблюдается некая совместимость и общность.

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

К этому, как показывает поиск, склоняются все авторы - сначала пишут "как хотят" -
"в лоб", потом замечают, что этот их алгоритм неэффекивен, и начинают искать, а что
же советуют по этому поводу профильная литература?
И выясняют, что только что прошлись по граблям, по которым уже прошли многие, зачем-то,
преодолевая трудности, изобрели давно изобретенный велосипед.

И имеет это отношение не только к ассемблеру, как таковому, но и к трансляторам с
многих других языков...

А "как хочет" это ты подразумеваешь "линейный алгорим"? Я лично наблюдаю, что большинство
авторов, в том числе, пишущих об этом статьи, предпочитают "рекурсивный спуск".


P.S. А "правильные правила" по интересующему меня вопросу я сегодня нашел, хотя и потратил
пол-выходного. Теперь дело за тем, чтобы применить их в своих исходниках и заодно посмотреть,
применяли ли их авторы известного пакета "Микрон" и их последователи, или они писали всё же
свой код по методу кто "как хочет"...

[Shaos]

просто вычисление на стеке с учётом приоритета операций и раскрытием скобок

вот как это делал я в конце 90х в своём компиляторе RW1:

http://nedopc.cvs.sourceforge.net/viewvc/nedopc/src/rw1c/rw1_expr.c?revision=1.1.1.1&view=markup