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

[Lavr]

вот как это делал я в конце 90х:

Сам придумал?

[Shaos]

вот как это делал я в конце 90х:

Сам придумал?

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

[Lavr]

вот как это делал я в конце 90х:

Сам придумал?

Угу - но все примерно так и делают...

Ну вот и я - "угу"... только до твоих 90-х и моих чуть раньше это написали в десятках книжек.

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

А вот это галимая неправда или твоё личное заблуждение. Способ-то как раз не один единственный.
Кстати, в тех же книжках и написано...

[Shaos]

способ по сути один - через стек (рекурсия это тоже стек)

[Lavr]

способ по сути один - через стек (рекурсия это тоже стек)

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


P.S. Что-то мне это напомнило одного деятеля с ZX.PK, который заявил, что все компьютеры
на i8080 - одинаковы... Поскольку в них во всех i8080.
Так и у тебя - что не делай, это - тоже будет стек...

[Shaos]

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

[Lavr]

просто далеко не во всех ассемблерах есть функционал по вычислению выражений - это штука второстепенная...

Ну, как говорится, "я вам не скажу за всю Одессу, вся Одесса очень велика"...
Но замечал я, что JMP $+2 умеют делать очень многие ассемблеры!
И как же они это делают без "функционала по вычислению выражений"?

И, раз уж на то пошло, то примитивы типа JMP $+2 и SHLD METKA+1 запросто
реализуются без всяких стеков линейным разбором строки.
Другое дело, что это не универсальная вещь, да и неудобная, что, собственно, и позвало
меня поискать более оптимальные алгоритмы - об чем и весь сыр-бор тут...

Суть-то в чем? Суть в том - для какой системы мы пишем ассемблер. Если это ассемблер
для кросс-системы, работает на системе с большими ресурсами, там хоть два стека
организуй и неограниченную длину строки.
А если ассемблер для системы, у которой ОЗУ - 48К, и в этом ОЗУ - сам транслятор, исходный
текст и буфер под код, стеки-то особо не размахнешь... Можешь увидеть сообщение "Мало ОЗУ",
если буфер меток переполнится.

Поэтому в доступных мне исходниках я и видел - размер возможного арифметического выражения
ограничивают, если что выдают: "Expression Too Complex".

[jdigreze]

Lavr, у меня где-то были ссылки на теорию, но мне так показалось, что оно тебе не нужно, а практического кода у меня увы нет. В 90-х был, но сплыл, и тот не мой, а хорошего знакомого.
А алгоритмов не один, только общеупотребимых, на сколько я помню, аж три штуки, и один из них как раз рекурсивный.

[petrenko]

...
А если ассемблер для системы, у которой ОЗУ - 48К, и в этом ОЗУ - сам транслятор, исходный
текст и буфер под код, стеки-то особо не размахнешь...

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

[Lavr]

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

Спасибо! Я вчера уж всё нашел, и теорию и экземпляр кода - тут ты меня своим намёком сориентировал верно!

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

Ну а какие правила? Ну вот взяли мы за образец "Микрон", на смену ему, устаревшему и с глюками,
пришел АССЕМБЛЕР «М&S», что он постулирует по интересующему меня вопросу?

Все возможности АССЕМБЛЕРа «МИКРОН» сохранены и добавлены новые:
- введены операции арифметического деления и умножения, а также арифметические операции с символьно заданными псевдооператором DB байтами (например, DB 'А'+80Н);
- допускаются операции арифметического умножения (*, знаковое) и деление (/, беззнаковое);
- все арифметические операции выполняются последовательно, слева направо, БЕЗ ПРИОРИТЕТА;
- допускается использование арифметических операций с байтом, заданным в символьном виде псевдооператором DB, при этом байт должен быть одиночным (допускается: DB 'TES', ' T'+80H и не допускается: DB 'TEST'+80H);
...
Во всем остальном АССЕМБЛЕР «М&S» полностью совпадает с АССЕМБЛЕРОМ «МИКРОН»...

Значит длина строки всё те же 64 символа...

Разбор строки - видно что линейный, т.к. нет приоритетов, а значит и никаких стеков нет.
Но "функционал по вычислению выражений" реализован весьма нехилый!

[Lavr]

просто вычисление на стеке с учётом приоритета операций и раскрытием скобок
вот как это делал я в конце 90х в своём компиляторе RW1:
http://nedopc.cvs.sourceforge.net/viewvc/nedopc/src/rw1c/rw1_expr.c?revision=1.1.1.1&view=markup

А что-то я не увидел, где у тебя используется "вычисление на стеке с учётом приоритета операций и раскрытием скобок".
Хотя даже инструкцию вроде прочитал внимательно: http://robots.chat.ru/rw1_r.html

И ссылка на компилятор RW1 теряется вот здесь: https://sourceforge.net/projects/nedopc

[Shaos]

Это старая инструкция и старый репозиторий

Всё новое - тут: https://gitlab.com/nedopc/sdk/tree/master/robbyc

P.S. В частности про разбор выражений - тут:
https://gitlab.com/nedopc/sdk/blob/master/robbyc/robbyc2.c

[Lavr]

В частности про разбор выражений - тут:
https://gitlab.com/nedopc/sdk/blob/master/robbyc/robbyc2.c

Если я всё правильно помню, размер анализируемой строки напрямую связан с размером стеков.
Это еще jdigreze тут отметил:

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

Я посмотрел свои исходники, и увидел, что на момент этой беседы я алгоритм со стеками
тоже реализовал, но не вставил в окончательный вариант ассемблера - не состыковался
он у меня удобно с существующим уже разбором строки.
В этой связи мне и стало интересно - ты размер стека (aka буфера) у себя сколько задал?

[Shaos]

Судя по коду стек у меня на 1000 элементов создаётся - пока хватало
Строка тоже где-то ограничена была по длине (в другом более головном файле)
На самом деле хардкод подобного рода считается очень плохим тоном среди современных программистов
Ну что есть, то есть - как уж написал в конце 90-х, а переписывать времени нету...

[Lavr]

Судя по коду стек у меня на 1000 элементов создаётся - пока хватало

Вооооо! А у меня всего на 200, но самое смешное, я его не смог превысить своими примерами.
То есть, я не смог подсунуть в алгоритм такой выдуманный, но осмысленный пример, чтобы выйти за 200.

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

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