Почему компилированный Бейсик выполняется быстро?

[Barmaley_m]

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

Наверно, кто-то задумывал портировать на них Microsoft BASIC?

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

Мой бейсик не предназначен для исполнения на Z80 (иначе было бы больше смысла запрограммировать его на ассемблере, а не Си). К тому же, C-версия где-то заточена под 32-битную архитектуру процессора. Даже если удастся скомпилировать под Z80 - то скорость вряд ли будет приемлемой.

Но на любом компе с виндой или линуксом тестировать - без проблем. В проект включены файлы проекта Eclipse CDT. Скачиваете и ставите Eclipse, открываете проект, выбираете конфигурацию Debug или Release - и в путь! Для винды может потребоваться в конфигурации проекта заменить Builder с Linux GCC на MinGW GCC.

И пара вопросов: размеры 12Кбайт это только для STM-ки?

Это для STM-ки, и очень приблизительно. Это разность размеров проекта с вызовом функции basic_main_interactive_prompt() и без него. Но подтягивается не только сам бейсик. Подтягивается еще и printf() с выводом дробных чисел, а она сама по себе тяжелая.

Вообще преобразование чисел с плавающей запятой между двоичной и десятичной формами - трудная задача. Та функция преобразования из текста в float, что включена в интерпретатор - я ее поставил, скрепя сердце, переведя оригинальную процедуру Altair BASIC с ассемблера на Си. По крайней мере, удалось сохранить ту точность, что была. Но так вообще преобразование неточное. Я пытался сделать лучше, но понял, что точное преобразование (до ближайшего представимого float-числа) можно реализовать только с применением длинной арифметики (MPI). Хотя у меня и есть соответствующая библиотека (https://github.com/mborisov1/rsa_embedded), решил пока не заморачиваться, чтобы выпустить проект быстрее.

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

Можно ли ожидать уменьшения объема на простых 8-ми битных платформах?

Не знаю. С одной стороны, плотность кода у Z80 выше. Но требуется хороший компилятор, а с ними на Z80 напряженка, как я слышал. Кроме того, Си-код бейсика рассчитан на 32-битную архитектуру процессора. На 8 битах будет неэффективно. Если требуется компактный бейсик на Z80 - то проще портировать Altair или Microsoft BASIC прямо, не уходя от ассемблера. Тем более, что процессор совместимый.

Сколько часов (дней/ночей) ушло на текущую версию?[/FONT][/SIZE]

Первый коммит в свой (неопубликованный) репозиторий я сделал 19 ноября 2023. Где-то 3-4 вечера в неделю уделял проекту. Всего сделано 110 коммитов. Под новогодние каникулы - каждый день помногу. Сколько часов... Ну, по грубым прикидкам, полмесяца полной занятости. Может, 3/4. И плюс еще время фоновых размышлений, когда за компом непосредственно не сидел.

В общем, нормальный такой проект, не слишком большой, но и не слишком маленький. Может быть, дойдут руки допилить его до функционала 8K BASIC. Или даже расширения сделать для возможности управления железом. Может получиться неплохой "старт-пакет" для начинающих программистов на микроконтроллерах. Ведь чем хорош бейсик - можно исполнять команды в интерактивном режиме, чередуя их с кусками программы. И нет опасности, что система завалится - по ошибке вылетит, и все. Если программа зависнет - есть кнопка Break. В "железном" проекте на Nucleo-F412 как раз задействовал для этого кнопку на плате.