Компилятор языка Паскаль - планы на будущее

[andrews]

demo_lode_runner стала меньше на 10%, 5935 байт.
demo_z работает с ошибками, но там без помощи автора не смогу.
В планах исправление ошибок и несколько фич кодогенератора, которые ещё уменьшат объём и увеличат скорость, потом - 8086 и STM8.

Вам не сложно прикрутить к bmpc_z80.exe ключи -v и -h или /? а то все время путаешься какая версия запущена под Win32. Хотя версию он показывает вместе с компилируемым файлом на входе. И еще каким ассемблером(ами) ассемблируются его .asm? Когда он запускается без входного файла на консоль не выводится инфа о дальнейших действиях: то ли текст ему вводить( и в каком файле он тогда сохранится), то ли имя входного файла. По поводу объема и скорости ассемблерного кода. Это логичнее в отдельную прогу убрать. Или от программиста ничего не зависит в плане выбора стиля программирования на Паскале. По поводу STM8 ( не лучше ли сразу STM32 и других ARM процессоров).

[Advertiser]

[Bolt]

Вам не сложно прикрутить к bmpc_z80.exe ключи -v и -h или /?
...
Когда он запускается без входного файла на консоль не выводится инфа о дальнейших действиях: то ли текст ему вводить( и в каком файле он тогда сохранится), то ли имя входного файла.

Согласен, надо пояснить. Прикручу.

И еще каким ассемблером(ами) ассемблируются его .asm?

Я в Ubuntu пользуюсь z80asm, в мануале на ассемблер есть ссылка http://savannah.nongnu.org/projects/z80asm/
Или Zeus command line Z80 assembler, он поддерживает dup. Кстати, есть мысль сделать обработку dup...edup в ассемблерных вставках.
А вообще стараюсь текст максимально упростить, чтобы собиралось любым ассемблером. Ассемблерные вставки asm...end пока просто копируются в выходной файл.

По поводу объема и скорости ассемблерного кода. Это логичнее в отдельную прогу убрать. Или от программиста ничего не зависит в плане выбора стиля программирования на Паскале. По поводу STM8 ( не лучше ли сразу STM32 и других ARM процессоров).

Что именно убрать в отдельную прогу и что не зависит от программиста? Если речь идёт об оптимизации размер-скорость, то потом будут отдельные ключи для выбора режима оптимизации. А сейчас такого выбора нет, любое упрощение и уменьшает размер, и увеличивает скорость.
ARM пробовал, даже вывел текст на плате STM32F746G-DISCO, но там такое количество регистров и объём RTL, что оно отложено до лучших времён. А добавить STM8 не сложнее Z80.

А будет ли версия компилятора под nedoos? Очень нужно!

Кросс-компилятор с целевой платформой nedoos, или компилятор, запускающийся под nedoos? Запуск под nedoos - точно нет. Кросс-компиляция - если объясните что требуется в коде, то можно попробовать.

[Bolt]

Хотя когда-то и была идея запустить компилятор на 64к, я от неё отказался.

В чём сложность запуска компилятора в таком окружении:

1. Чтобы запустить компилятор под NedoOS его надо скомпилировать под NedoOS. Нужна поддержка этой ОС в компиляторе.
2. Объём исполняемого файла превысит 64 килобайта однозначно. Можно переключать страницы, можно сделать оверлей, можно поделить компилятор на несколько частей...
3. Компилятор многопроходный, хранит в памяти информацию в виде деревьев и связных списков. Статистика по demo_z: 5313 строк, около 100 килобайт исходного кода, включая спрайты, 5549 узлов синтаксического дерева, в итоге около 12 килобайт исполняемого кода и 20 килобайт спрайтов. Компилятор для обработки такой программы использует почти 7 мегабайт оперативной памяти. Да, это 64-битные указатели. Да, можно перелопатить весь компилятор, экономя байты, можно работать с файлами на диске, можно сделать виртуальную память...
4. Сборку demo_z компилятор сейчас делает за 0,5 с на 64-битном процессоре с тактовой частотой 1,9 ГГц. На Z80 это будет минимум в 1000 раз медленнее. 8 минут, и это если всё в оперативке, без свопа и прочего. Оно такое надо?

Трезво оценивая свои способности и полученный результат готов взяться только за добавление целевой платформы, но не за попытку впихнуть невпихуемое

[andrews]

Что именно убрать в отдельную прогу и что не зависит от программиста? Если речь идёт об оптимизации размер-скорость, то потом будут отдельные ключи для выбора режима оптимизации. А сейчас такого выбора нет, любое упрощение и уменьшает размер, и увеличивает скорость.
ARM пробовал, даже вывел текст на плате STM32F746G-DISCO, но там такое количество регистров и объём RTL, что оно отложено до лучших времён. А добавить STM8 не сложнее Z80.

нужны операторы скобочные в Паскаль, чтобы они затем переходили в текст на ассемблере, а по ним эта прога-профайлер? определит время выполнения выделенного скобками фрагмента исходника( количество машинных циклов), задействованную память и регистры. Можно это все конечно добавить и в компилятор на своем ключе и генерить еще один файл.
Это подспорье программисту, который будет осваивать написание на нем эффективных программ. Мне не встречалось систем с дисплеями на STM8, хотя во Франции в 70-80е были компьютеры на ST6, ST7, и кажется это их предшественники архитектурно. На STM32 есть серия STM32 Primer с ЖКИ дисплеями. Там и операционка и игры были
http://www.stm32circle.com/resources/stm32primer2.php
и Паскаль с графикой там может быть в тему.

[Bolt]

нужны операторы скобочные в Паскаль, чтобы они затем переходили в текст на ассемблере, а по ним эта прога-профайлер? определит время выполнения выделенного скобками фрагмента исходника( количество машинных циклов), задействованную память и регистры.

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

Мне не встречалось систем с дисплеями на STM8.
...
На STM32 есть серия STM32 Primer с ЖКИ дисплеями.

На STM32 много чего есть с дисплеями.
STM8 не обязательно должен быть с дисплеем и играми, он может выполнять и другие задачи.

[andrews]

Теперь понял. Но... не понимаю зачем это именно в такой форме. Потому что код может меняться при изменении программы за пределами этого "оператора", и даже в другой версии компилятора, а программа на ЯВУ, подогнанная под один процессор, может быть очень медленной на другом.

согласен, что ценно только в паре с профайлером. Но его писать универсальный для всех 8, 16, 32 битных систем сложновато. А для z80 можно сделать, но и тут все не тривиально, вон их сколько всяких разных железяк напридумывали. Сейчас пока после каждой компиляции надо просматривать ассемблерный текст, что он там нагенерил( да еще если ключи разные оптимизации появятся). Писать подробный мануал, как писать быстрый и оптимальный код, тоже вряд ли захочется. А так пусть каждый разработчик выеживается, как знает. Ассемблер кто-то подзабыл, кому-то "религия" не позволяет много времени терять на проект. Тем более, если он кого-то заинтересовал, то можно и переписать на ассемблере. А как эскизный проект в самый раз на ЯВУ.
Про STM8 я писал статью для журнальчика Compel-а в 2009 году, поверхностная получилась не было уже особого стимула писать, а после они регулярно что-то по этому семейству писали
https://www.compel.ru/lib/ne/2009/2/...emeystva-stm8s
Камушек интересный, но дисплейчики к нему цеплять графические это на мой взгляд черезчур. Да и смысл? Цена у них с STM32 различается не сильно, а готовых решений с дисплеями для STM32 вагон. Для популяризации кросс-компилятора вполне достаточно. Но это дело хозяйское. Паскаль же и графика естественный тандем или нет? Впрочем может к современным кросс-ассемблерам для z80 графические пакеты тоже легко цепляются. Правда еще нужен удобный IDE+отладчик.

[Bolt]

Почему STM8? Потому что если сейчас займусь ещё и STM32, то утону в регистрах, драйверах и RTL. Z80, 8086, STM8, PIC24, и даже 80386, если не лезть в защищённый режим - это то, что для меня просто и понятно. На этих платформах отрабатываю общую структуру компилятора, багов и так достаточно, а потом можно будет переходить на ARM и MIPS, которые пока для меня не совсем привычны.
STM8 не обязательно должен быть с графическим дисплеем, он может быть и "автономным". Читать датчики, отправлять данные по UART, мигать светодиодом.
Паскаль это не только графика, но и, например, переносимость программ. Драйвер SD-карты и файловой системы ext2 прекрасно работает на PIC24 и PIC32, надо - и на Спектруме запустим

[andrews]

Уфф, скользкая стезя. Одно дело продвижение кросс-компилятора на других платформах, и совсем другое введение в обиход железа "24-битный программный счетчик, с помощью которого стало возможным адресовать 16-мегабайтное адресное пространство памяти с отображенными в него регистрами. Мощность вычислительного ядра возросла, конечно, не в той степени, чтобы способствовать увеличению адресного пространства (хотя по сравнению с семейством ST7 добавлены операции деления 16-бит на 16-бит и 16-бит на 8-бит и более быстрого знакового умножения 8-бит на 8-бит). Большинство инструкций выполняются быстрее за счет трехстадийного конвейера, раздельной внутренней 32-разрядной шины для выборки инструкций и 16-разрядной шины данных. В командах, работающих с содержимым памяти, совмещены в одном машинном цикле операции чтения и записи. Все это дает возможность получить производительность процессора до 20 MIPS при тактовой частоте 24 МГц".

Хотя был такой компьютер "Искра-226" где основной процессор был совместим с материнским Hewlett Packard, а втыкалось
в него что угодно и порой в разы более мощное. Но тогда надо выбирать какое-то спектрумовское железо с шиной, а то переговоры-тары-бары с авторами. Лампочки вкл./выкл? Можно конечно, но для z80 и STM8 можно считать ускорителем. В свое время мы с Игорем Мазницей и на AT90S1200 что-то пытались со спрайтами делать, пока его в Полигедрон не унесло.