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

[ivagor]

каков шанс ускорить команду POKE ?

Посмотрел, особых резервов там нет, получилось ускорить на 5% относительно 2.70. Если будут еще версии, то эта доработка там будет, но вряд ли это будет заметно. А вот использование шестнадцатеричных сказывается гораздо сильнее (особенно если POKE используется активно).

[metamorpho]

Посмотрел, особых резервов там нет, получилось ускорить на 5% относительно 2.70. Если будут еще версии, то эта доработка там будет, но вряд ли это будет заметно. А вот использование шестнадцатеричных сказывается гораздо сильнее (особенно если POKE используется активно).

Решил попробовать использовать шестнадцатеричные числа (заменил в POKE все десятичные) - Бейсик упрямо выдаёт синтаксическую ошибку в строке 297
297 POKE BD-256,&00,&00,&00,&00,&00,&00,&00,&00:POKE BD,&20,&70,&60,&E0,&60,&60,&C0,&C0:GOTO 330

Что в ней не так не пойму ?

[Stl75]

297 POKE BD-256,&00,&00,&00,&00,&00,&00,&00,&00:POKE BD,&20,&70,&60,&E0,&60,&60,&C0,&C0:GOTO 330

Там данные по-моему, по байту...
Через запятую - нельзя...

[ivagor]

Это ошибка 2.5, в моих модификациях этот баг давно исправлен (пункт 3 в readme). В 2.5 надо чтобы POKE с шестнадцатеричными был последним оператором в строке.

[metamorpho]

Это ошибка 2.5, в моих модификациях этот баг давно исправлен (пункт 3 в readme). В 2.5 надо чтобы POKE с шестнадцатеричными был последним оператором в строке.

Да точно. Запустил на Бейсике 2.70 и всё работает. Человечек стал немного шустрее бегать.

[ivagor]

Хочется все же сохранить совместимость с 2.5. Можно последнее число в POKE (перед двоеточием) сделать десятичным, а остальные пусть будут шестнадцатеричными.

[Advertiser]

[svofski]

Хочется все же сохранить совместимость с 2.5.

Какой смысл сохранять совместимость с багами 30-летней давности? Если бы это был Бейсик из ПЗУ, то конечно. Но тут-то.

[PPC]

скорее всего получится впихнуть быстрый PUT или PAINT (не вместе, а быстрые символы точно не поместятся).

В пределе можно рассмотреть совсем безумные идеи патча интерпретатора на лету. Если, скажем удастся локализовать код исходных операторов большими кусками, то можно делать отдельные куски "микрокода" команд. Например, делаем BLOAD в ленточной версии BASIC или LOAD DATA в дисковом BASIC 2.5, загружая микрокод команды в интерпретатор на место быстрого набора зарезервированных слов (или какой-другой команды).

Или, cкажем, расширяем оператор SCREEN новыми смыслами на которые по умолчанию стоят заглушки.

А про компилятор повторю мысль, которую уже писал: если нацеливаться на компиляцию 2.5, то runtime библиотка - не проблема (она уже есть), проблема в трансляторе.

Может и правда начать с генерации какого-либо P-кода?

Скажем, в Supersoft C есть т.н. Optimizer - отдельный исполняемый файл C2.COM, основная задача которого - перетолмачивание P-кода сгенерённого компилятором в ассемблерный выхлоп (то что он какой-нить peephole optimization ещё делает-скорее доп. фича).
Этот конкретный P-код хранится в виде текстового файла, так что можно на лету играться. Пример:

Скрытый текст

C65 2
D27 sh_font
D3 DLG_FONT
B9
D27 wn_inactive
C65 2
C1
B9
D27 bm_prompt
C65 2
D3 DLG_INFO
B9
D27 wn_inactive
C65 2
B12
B99
H61 sigterm
C1
B9
D27 textcolor
C65 2
D27 clrscr
D27 sh_csr
C1
B9
D27 exit
C65 2

[свернуть]

Недостаток в том что вот этот конкретный генератор возможно не поддерживает floating point типы данных.

Конечно, придётся разбираться во всех p-кодах, дописывать (использовать) рантайм для операций над типами и т.п.

ЛС-Паскаль уже предлагался, там вроде UCSD p-code, не уверен. Если так, то там стеков гора и быстро на ВМ80 не выйдет.

Возможно уже где-то есть P-код генератор для какого-нибудь абстрактного Бейсика и компилятор P-кода в i8080 c исходниками на C.
Если так, то портануть его на какой-нибудь C для CP/M и допилить до совместимости с BASIC 2.5 будет чуть проще, хоть и всё равно гора работы.

[ivagor]

Какой смысл сохранять совместимость с багами 30-летней давности?

1. Для самоудовлетворения мне нужна точка отсчета, чтобы получать удовольствие от того, насколько мои модификации быстрее. Эту причину можно смело игнорировать.
2. На данный момент есть дисковые версии только 2.5. Надо делать свой дисковый вариант, много лет собираюсь.

Может и правда начать с генерации какого-либо P-кода?

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

[svofski]

Может и правда начать с генерации какого-либо P-кода?

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

Что до p-кода, мы уже играли в похожую вещь, когда делали ZPU8080. Конечно zpu совсем не для 8080, это было чисто цирковое выступление и, может быть, можно придумать получше именно для 8080. Но я чего-то забыл, мы какую задачу решаем?

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

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