Бейсики для Вектора-06Ц и клонов

[metamorpho]

По-моему Бейсик на ДВК-1 задавал в начале разные неудобные вопросы типа "НУЖНЫ ЛИ ВАМ РАСШИРЕННЫЕ ФУНКЦИИ?".
А работать со строками он совсем не умел. Ты не ошибся с выбором платформы? =)))

Непонял мысль про "ошибся с выбором платформы". Подозреваю я что-то недопонимаю в компиляции.

Понимание и обработка компилятором строковых переменных и констант входит в основоное ядро кода - и из него ничего
отключить нельзя. А вот строковые функции, о которых я написал, это имеется ввиду функция MID, RIGHT, STR, LEFT и
др. - вот эти функции подключаются только если они нужны.

Мой компилятор-чудо-Бейсик не будет задавать вопросов как на ДВК-1

Конечно возможно я не совсем понимаю внутренности процесса компиляции, но вот как в общих чертах мне
представляется этот процесс на реальном Векторе:
- набираем и записываем в файл код программы как в обычном Бейсике (здесь всё происходит в текстовом редакторе с
некоторыми удобными настройками и подсветкой операторов и т.п.)
- далее запускаем с диска компилятор, который анализирует наш код. Компилятор выявляет все операторы и функции,
которые использует наша программа. Далее компилятор загружает с диска нужные модули (код отдельных функций и
операторов, либо другой вариант - по очереди загружает соответсвующие библиотеки - например библиотека строковых
функций или библиотека работы с графикой - и уже в библиотеке находит нужный код и вставляет его в память или в
темп-файл) и в итоге компилятор собирает все модули, которые используются в нашей программе. Далее в программу
вставляются адреса вызовов функций (с входными и выходными параметрами если нужно).
- далее формируется выходной файл ROM или COM (а ещё можно сделать фишку EXE файл, чтобы запускалось на PC -
тогда будет ретро игра сразу на двух платформах - со всеми пользами и интересностями)

[Advertiser]

[svofski]

Про выбор платформы была шутка. Бейсик на ДВК-1 был хтоническим спавном какой-то одной из древнейших версий Бейсика, которая не далеко ушла от калькулятора.

Что до остального, все это, включая компиляцию в x86, ACK уже предположительно (*) умеет. Отличие только в каких-то деталях синтаксиса и в том, что для Вектора нужно сделать библиотеку. Можно приделать свою в нужном объеме.

*) Предположительно, потому что что-то существенное я им компилировал и запускал только на языке Си. Но пробную программу на Бейсике типа Хелло вродл тоже собрал и работает.

**) Повторюсь, что в случае кросс-компиляции мне остается непонятным выбор языка. Зачем истязать себя Бейсиком, если при этом не сохраняется его основная ламповая фича -- спонтанность и интерактивность? Если сбросить с себя оковы бейсика, открывается путь еще к z88dk.

[svofski]

Функция INT() для меня загадка:

=>
PRINTINT(1.5E33)
 1.5E+33

=>
PRINTINT(5.7)
 5

=>
PRINTINT(-5.7)
-6

С обычными числами он ведет себя как floor(). Странно для отрицательных чисел, но работает как обещано, что ж поделать. А если число с порядком, то типа сам дурак? Как быть?

[Ramiros]

Функция INT() для меня загадка:

=>
PRINTINT(1.5E33)
 1.5E+33

=>
PRINTINT(5.7)
 5

=>
PRINTINT(-5.7)
-6

С обычными числами он ведет себя как floor(). Странно для отрицательных чисел, но работает как обещано, что ж поделать. А если число с порядком, то типа сам дурак? Как быть?

а что не так? 1.5х10^33 это же целое число.

[svofski]

а что не так? 1.5х10^33 это же целое число.

Да, так все и объясняется. Просто я когда думаю "целое", мне представляется целое, которое помещается в переменную целого типа. Которого кроме всего прочего в этом Бейсике и нет.

[ivagor]

Еще поускорял где смог, перечень оптимизаций в readme

- - - Добавлено - - -

Забыл в начале readme исправить номер на 2.71, менять архив из-за такой мелочи не буду, там дальше все правильно.

[svofski]

Слова про z88dk я пожалуй беру обратно. Компилятор глючный как чорт.

[ivagor]

Да, глюков там полно, но если не портировать готовые программы, а писать с нуля, то глюки можно обходить. Это неудобно и неприятно, но скорость откомпилированных программ сравнительно хорошая и даже есть пара библиотек плавучки. SDCC лучше, но ему нужен z80 и искаропки он не знает про вектор (что решаемо).

- - - Добавлено - - -

оффтоп про Си

Прошу прощения за повторение, вроде уже писал, но тут наверно к месту. Когда портировал jpeg, то В КАЖДОМ из 3х попробованных компиляторов обнаружились баги, причем разные. Самый правильный - zpu8080, там был виноват я сам, ошибся в библиотеке. Замечательно, но медленно. Ошибку в SDCC я обошел, а через некоторое время ее исправили, супер, если бы не z80. И только z88dk никто на тему бага не думал править, скорее всего он до сих пор есть. C другой стороны, когда писал в z88dk маленькие тестовые программки, то все было нормально. А вот когда пробовал рейкастер с плавучкой и текстурами, вот там опять полезли иррациональные глюки, которые более-менее решились только когда стала доступна другая (микрософтовская) библиотека плавучки. С "любительскими" компиляторами для не самых популярных ретроплатформ все непросто.

[свернуть]

[svofski]

если не портировать готовые программы, а писать с нуля, то глюки можно обходить

Это может быть так, когда глюки известные и стабильные. Тогда их можно принять как ограничения и с этим жить. Это не только для 8080 так бывает. Но когда один и тот же код в зависимости от вставленного где-то посередине printf(), или выбора опций, работает совершенно по разному, это получается совершенно невозможная путаница. Главное, что ты никогда не знаешь, исправят это в завтрашней версии, или испортят еще хуже. Я бы и рад помочь разработчикам хотя бы хорошим багрепортом, но глюки настолько эзотерические, что я не могу даже привести хороших тестовых примеров. Хотя вообще z88dk ценная вещь и наверняка когда-нибудь глючность его станет незначительной.

Кстати о zpu8080, игру в стиле ANTIGRAV на нем наверное можно забацать и пошустрее, чем получилось на Бейсике. Но процесс разработки боюсь не для всех =)

[ivagor]

Главное, что ты никогда не знаешь, исправят это в завтрашней версии, или испортят еще хуже.

Вот того, что в z88dk что-то исправят я бы сильно не опасался, там, насколько могу судить, направленность на добавление фич (больше библиотек, больше платформ), а не на их отладку. Хотя я некоторое время не слежу, может ситуация поменялась.

У zpu8080 сильные стороны: безглючность (особенно если сравнить с z88dk), современность (про z88dk молчу, SDCC получше, но GCC круче) и (надо же и себя похвалить) быстрая целочисленная арифметика. Основные минусы: невысокая скорость результирующих программ и сложность организации процесса разработки для непрограммистов типа меня. Есть еще нереализованная уникальная фича - теоретически можно переделать интерпретатор zpu для работы (например с квазом) с адресным пространством >64 Кб. Скорость это снизит, зато большие программы. Для игр все же zpu8080 мне кажется не очень пригоден, хотя может для текстовых.