Сообщение от
Sayman
This is all interests, but all the tests I've seen, showed that z88dk always produces slow code.
Я не утверждаю, что сгенерированный компилятором код всегда медленнее.Причина в том, sccz80 пытается сделать все свои операции с вызовов подпрограмм. Это отличается от SDCC, например, который пытается встроить код. В результате бывший, как правило, меньше, а второй, как правило, быстрее. Честно говоря, когда у вас есть ASM библиотеки, которые быстро, вы обычно хотят, чтобы компилятор генерировать меньшую код из-за малого количества памяти, доступной на Z80 систем.Давление на память острее, чем это делается на скорость для крупных проектов - просто посмотрите на C игр, которые оказались. Нередко жалоба, что они слишком коротка! Но и это давление на средства памяти спецэффекты иногда приходится быть опущены. Почему не C игры имеют волнистые воды или других анимированных фоновых эффектов? Это не потому, что спрайт двигатель не может делать.
Скрытый текст
I don't argue that the compiler-generated code is always slower. The reason is sccz80 tries to do all its operations with subroutine calls. This is different from sdcc, for example, which tries to inline code. The result is the former approach tends to be smaller and the latter tends to be faster.
Honestly, when you have asm libraries which are fast, you usually want the compiler to generate smaller code because of the small amount of memory available on z80 systems. The pressure on memory is more acute than it is on speed for large projects -- just look at the C games that are turned out. Quite often the complaint is that they are too short! But also this pressure on memory means special effects sometimes have to be omitted. Why don't C games have wavy water or other animated background effects? It's not because the sprite engine can't do them.
[свернуть]
sdcc or z88dk or old hi-tech-c 3.09 (for cp/m) used with asm libs (however, stock HTC 3.09 have 90% libs written in C).
you can see another test:
http://zx-pk.ru/showpost.php?p=696109&postcount=91
z88dk is not present, but sdcc 3.4.0 have best performance.
Что это тест тестирование? Это тестирование C-компилятор сгенерированный код. Это не для тестирования библиотеки.
С играх суть ясна. Причина, по которой z88dk используется почти исключительно для игр, написанных на C, потому что он имеет библиотеку спрайтов АНМ в нем. Если вы написали эту библиотеку на С, было бы, может быть, четыре раза медленнее и более. Если игра работает, скажем, 17 кадров в секунду, то при C-эквивалентной может работать при 4 кадров в секунду, которые были бы неприемлемыми.
Другими словами, библиотека ASM требуется. С этой библиотеке АНМ в месте, наиболее время выполнения расходуется в быстром АНМ и медленно код С используется только для логики. Но из-за медленного код С является лишь небольшая часть игрового цикла, это нормально, чтобы использовать С в течение этой части.
То же самое относится ко всему остальному. Вы хотите больше времени выполнения будут потрачены на ассемблере код не намного медленнее кода C. Это может произойти, только если программисты используют код библиотеки, и если есть большое количество библиотек кода, доступного для всех ситуаций.
Тест для небольших систем необходимо сравнить скорости и размер зависит от того, компилятор используется на небольших системах.
Asm библиотеки влияет на скорость, но и размер кода не только. Что-то вроде Fuzix написано в чистом С, который имеет один мощное преимущество и один мощный недостаток. Преимущество в том, что Fuzix может быть с легкостью перенесены с различных машин и процессоров. Сейчас Fuzix может быть скомпилирован для 6502, 6809 и Z80 целей. Недостатком является то, что составлен C гораздо больше, чем ассемблерный эквивалент. 40k след на z80 не оставляет много места для приложений.
Мы можем смотреть на несколько маленьких кусочков библиотечного кода, который z88dk и Fuzix имеют общие черты:
Скрытый текст
What is this benchmark testing? It is testing the C-compiler generated code. It does not test the libraries.
With games the point is clear. The reason why z88dk is almost exclusively used for games written in C is because it has an asm sprite library in it. If you wrote this library in C, it would be maybe four times slower or more. If the game operated at, say, 17 frames per second then under a C-equivalent it might operate at 4 frames per second which would be unacceptable.
In other words, the asm library is required. With that asm library in place, most execution time is spent in the fast asm and the slow C code is only used for the logic. But because the slow C code is only a small portion of the game loop, it's ok to use C for that part.
The same applies to everything else. You want most execution time to be spent in asm code not the much slower C code. This can only happen if programmers use the library code and if there is a large amount of library code available for all situations.
A benchmark for small systems needs to compare speed and size based on how the compiler is used on small systems.
Asm libraries not only affect speed but also code size. Something like Fuzix is written in pure C which has one powerful advantage and one powerful disadvantage. The advantage is that Fuzix can easily be ported between different machines and processors. Right now Fuzix can be compiled for 6502, 6809 and z80 targets. The disadvantage is that the compiled C is much larger than an asm equivalent. The 40k footprint on the z80 does not leave much room for applications.
We can look at a few small bits of library code that z88dk and Fuzix have in common:
[свернуть]
Fuzix strchr()
https://github.com/EtchedPixels/FUZI.../libs/strchr.c
Собран с SDCC:
Код:
_strchr_start:
_strchr:
push ix
ld ix,0
add ix,sp
dec sp
ld e,(ix+4)
ld d,(ix+5)
l_strchr_00106:
;strchr.c:6: return s;
ld a,(de)
ld (ix-1),a
ld b,a
rla
sbc a, a
ld c,a
ld a,(ix+6)
sub a, b
jr NZ,l_strchr_00102
ld a,(ix+7)
sub a, c
jr NZ,l_strchr_00102
;strchr.c:7: if (ch == 0)
ex de,hl
jr l_strchr_00108
l_strchr_00102:
;strchr.c:8: return 0;
ld a,(ix-1)
or a, a
jr NZ,l_strchr_00104
;strchr.c:9: s++;
ld hl,0x0000
jr l_strchr_00108
l_strchr_00104:
;strchr.c:10: }
inc de
jr l_strchr_00106
l_strchr_00108:
inc sp
pop ix
ret
_strchr_end:
62 bytes.
z88dk реализации на ассемблере:
Код:
_strchr:
pop af
pop hl
pop bc
push bc
push hl
push af
asm_strchr:
; enter : c = char c
; hl = char *s
;
; exit : c = char c
;
; found
;
; carry reset
; hl = ptr to c
;
; not found
;
; carry set
; hl = 0
;
; uses : af, hl
loop:
ld a,(hl)
cp c
ret z
inc hl
or a
jr nz, loop
jp error_zc
;;; error_zc is an exit function used many times in the library
error_zc:
ld hl,0
scf
ret
21 байт.Версия z88dk во много раз быстрее.
Вот один я не буду компилировать как это слишком долго. Просто посмотрите на него, и вы можете видеть, что это гораздо медленнее и гораздо больше, чем z88dk версии.
Скрытый текст
21 bytes. The z88dk version is many times faster.
Here's one I won't compile as it's too long. Just look at it and you can see it is much slower and much larger than the z88dk version.
[свернуть]
Fuzix malloc:
https://github.com/EtchedPixels/FUZI.../libs/malloc.c
z88dk malloc:
http://z88dk.cvs.sourceforge.net/vie....5&view=markup
http://z88dk.cvs.sourceforge.net/vie....4&view=markup
Это сообщение будет слишком долго, если я продолжать, но вы получите идею. Fuzix в C составляет около 40 тыс. В ASM она, вероятно, будет ~ 16k. Если бы это было собрано с SDCC-z88dk это, вероятно, будет меньше и быстрее, хотя это не так просто, как только его перекомпиляция, как библиотека z88dk в делает много вещей, которые ядро Linux делает, но это не Linux так много библиотечные подпрограммы должны быть изменены.
Скрытый текст
This post will be too long if I go on but you get the idea. Fuzix in C is about 40k. In asm it would likely be ~16k. If it were compiled with sdcc-z88dk it would likely be both smaller and faster although it's not as simple as just recompiling it as z88dk's library does many things that a linux kernel does but it's not linux so many library routines would have to be changed.
[свернуть]
Ответить с цитированием