Вектор-06Ц: Общие вопросы

[svofski]

В основном пилят сам Форт.

Это правда. Когда человек постигает Форт, его перестает интересовать мирская суета.

[Oleg N. Cher]

Ага. Начинает думать как мастер Йода

Я в своё время делал на Форте графическую библиотеку, так что думаю, что слегка его постиг, но удобным для разработки его не нахожу. Как эзотерическое направление - возможно. Мозголомная отладка, беспощадная. И постоянно крутишь в голове порядок чисел в стеке и на куче (HERE). Вместо того, чтобы мыслить в терминах прикладных задач. Форт в моём понимании неплохой задел для машинок с очень маленьким объёмом ОЗУ, он намного круче Бейсика. Можно на таких машинках начинать реальную интерактивную работу, например, с периферией. Но в те времена ценили и плавающую арифметику, хоть и медленную, но полезную. А у многих Фортов её не было.

Еще не забывайте Pascal/MT+, который очень даже Паскаль. Пример недавнего переноса Сталкера на Вектор показал его профпригодность. Если не переносить сишный код, а писать чего-то с нуля, из Паскаля/МТ+ пожалуй можно выстрадать немного больше, чем из Си. Просто за счет того, что это очень практичный компилятор для своего времени, который поддерживает всякие особенности маленьких машин, оверлеи итд.

Я рад, что Вы оценили возможности Паскаля. Я ещё раньше (до порта Сталкера) видел его неплохой потенциал даже для восьмибитных игр. Но почему-то слабо раскрытый на практике.

А ещё более проще переносить программы. Например, я за два вечера почти портировал Bolder16K со Спектрума (Z80) на Львов ПК-01 (КР580). Игра конечно простая, но тем не менее.

• https://github.com/Oleg-N-Cher/Bolder16K

До Вектора/Специалиста/Корвета пока не добрался. Может когда-нить потом.

[PPC]

Если не переносить сишный код, а писать чего-то с нуля, из Паскаля/МТ+ пожалуй можно выстрадать немного больше, чем из Си. Просто за счет того, что это очень практичный компилятор для своего времени, который поддерживает всякие особенности маленьких машин, оверлеи итд.

Это да, 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*/

[свернуть]

[ivagor]

Похоже каждый выбрал свой компилятор и пользуется им, у меня это sccz80 (из z88dk). Глючная хрень, но это кросс-компилятор со сравнительно большими возможностями и если обходить ошибки, то он работает. Близок к идеалу был бы SDCC (сужу по версии z80), но версию для 8080 вряд ли дождусь.

[svofski]

Похоже каждый выбрал свой компилятор и пользуется им

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

[ivagor]

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

[Advertiser]

[ivagor]

Забыл про последнюю маленькую модификацию бейсика, тогда на си был предпоследнее выкатывание (околожпег), зато там было крупнее.

[PPC]

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

Ну если ты насчёт этого putch() выше то это ведь только маааленькая такая ассемблерная вставка. Без неё можно жить если нет яростного вывода на консоль каких нибудь оконных примитивов.

В моей крайней поделке которую выкатил не столь давно (BMP) этого кода нет. Мне стало интересно оценить статистику. Оказалось, там всё таки нашлось около 200 строчек инлайн асма, на примерно 6000 строк на C. Но даже в этом случае (как и в коде выше ) кроме инлайн асма conditionally даётся и альтернативная сишная имплементация. Возможно я просто не настолько "пурист" как ты, но мне кажется, это вполне себе норм. Или не?

/****************************************************************/
/* 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

O_SPEED выше, конечно правильнее поменять на какое-то __CPU

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

Похоже каждый выбрал свой компилятор и пользуется им, у меня это sccz80 (из z88dk). Глючная хрень, но это кросс-компилятор со сравнительно большими возможностями и если обходить ошибки, то он работает. Близок к идеалу был бы SDCC (сужу по версии z80), но версию для 8080 вряд ли дождусь.

SDCC был бы идеален, да но кто ж нам его под 8080 даст. Можно конечно пройти их путь и сделать самому (корни у него в Small C вроде)

А вообще-то я ужасно хотел переползти на ACK. Я раз в 10 лет "переползаю на ACK", примерно как человечество раз в 2 миллиона лет запускает адронный коллайдер...

Кое-как собрал его под linux, что-то недособралось, потом нужно было всю среду разработки туда переносить, писать библиотеки поддержки и т.д. и т.п.
Я понял что меня затянет обустройство (типа войду в режим языка Форт) и вернулся к ацтекам с которыми у меня ещё с 90х дофига чего имелось.

[ivagor]

(корни у него в Small C вроде)

Насчет SDCC не помню, а sccz80 точно на базе small c.

[crackintosh]

Вот он! VECTOR-86PC / Вектор-86ПК
Пока что он у драгоёбов валяется в гараже... мне только фото прислали.
Насколько он раздеребанен - не знаю. Надеюсь выкупить...
Писали о нем вот здесь: