Вряд ли в Турбе, его сильно давно использовал.Сообщение от Bolt
Наверное в дельфях, когда реально дофига всяких скобок-знаков.
Вряд ли в Турбе, его сильно давно использовал.
Наверное в дельфях, когда реально дофига всяких скобок-знаков.
Кто возьмётся по листингу и .tap найти где сбивается кодогенератор?
demo_lode_runner стала меньше на 10%, 5935 байт.
demo_z работает с ошибками, но там без помощи автора не смогу.
В планах исправление ошибок и несколько фич кодогенератора, которые ещё уменьшат объём и увеличат скорость, потом - 8086 и STM8.
Вам не сложно прикрутить к bmpc_z80.exe ключи -v и -h или /? а то все время путаешься какая версия запущена под Win32. Хотя версию он показывает вместе с компилируемым файлом на входе. И еще каким ассемблером(ами) ассемблируются его .asm? Когда он запускается без входного файла на консоль не выводится инфа о дальнейших действиях: то ли текст ему вводить( и в каком файле он тогда сохранится), то ли имя входного файла. По поводу объема и скорости ассемблерного кода. Это логичнее в отдельную прогу убрать. Или от программиста ничего не зависит в плане выбора стиля программирования на Паскале. По поводу STM8 ( не лучше ли сразу STM32 и других ARM процессоров).
А будет ли версия компилятора под nedoos? Очень нужно!
Zx-Evolution rev.c
Согласен, надо пояснить. Прикручу.
Я в Ubuntu пользуюсь z80asm, в мануале на ассемблер есть ссылка http://savannah.nongnu.org/projects/z80asm/
Или Zeus command line Z80 assembler, он поддерживает dup. Кстати, есть мысль сделать обработку dup...edup в ассемблерных вставках.
А вообще стараюсь текст максимально упростить, чтобы собиралось любым ассемблером. Ассемблерные вставки asm...end пока просто копируются в выходной файл.
Что именно убрать в отдельную прогу и что не зависит от программиста? Если речь идёт об оптимизации размер-скорость, то потом будут отдельные ключи для выбора режима оптимизации. А сейчас такого выбора нет, любое упрощение и уменьшает размер, и увеличивает скорость.
ARM пробовал, даже вывел текст на плате STM32F746G-DISCO, но там такое количество регистров и объём RTL, что оно отложено до лучших времён. А добавить STM8 не сложнее Z80.
Кросс-компилятор с целевой платформой nedoos, или компилятор, запускающийся под nedoos? Запуск под nedoos - точно нет. Кросс-компиляция - если объясните что требуется в коде, то можно попробовать.
Хотя когда-то и была идея запустить компилятор на 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 минут, и это если всё в оперативке, без свопа и прочего. Оно такое надо?
Трезво оценивая свои способности и полученный результат готов взяться только за добавление целевой платформы, но не за попытку впихнуть невпихуемое
Да, печально. Но ведь было время запускался turbo pascal вместе с IDE на машинах с 640К памяти. И даже компилировал при этом и отлаживал. А первые версии вообще в 32к убирались.
Apple Pascal, 64 kb, 6502 1mgz
https://en.m.wikipedia.org/wiki/Apple_Pascal
Turbo Pascal имеет две особенности, которые позволяют ему так работать: он однопроходный, и наглухо прибит гвоздями к одной архитектуре.
Apple Pascal, видимо, тоже.
В 1-2 плоских мегабайта ещё можно попробовать уложиться. Но не в 64к с окнами, там половина тактов на переключение страниц уйдёт.
Или поднимаем тактовую, чтобы получить приемлемое время работы.
Или прибиваем гвоздями к Z80 и NedoOS, переписывая всё с нуля на ассемблере с использованием трюков для экономии байтов, тактов и регистров.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием