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

[Stl75]

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

Привет всем...

На мой взгляд основная разница программ на Basic' e и в коде - именно в скорости выполнения...
???

Человечек стал немного шустрее бегать.

Как metamorpho сказал, чтобы человек по быстрее бегал...

[PPC]

ACK тоже компилирует свои языки (среди которых есть Бейсик) в какой-то промежуточный код. Если у тебя настроение есть в этом копаться, посмотри что там.
<snip>
Но я чего-то забыл, мы какую задачу решаем?

Если честно, то я не до конца уверен, какую. Мне представляется, все решили писать компилятор

Если хочется скомпилировеать Бейсик любой ценой, то почему не подходят те компиляторы, что уже есть? Если плавучка, то плавучка в ACK есть, нету только библиотеки, которая ее реализовывает.

Я так понимаю, BASCOM всем/кому-то (не мне) не подходит потому, что
1. Это не BASIC 2.5 семантически
2. У него нет Векторовского нативного рантайма (что решаемо, но это всё равно не будет BASIC 2.5)

А ведь у BASCOM, кроме того что он цомпилер должен быть ещё и целочисленный integer...

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

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

[svofski]

Если честно, то я не до конца уверен, какую. Мне представляется, все решили писать компилятор

Зачем же тогда компилировать именно Бейсик. Можно компилировать языки поприятнее. То, что делает metamorpho, прикольно именно тем, что оно сделано вот на таком вот Бейсике как у всех был.

Плавучка отдельно выдранная из Бейсика уже есть, тут пробегала пару страниц назад. Так что по идее можно ее взять, аккуратно вклеить в библиотеку ACK на место заглушек, вот и все дела. Наверняка повозиться придется конечно все равно, но все-таки это не то же самое, что ее писать.

Вопрос со звездочкой: а кому вообще сдалась и на что эта плавучка в Бейсике? В классическом варианте она была ценна тем, что получался могучий калькулятор. А сейчас?

[PPC]

Зачем же тогда компилировать именно Бейсик. Можно компилировать языки поприятнее. То, что делает metamorpho, прикольно именно тем, что оно сделано вот на таком вот Бейсике как у всех был.

Думаю, в твоём вопросе есть и неявный ответ: все хотят не просто компилятор какого-то абстрактного языка бейсик, а компилятор именно для Векторовского BASIC 2.5, что бы он из себя не представлял исторически, и откуда бы не произрастали его корни. Идея, как я понимаю такая: ты ему скармливаешь BAS или CAS файл, а на выхлопе - COM или даже монолитный ROM. Иначе отчего в этой теме про BASIC 2.5 столько постов...это "родные валенки", все их так или иначе носили. Вполне нормальное желание, хотя за всех говорить... просто мне так кажется.

Так что по идее можно ее взять, аккуратно вклеить в библиотеку ACK на место заглушек, вот и все дела. Наверняка повозиться придется конечно все равно, но все-таки это не то же самое, что ее писать.

Мне всё-таки нравится, когда я могу запустить компилятор на таргет платформ. Хотя ничего плохого в ACK нет. Но Aztec - исключительно прикольный цомпилер. Гораздо более доставляет, чем Pascal MT+. И потом, это ведь Томас Фенвик, живая легенда, выкинувшая в окно многолетние потуги MS и написавший за 3 месяца Win CE... а ACK - это кросс-средство в себе и оно чуть в стороне и слегка "полноватое", как язык Ада.
Хотя оба генерят чудовищный код... Подозреваю, можно гораздо лучше, даже не кросс, а прямо на платформе.

Насчёт плавучки, она полезна. Но для определённого круга задач (Фортран их решал). От того, что есть многоядерные FPU, Векторовская плавучка хуже не стала. Это-как с 12м айфоном, или какой там был предыдущий. Ну и потом, AMD выпускал сопроцессоры. Можно подумать об HDL архитектуре с таким.

Все наши задачи и достижения вообще с практической точки зрения не имеют смысла. Эзотерика, но нам ведь нравится

[svofski]

Ну да, понятно. У меня похожее, но чуть-чуть рядом. Интересно чтобы был Бейсик c REPL, а не компилятор. Пусть он будет похож на 2.5, но мне норм, если там какие-то эзотерические параметры у оператора SCREEN отвалятся. Я бы даже может наоборот, замутил какой-нибудь SCREEN эзотеричней всех, что уже были. С другой стороны вот эту сатанинскую муть с отсутствием пробелов хочется сохранить, а то это уже не совсем Бейсик получается.

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

[ivagor]

С другой стороны вот эту сатанинскую муть с отсутствием пробелов хочется сохранить

В бейсике 5.x микрософт изменил синтаксические требования и пробелы стали обязательны. В BASCOM есть параметр, который позволяет компилировать по новым или "старым" правилам.

[metamorpho]

Пламенное обсуждение вариантов Бейсика, разбудило и во мне фантазии на эту тему
Если описывать какой нужен новый Бейсик, то мне думается так:

1. Писать например компилятор обязательно совместимый с программами Бейсик v.2.5. ?? а какой в этом смысл ? если
цель компилятора ускорить выполнение программы, то ускорить старые Бейсик программы можно нажатием F10 (12 Мгц)

2. А если уж есть жгучее желание написать компилятор языка Бейсик, то это должен быть мощный Бейсик, свободный от
костылей совместимости со всеми предыдущими Бейсиками. Вобравший в себя все лучшие (оптимизированные и быстрые)
наработки и идеи. И заточен этот чудо Бейсик для более БЫСТРОГО и УДОБНОГО создания игровых программ и
демосцены. Например я бы включил в этот компилятор-Бейсик следующее:
- обязательная часть ядро-основа это основные Бейсик операторы (циклы, if then else, goto, gosub, работа с клавиатурой и подобное)
- возможность встроенных в код бейсика подпрограмм на ассемблере

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

Допустим из математических операторов мне нужен только sin() и соs(), а остальные математические функции
(тангенс, арктангенс, логариф, возведение в степень и т.д.) мне не нужны, поэтому при компиляции подключается код
только этих двух нужных мне функций и всё.
Если нам совсем не нужны строковые функции, то и не нужно их подключать.
Допустим мне нужен оператор рисующий линии и прямоугольники, а все остальные (окружности, точки, paint,
point и т.п) мне не нужны - соответственно компилятор их не подключает.
Ещё например мне нужен распаковщик (типа zip), чтобы распаковать область данных начиная со строки (или
метки) такой-то. Или же чтобы читать данные из файла и на лету их распаковывать в указанную область памяти.
Ещё было бы здорово иметь настраиваемый модуль загруки - например обычная загрузка, скоростная загрузка,
загрузка аля-zx spectrum и ещё что-нибудь.
Конечно музыка и звуки. beep и play (на выбор ВИ53 или AY) - с возможностью подключения разных движков тяжёлых и лёгких.
Оператор супер-быстрого вывода спрайта несколько разных вариантов - с оптимизацией по размеру, с указанием во сколько плоскостей выводить.......Например нам нужен только один вариант - вывод спрайтов 16х16 точек в две плоскости и компилятор включает в скомпилированный код только этот вариант вывода спрайта.
Ещё я бы включил оператор скроллинга указанной области экрана, программу голосового робото-чтения букв и .... другие хотелки-модули

[svofski]

Допустим из математических операторов мне нужен только sin() и соs(), а остальные математические функции
(тангенс, арктангенс, логариф, возведение в степень и т.д.) мне не нужны, поэтому при компиляции подключается код
только этих двух нужных мне функций и всё.

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

Если нам совсем не нужны строковые функции, то и не нужно их подключать.

А работать со строками он совсем не умел. Ты не ошибся с выбором платформы? =)))

[Stl75]

Думаю, в твоём вопросе есть и неявный ответ: все хотят не просто компилятор какого-то абстрактного языка бейсик, а компилятор именно для Векторовского BASIC 2.5, что бы он из себя не представлял исторически, и откуда бы не произрастали его корни. Идея, как я понимаю такая: ты ему скармливаешь BAS или CAS файл, а на выхлопе - COM или даже монолитный ROM. Иначе отчего в этой теме про BASIC 2.5 столько постов...это "родные валенки", все их так или иначе носили. Вполне нормальное желание, хотя за всех говорить... просто мне так кажется.

Привет всем...

Ну я - примерно так и хотел...
Компилятор для Вектор Basic' a v2.5...
Открываешь - .bas, .cas - на выходе .com, .rom...

Как то - так...

[ivagor]

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

Некоторые версии микрософтовского тоже задавали подобные вопросы, тогда это было актуально.

При ковырянии бейсика выявляются некоторые вещи, которые мне кажутся интересными:
1. Реализация LINE в 2.5 использует однобайтный Y и двухбайтный X. Причем рисование линии не менялось с 1.3 (в Сигнале аналогично). И везде эта линия в паре с рисованием точки 0-255,0-255. Думаю линию позаимствовали где-нибудь.
2. Штатный POKE все же может нагадить в бейсик. POKE&FFFF, - первое значение попадет в FFFF, а следующие в 0000, 0001 и т.д. Глубина повреждений ограничивается длиной строки бейсика.

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

Еще мелкий момент. POKE и PEEK могут менять и смотреть не только знакогенератор и несколько следующих ячеек, но и почти все 3 буфера нот. Как это можно использовать - теоретически можно играть музыку без PLAY и символьных переменных, напрямую POKE в буфер.