Если бы у Медноногова был БК ?..

[haywire]

> Никакого несовпадения разрядности не будет. На момент передачи параметров таким образом компилятор прекрасно знает список параметров и их разрядность.

Может не знать. Тело функции может быть в совершенно другом модуле, скомпилированным даже не этим компилятором. Передача параметров через стек в С абсолютно стандартна и подобных фокусов не допускает. Более того, экономия одного байта на стеке весьма сомнительна относительно разрастанию кода и уменьшению быстродействия. Ни один компилятор так не делает.

[Oleg N. Cher]

Хых. Знаете ли, уважаемый, если Вы перепутаете количество и последовательность параметров, то у Вас любая программа на этом вылетит. Это не недостаток SDCC и уж точно не недостаток такого способа передачи.

Если придерживаться "стандартных" для PDP-11 способов вызова, то надо забыть про Z80 и про подходы для улучшения оптимальности. Напрочь. Но я понимаю, Вы выступаете в защиту сишного бардака. С этим я спорить не буду, бардака конечно хватает.

Дело, кстати, не в экономии байта на стеке. Дело больше в экономии кода и улучшении скорости при снятии параметров.

Сожалею, что Вас задел. Идите с миром.

[haywire]

IAR код в 2 раза более компактный генерирует

1854 j = c1 = c2 = c3 = c4 = c5 = c8 = 0;
\ 382B 010000 LD BC,0
\ 382E 69 LD L,C
\ 382F 60 LD H,B
\ 3830 221201 LD (?0010+274),HL
\ 3833 ED431401 LD (?0010+276),BC
\ 3837 220E01 LD (?0010+270),HL
\ 383A ED431001 LD (?0010+272),BC
\ 383E 220A01 LD (?0010+266),HL
\ 3841 ED430C01 LD (?0010+268),BC
\ 3845 220601 LD (?0010+262),HL
\ 3848 ED430801 LD (?0010+264),BC
\ 384C 220201 LD (?0010+258),HL
\ 384F ED430401 LD (?0010+260),BC
\ 3853 22FE00 LD (?0010+254),HL
\ 3856 ED430001 LD (?0010+256),BC
\ 385A 221A01 LD (?0010+282),HL
\ 385D ED431C01 LD (?0010+284),BC
\ 3861

// 54 байта

14528 ;bank2.c:1844: j = c1 = c2 = c3 = c4 = c5 = c8 = 0;
006160 AF [ 4]14529 xor a, a
006161 DD 77 CD [19]14530 ld -51 (ix), a
006164 DD 77 CE [19]14531 ld -50 (ix), a
006167 DD 77 CF [19]14532 ld -49 (ix), a
00616A DD 77 D0 [19]14533 ld -48 (ix), a
00616D AF [ 4]14534 xor a, a
00616E DD 77 D1 [19]14535 ld -47 (ix), a
006171 DD 77 D2 [19]14536 ld -46 (ix), a
006174 DD 77 D3 [19]14537 ld -45 (ix), a
006177 DD 77 D4 [19]14538 ld -44 (ix), a
00617A AF [ 4]14539 xor a, a
00617B DD 77 D5 [19]14540 ld -43 (ix), a
00617E DD 77 D6 [19]14541 ld -42 (ix), a
006181 DD 77 D7 [19]14542 ld -41 (ix), a
006184 DD 77 D8 [19]14543 ld -40 (ix), a
006187 AF [ 4]14544 xor a, a
006188 DD 77 D9 [19]14545 ld -39 (ix), a
00618B DD 77 DA [19]14546 ld -38 (ix), a
00618E DD 77 DB [19]14547 ld -37 (ix), a
006191 DD 77 DC [19]14548 ld -36 (ix), a
006194 AF [ 4]14549 xor a, a
006195 DD 77 DD [19]14550 ld -35 (ix), a
006198 DD 77 DE [19]14551 ld -34 (ix), a
00619B DD 77 DF [19]14552 ld -33 (ix), a
00619E DD 77 E0 [19]14553 ld -32 (ix), a
0061A1 AF [ 4]14554 xor a, a
0061A2 DD 77 E1 [19]14555 ld -31 (ix), a
0061A5 DD 77 E2 [19]14556 ld -30 (ix), a
0061A8 DD 77 E3 [19]14557 ld -29 (ix), a
0061AB DD 77 E4 [19]14558 ld -28 (ix), a
0061AE AF [ 4]14559 xor a, a
0061AF DD 77 E5 [19]14560 ld -27 (ix), a
0061B2 DD 77 E6 [19]14561 ld -26 (ix), a
0061B5 DD 77 E7 [19]14562 ld -25 (ix), a
0061B8 DD 77 E8 [19]14563 ld -24 (ix), a
14564 ;bank2.c:1845: do
0061BB

// 91 байт

[Oleg N. Cher]

Любите синтетические тесты, по которым Java превосходит Rust в стопицот раз? Угомонитесь уже.
Кстати, я именно это называл уродской работой с индексными регистрами.

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

;	---------------------------------
; Function _Abc
; ---------------------------------
_Abc:
	ld	hl,0x0000
	ld	(_c8),hl
	ld	(_c5),hl
	ld	(_c4),hl
	ld	(_c3),hl
	ld	hl,0x0000
	ld	(_c2),hl
	ld	(_c1),hl
	ld	(_j),hl
	ret
	SECTION code_compiler
;	---------------------------------

28 байт

[^m00h^]

Может тогдв сделать порт Laser Basic на БК, а потом уже перетаскивать дурака ? Их кстати было 2 версии, вторая от New Hakers Krowait System'94:

https://vtrd.in/release.php?r=d8d1fa...376207559297e6

[Oleg N. Cher]

Это выхлоп ZSDCC с опциями -SO3 --opt-code-size --max-allocs-per-node100000

Код такой:

static int j, c1, c2, c3, c4, c5, c8;
static void Abc (void) {
  j = c1 = c2 = c3 = c4 = c5 = c8 = 0;
}

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

По порядку:

Может тогдв сделать порт Laser Basic на БК, а потом уже перетаскивать дурака ?

Такой порт несомненно бы был хорош и полезен. Но в полном объёме это не понадобится для Дурака. Буду заниматься этим посильно.

Их кстати было 2 версии, вторая от New Hakers Krowait System'94:

Это просто хак под джойстик. И копирайты Славы выпилены. Я их сравнивал.

[Sayman]

1. Есть в IAR регистровые параметры? Нет. В SDCC есть. Кстати, появились за последние 10 лет.

SDCC, вплоть до версии 4.1.0 не умеет "в стоке", без использования "соглашений" использовать регистровые параметры. только снапшот 4.1.12 этому научился. IAR это умеет 20 лет как без всяких соглашений. почитай мануал хоть к нему, чтоли. там всё расписано.

В SDCC есть ещё три модели вызова, помимо родной __cdecl

начиная с 4.1.12 он автоматом применяет новую модель вызовов и то, только к генерируемым функциям. функции в его родной либе всё ещё в старой модели. хоть 10 моделей пусть будет, это без толку, т.е. его родная либа это кошмар! банальный mul/div long для Z80 написан на СИ(!!!), какая уж там оптимизация?!

3. IAR ложит два байтовых параметра в виде двух слов. SDCC в виде двух байтов.

IAR, как и любой компилятор сей/паскалей для Z80 всегда делает PUSH RR, где RR какая то регистровая пара. НО, IAR, если параметры не динамические, сначала будет юзать регистры и только потом стек. опять таки - RTFM.

PUSH AF
INC SP

ОООЙ, это так важно, положить 1 байт на стек и и потратить потом ещё 6 тактов на inc sp. что за чушь?

SDCC улучшают постоянно. Вы просто не следите.

я могу с вами поспорить, что кодогенерация между 3.4.0 и 4.1.0 байт в байт одинаковая! так где изменения и улучшения?

но, во всём этом самое забавное то, что старый Solid C, написанный ещё в 1995 году для MSX и портированный под Спринтер в 2004 году, выдаёт код более компактный и быстрый, чем SDCC, хотя местами и есть у Солида затупы, но какой си без затупов то?!)))
а пресловутый пипхоле - чего там, чего? если посмотреть в его исходники, то становится очевидно, что вся оптимизация сводится к перебору шаблонов которые вкомпилированы. и можно задавать хоть 2000000 глубину этой пипки, результата не будет, а время компиляции растягивается на несколько минут.

я тут сижу над FatFS, переделки там кое какие, оптимизации. так вот, sdcc, Solid-C, IAR участвуют в этом. на текущий момент, SDCC даёт самый худший результат (и это на 4.1.12). даже Солид, у коиторого отродясь нет лонгов, путём вкарячивания "внешней" имитации умудряется обгонять SDCC. При этом, у SDCC весьма странная любовь к индексным регистрам, не смотря на попытку использовать static. А вот IAR и Solid весьма легко от индексных регистров отказываются.

который бы сам запилил оптимизирующий компилятор

оптимизатор может быть внешним, в виде отдельного ехешника. почти все существовавшие компиляторы (большая их часть) сей для z80 имели именно отдельные оптимизаторы. IAR, SDCC, Solid как раз те, в которых оптимизатор внутренний.

[Sayman]

Любите синтетические тесты, по которым Java превосходит Rust в стопицот раз? Угомонитесь уже.
Кстати, я именно это называл уродской работой с индексными регистрами.

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

;	---------------------------------
; Function _Abc
; ---------------------------------
_Abc:
	ld	hl,0x0000
	ld	(_c8),hl
	ld	(_c5),hl
	ld	(_c4),hl
	ld	(_c3),hl
	ld	hl,0x0000
	ld	(_c2),hl
	ld	(_c1),hl
	ld	(_j),hl
	ret
	SECTION code_compiler
;	---------------------------------

28 байт

; 229.	static void Abc (void)
Abc:
; 230.	{
; 231.	    static int j, c1, c2, c3, c4, c5, c8;
; 232.	
	LD	HL,0
	LD	(?0099),HL
	LD	(?0098),HL
	LD	(?0097),HL
	LD	(?0096),HL
	LD	(?0095),HL
	LD	(?0094),HL
	LD	(?0093),HL
; 233.	    j = c1 = c2 = c3 = c4 = c5 = c8 = 0;
	RET
; 234.	}

IAR 4.06a с опцией -z9, 25 байт.

[haywire]

> Кстати, я именно это называл уродской работой с индексными регистрами.

Кстати, я тоже это назвал бы уродской работой с индексными регистрами. Это - выхлоп SDCC, внезапно. IAR индексные регистры в каждую дырку не засовывает.

> Любите синтетические тесты, по которым Java превосходит Rust в стопицот раз?

Люблю синтетические тесты. Но что тут синтетического ? Не вижу тут ничего синтетического.

Я выбираю компиляторы для своей работы.

Вот полный тест с исходником и результатами компиляции

Как видите, SDCC нагенерировал 28582 байта кода, IAR - 16270 байт. Разница - 2 раза. Это абсолютно неприемлемо.
При этом, код SDCC - нерабочий. Разбирайтесь, вам с афтором работы на 50 лет. Этот фрагмент сверху - вырезка оттуда.

Кстати, написать оптимизирующиий компилятор для убогого 8-и битного процессора - вполне реально. Это не для VLIW писать, тут всё проще.
Не за год, конечно, не за 2. Но за 5-10 лет - вполне. Они так все и писались, собственно.
Автор SDCC трудится уже лет 20? Чем он занимается, и где результат - остаётся только догадываться.

[jerri]

IAR код в 2 раза более компактный генерирует

1854 j = c1 = c2 = c3 = c4 = c5 = c8 = 0;
\ 382B 010000 LD BC,0
\ 382E 69 LD L,C
\ 382F 60 LD H,B
\ 3830 221201 LD (?0010+274),HL
\ 3833 ED431401 LD (?0010+276),BC
\ 3837 220E01 LD (?0010+270),HL
\ 383A ED431001 LD (?0010+272),BC
\ 383E 220A01 LD (?0010+266),HL
\ 3841 ED430C01 LD (?0010+268),BC
\ 3845 220601 LD (?0010+262),HL
\ 3848 ED430801 LD (?0010+264),BC
\ 384C 220201 LD (?0010+258),HL
\ 384F ED430401 LD (?0010+260),BC
\ 3853 22FE00 LD (?0010+254),HL
\ 3856 ED430001 LD (?0010+256),BC
\ 385A 221A01 LD (?0010+282),HL
\ 385D ED431C01 LD (?0010+284),BC
\ 3861

// 54 байта

зачем тут 32 битные данные?