Немного про одну заморочку бейсика (и последующий хитпарад глюков) (Страница 3 из 3)

Ассемблерный файл генерируемый компилятором получается типа I. Но является не Integer Basic псевдокодом, а специальным форматом для S-C ASSEMBLER 4.0/S-C MACRO ASSEMBLER II:

Выглядит так:

Ассемблер был достаточно известен в те годы, существовал для многих платформ. Листинги в его формате встречаются и сегодня. Имеет много специфических директив (все они двухбуквенные) с расширенными возможностями, которыми хвастается сегодняшний ca65. На скриншоте выше видно две из них:
.HS 123456 = hex string, аналог .db 12h,23h,56h
.DA label = define address. аналог .dw label

Чтобы его транслировать из файла токенов в обычный текст (@Voldamar0: кстати, может есть желание добавить  просмотр и экспорт таких файлов в dos33core?), я не придумал ничего лучшего, как грузить accемблер (BRUN ASM, подсказка системы изменитcя с "]" на ":"), загружать ассемблерный текст (LOAD C.A), делать перенаправление вывода на принтер (PR#1, в эмуляторе Олега вывод в файл работает, в отличие от ввода из файла) и давать команду LIST (да да, аналогично Бейсику) для просмотра ассемблерного исходника.
---------------------
Теперь подводя итоги. Я даже не стал смотреть другие Бейсик-компиляторы - они все проиграют этому компилятору как в скорости, так и в размере скомпилированного кода (для Flash можно не включать неиспользуемые модули, напр., убрать всю Apple hi-res поддержку, в итоговом бинарнике). Итоговый файл с print hello занимал меньше 100h байт (без включения runtime модуля). Для грубой отвязки вашей Бейсик программы от Бейсика и вообще от DOS годится - при определенном усилии через правку текста исходника (избавление от нецелочисленной арифметики и специфических для железа команд) и правки исходников рантайм модулей результат может быть достигнут. Причем для текстов Бейсиков под любые 6502 платформы - все они в конечном итоге являются OEM версиями MicroSoft Floatpoint Basic.
Но у вообще всех 6502 компиляторов (для apple ][, commodore 64, кроссплатформенных современных итд) одна главная проблема - нехватка регистров общего назначения и слишком маленький аппаратный стек для хранения в нем параметров, локальных переменных итд.
Ровно с теми же самыми трудностями не может справиться cc65 (последняя правка в его исходниках датируется 2021 годом) - в нем используются только 2 регистра общего назначения из трех доступных - A и Х, причем как пара толь ко для одной переменной (по стандарту второй параметр всегда передается через стек, для cc65 через эмуляцию стека), описатель Register используется для эмуляции РОН в ячейках памяти нулевой страницы, причем выделяется максимум 6 байт...
Аналогично стек - единственное отличие Flash! от CC65 - в последнем используется настоящий аппаратный стек для вызовов подпрограмм... Но при этом параметры и локальные переменные хранятся в софтверном стеке. И типичный запуск функции с несколькими параметрами превращается в адовый ад - только первый первый параметр (8 или 16 бит) может передаваться через реальные регистры, дальше параметры копируются в эмулируемый стек, откуда вызываемая функция их копирует в "регистры" (ячейки памяти в нулевой странице) и в локальные переменные (ячейки в эмулируемом стеке)... Про это все можно только сказать, что оно в принципе работает, но не более того.
Flash! использует A:Y пару, cc65 использует A:X. Последний может дать чуть более оптимизированный по времени выполнения код - но отличие меньше чем в два раза. При стечении звезд cc65 (которые компилирует в 1 проход и не использует высокоуровневую оптимизацию в принципе) может умудриться оформить внутренний простейший цикл через реальный регистр процессора, Flash! на это в принципе неспособен - стек вызовов и NEXT/FOR цикл у него в эмулируемом стеке. Вторая проблема Flash! и любых компиляторов Бейсика - невозможность ограничить размер цифровых переменных 8 битами - любая арифметика делается через 16 бит.