Ага. Начинает думать как мастер Йода
Я в своё время делал на Форте графическую библиотеку, так что думаю, что слегка его постиг, но удобным для разработки его не нахожу. Как эзотерическое направление - возможно. Мозголомная отладка, беспощадная. И постоянно крутишь в голове порядок чисел в стеке и на куче (HERE). Вместо того, чтобы мыслить в терминах прикладных задач. Форт в моём понимании неплохой задел для машинок с очень маленьким объёмом ОЗУ, он намного круче Бейсика. Можно на таких машинках начинать реальную интерактивную работу, например, с периферией. Но в те времена ценили и плавающую арифметику, хоть и медленную, но полезную. А у многих Фортов её не было.
Я рад, что Вы оценили возможности Паскаля. Я ещё раньше (до порта Сталкера) видел его неплохой потенциал даже для восьмибитных игр. Но почему-то слабо раскрытый на практике.
А ещё более проще переносить программы. Например, я за два вечера почти портировал Bolder16K со Спектрума (Z80) на Львов ПК-01 (КР580). Игра конечно простая, но тем не менее.
До Вектора/Специалиста/Корвета пока не добрался. Может когда-нить потом.
Это да, MT-Plus хранит константы вообще вдоль всего кода а локальные переменные в сегменте данных и вовсю использует косвенную адресацию LHLD/SHLD + LXI H/ MOV M для доступа, что получается достаточно быстро. Если не очень сильно угнетает академический синтаксис Никлауса Вирта, то MT-Plus - это очень хороший и практически ISO - совместимый компилятор Паскаля. MT-Plus не стал популярным возможно из-за количесства проходов при компиляции: "тогда", на медленных CP/M машинах это было затратно. Сейчас, когда мы все компилим host->target на машинах с большими гигагерцами это несущественно.
ACK - это здорово, но ему надо надеть CP/M - совместимое console и device I/O. Тогда потоковые либы сами скомпилятся как надо.
Если смириться с K&R (поддержка указателей на функии мне кста нравится больше по части причин чем что то как ограничил её ANSI со своей type safety паранойей), то есть Aztec C. А у него есть хитрый ключик, превращающий фрейм локальных переменных не объявленных как auto в часть BSS:
-Q treat local variables as statics initialized with 0; variables declared with auto prefix will still use stack storage. Доступ к локальным данным c этим ключиком становится по скорости сравним с паскалевским, и выхлоп значительно меньше, такая хитрость. И его тулчейн тоже поддерживает создание оверлеев и всякие хитрости маленьких машин (хотя его кодогенератор конечно MT плюсу проиграет вчистую потому как yacc).
почти оффтоп
На всякий случай, если кому понадобится быстрый не-ROMABLE CP/M putch() для Ацтека (и вообще для stdcall)
Код:#ifdef _ROMABLE #define putch(_c) bios(CONOUT,_c) /* character directly to console */ #else /*_ROMABLE*/ #define putch cputch /* not _ROMABLE but fast */ #endif /*_ROMABLE*/ #ifdef _ROMABLE cputch(_c) register int _c; { putch(_c); } #else /* Non-ROMable self-modifying fast putchar via BIOS couout */ #asm BIOSENT EQU 1 ; BIOS table vector CONOUT EQU 10 ; (4 * 3 - 3 + 1) output to CON: OP_CALL EQU 205 ; Manx assembler accepts 0xCD cputch_: push b ; save register variable lxi h,4 dad sp mov c,m ; character from <C> to console DB OP_CALL bconout:DW init pop b ; restore register variable ret init: push d lhld BIOSENT lxi d,CONOUT dad d mov e,m inx h mov d,m xchg shld bconout pop d pchl #endasm #endif /*_ROMABLE*/[свернуть]
Последний раз редактировалось PPC; 02.07.2021 в 03:38.
Похоже каждый выбрал свой компилятор и пользуется им, у меня это sccz80 (из z88dk). Глючная хрень, но это кросс-компилятор со сравнительно большими возможностями и если обходить ошибки, то он работает. Близок к идеалу был бы SDCC (сужу по версии z80), но версию для 8080 вряд ли дождусь.
Не совсем соглашусь, последнее, что выкатывал я было как раз на С с использованием z88dk. Ну а ты сколько сишного сделал не так уж давно.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Забыл про последнюю маленькую модификацию бейсика, тогда на си был предпоследнее выкатывание (околожпег), зато там было крупнее.
Ну если ты насчёт этого putch() выше то это ведь только маааленькая такая ассемблерная вставка. Без неё можно жить если нет яростного вывода на консоль каких нибудь оконных примитивов.
В моей крайней поделке которую выкатил не столь давно (BMP) этого кода нет. Мне стало интересно оценить статистику. Оказалось, там всё таки нашлось около 200 строчек инлайн асма, на примерно 6000 строк на C. Но даже в этом случае (как и в коде выше ) кроме инлайн асма conditionally даётся и альтернативная сишная имплементация. Возможно я просто не настолько "пурист" как ты, но мне кажется, это вполне себе норм. Или не?
O_SPEED выше, конечно правильнее поменять на какое-то __CPUКод:/****************************************************************/ /* Input bitmap byte extractors (general and 4 bpp - optimized */ /****************************************************************/ #if O_SPEED extern char bpp_bm(); /* Vector-06c byte from 1-8 bpp BMP image row buffer */ extern char bpp4bm(); /* Vector-06c byte from 4 bpp BMP image row buffer */ extern char xpp4bm(); /* Vector-06c byte from 4 bpp BMP image row buffer */ #asm
- - - Добавлено - - -
SDCC был бы идеален, да но кто ж нам его под 8080 даст. Можно конечно пройти их путь и сделать самому (корни у него в Small C вроде)
А вообще-то я ужасно хотел переползти на ACK. Я раз в 10 лет "переползаю на ACK", примерно как человечество раз в 2 миллиона лет запускает адронный коллайдер...
Кое-как собрал его под linux, что-то недособралось, потом нужно было всю среду разработки туда переносить, писать библиотеки поддержки и т.д. и т.п.
Я понял что меня затянет обустройство (типа войду в режим языка Форт) и вернулся к ацтекам с которыми у меня ещё с 90х дофига чего имелось.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)