Никому не хочется асм переписывать под странный синтаксис sdcc. Но вроде в TODO-листе у sdcc был пункт про то, чтобы встроить его в z88dk.Сообщение от jerri
Никому не хочется асм переписывать под странный синтаксис sdcc. Но вроде в TODO-листе у sdcc был пункт про то, чтобы встроить его в z88dk.
Сообщество z88dk уже давно хочет поюзать sdcc. Для этого в sdcc были добавлены опции совметимости с z88dk. (Какие не припомню, погуглить можно.)
Об этом писал Philip в списке рассылки sdcc.
V6Z80P - Back for Good
Вторая часть перевода статьи о Churrera готова! На этот раз речь идёт о создании тайлсета для построения карты игры.
http://viva-games.ru/stati/sozdaj-sv...ectrum-chast-2
Это написано кем-то незнакомым с инструментами.
Все составляется C будь SDCC, sccz80 (составитель z88dk в), или любой другой известный компилятор z80 C генерирует код, который является по меньшей мере в три раза больше и в три раза медленнее, чем писаные ассемблере.
Точка z88dk является доступность существенной библиотеку ассемблерных подпрограмм, так что C используется в основном как клей ("бизнес-логики"). Большинство время выполнения затем провел в быстром ассемблере и размер программы значительно сокращается, поскольку большая часть его написана на ассемблере.
Это страница с использованием C код для встраивания в QSort и рисование линий, например, когда z88dk содержит QSort и рисования линий функции, написанные на ассемблере. Если те, которые используются z88dk версия в несколько раз быстрее и меньше, чем SDCC.
На этой странице также говорит о нестабильности на КПК в отношении длинных типов. SDCC реализует длинный арифметики в С, тогда как z88dk реализует на ассемблере с использованием подпрограмм, использующих набор EXX. Эти функции очень малы и быстро, но на КПК использования регистров EXX заставляет систему к краху, если прерывания не отключены.
Сравнение двоичных размеров больно, игнорируя содержимое ЭЛТ. SDCC имеет голую минимальной поддержки для PRINTF части STDIO и не имеет ни малейшего понятия о файлах. Стандартные ЦППС z88dk назвать обеспечение вещи, как стандартного ввода, стандартный вывод, стандартный поток ошибок. ЭЛТ, что КПК люди используют с SDCC не делать ничего, кроме инициализации сегмент данных, но элт z88dk предоставляет также инициализирует кучи и системное программное обеспечение. Это добавляет к двоичному размера.
Дело о сгенерированного компилятором кода является правильным. SDCC пытается оптимизировать и встроенный сгенерированный код. Это выглядит лучше невооруженным глазом, для использования IX как указатель кадра, за исключением. sccz80 (компилятор z88dk в) вместо пытается превратить основные функции компилятора в подпрограммам. Это должно привести к меньшему кода, и это на самом деле то, что мы видим в наших тестах в сравнении с использованием SDCC с z88dk. Но sccz80 не оптимизирующий компилятор, как SDCC так, что размер кода преимущество может произойти, только если программист осознает, что может привести к sccz80 получать большие код.
В любом случае, это не в курсе сравнение
У нас уже есть SDCC работает с z88dk, в том числе с пакетом обновления 1 (спрайт двигателя). Если кому-то интересно вы можете помочь нам тест.
Все эти программы испытаний могут быть скомпилированы либо SDCC или sccz80 без каких-либо модификаций на источник:
https://drive.google.com/open?id=0B6...Nm8&authuser=0
С Churerra, что Mojón близнецы используете очень старую версию z88dk и старую версию текущего двигателя спрайт (SP1) так что все должны быть обновлены в источнике churerra до SDCC можно использовать для компиляции.
======================
This is written by someone unfamiliar with the tools.
All compiled C whether by sdcc, sccz80 (z88dk's compiler), or any other known z80 C compiler generates code that is at least three times larger and three times slower than hand-written assembler.
The point of z88dk is to make available a substantial library of assembler subroutines so that C is mainly used as glue ("business logic"). Most execution time is then spent in fast assembler and program size is much reduced because much of it is written in assembler.
That page is using C code to implement qsort and line drawing, for example, when z88dk contains qsort and line drawing functions written in assembler. If those are used the z88dk version is several times faster and smaller than sdcc.
The page also talks about instability on the cpc with regards to long types. sdcc implements long arithmetic in C whereas z88dk implements it in assembler using subroutines that use the EXX set. These subroutines are very small and fast but on the cpc use of EXX registers causes the system to crash unless interrupts are disabled.
The comparison of binary sizes is hurt by disregarding the contents of the crts. sdcc has bare minimum support for the printf part of stdio and has no concept of FILEs. z88dk's standard crts are providing things like stdin, stdout, stderr. The crts that the cpc folks use with sdcc do nothing except initialize the data segment but the crt z88dk is providing also initializes the heap and system software. This adds to the binary size.
The point about compiler-generated code is correct. sdcc tries to optimize and inline generated code. This looks better to the naked eye, except for the use of ix as frame pointer. sccz80 (z88dk's compiler) instead tries to turn basic compiler functions into subroutine calls. This should lead to smaller code and that is in fact what we see in our tests versus using sdcc with z88dk. But sccz80 is not an optimizing compiler like sdcc is so that code size advantage can only happen if the programmer is conscious of what will cause sccz80 to generate large code.
In any case, it's not an informed comparison
We already have sdcc running with z88dk, including sp1 (the sprite engine). If anyone is interested you are welcome to help us test.
All of these test programs can be compiled with either sdcc or sccz80 without any modifications to the source:
https://drive.google.com/open?id=0B6...Nm8&authuser=0
With Churerra, the mojon twins are using a very old version of z88dk and an old version of the current sprite engine (sp1) so things would have to be updated in the churerra source before sdcc could be used to compile it.
Попробовал перевести чуть лучше, чем это сделал Google Translate.
---------------------------------------------------------------------
Это написано кем-то, кто не знаком хорошо с инструментами (SDCC и z88dk, очевидно).
Всё, что скомпилировано из C либо с помощью sdcc, sccz80 (компилятор z88dk) или любым другим известным компилятором C под z80, генерирует код по меньшей мере в 3 раза больше и три раза медленнее, чем код, написанный на asm вручную.
Цель z88dk - сделать доступной существующую библиотеку подпрограмм на Asm, так что C главным образом используется как "клей" ("бизнес-логика"). Основное время выполнения в этом случае тратится на быстрый ассемблер и размер программы значительно уменьшается из-за того, что большая часть написана на asm.
На той странице используется C для реализации qsort и рисования линий, например, когда z88dk содержит qsort и алгоритм рисования линий написанные на asm. Если они используют z88dk-версию, она в несколько раз быстрее и код короче, чем sdcc.
На той странице также говорится о нестабильности cpc в связи с типом long. sdcc реализует арифметику с long в C, в то же время z88dk реализует её в asm с помощью подпрограмм, которые используют расширенный набор регистров. Эти подпрограммы очень короткие и быстрые, но использование расширенного набора регистров вызывает крах системы, если прерывания не запрещены.
Сравнение размеров бинарников некорректно, если не учитывать отношение к crt-функциям. SDCC имеет предельно минимальную поддержку printf-части библиотеки stdio и не имеет никакой концепции работы с файлами. Стандарты z88dk crt предоставляют вещи вроде stdin, stdout, stderr. Библиотеки CRT, которые использует народ CPC из SDCC ничего не делают, за исключением инициализации сегмента данных, а CRT из z88dk делают также инициализацию "хипа" и системных программ. Это и добавляет размер к бинарнику.
Точка зрения о коде, который сгенерирован компилятором, верна. SDCC пытается оптимизировать inline-сгенерированный код. Это выглядит лучше для невооружённого глаза, за исключением использования регистра IX как указателя. sccz80 (компилятор пакета z88dk) вместо этого пытается включить базовые функции компилятора в вызовы подпрограмм. Это должно приводить к меньшему коду и это по факту то, что мы видим в наших тестах по сравнению с использованием sdcc с z88dk. Но sccz80 - не оптимизирующий компилятор, в отличие от sdcc, так что код зависит только от программиста, который учитывает, что именно приведёт к увеличению длины кода, сгенерированного sccz80.
В любом случае, это сравнение неинформативно.
--------
Цитата:
Сообщение от Valen
Сообщество z88dk уже давно хочет поюзать sdcc. Для этого в sdcc были добавлены опции совметимости с z88dk. (Какие не припомню, погуглить можно.)
Об этом писал Philip в списке рассылки sdcc.
----------
Мы уже запускаем sdcc с z88dk, включая sp1 (спрайтовый движок). Если кто-то заинтересован, приглашаем помочь нам с тестированием.
Все эти программы могут быть скомпилированы либо SDCC, либо sccz80 без каких-либо модификаций в исходниках:
https://drive.google.com/open?id=0B6...Nm8&authuser=0
В Чуррере Близнецы Мохоны используют очень старую версию z88dk и старую версию спрайтового движка (sp1), поэтому эти вещи должны бы быть обновлены в исходниках Чурреры перед тем, как возможно станет использовать SDCC для его компиляции.
Третья часть описания Чурреры уже доступна! Авторы рассказывают о том, как имея созданный во второй части комплект графических плиток, нарисовать карты игры.
http://viva-games.ru/stati/sozdaj-sv...ectrum-chast-3
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Alcoholics Anonymous,
This is all interests, but all the tests I've seen, showed that z88dk always produces slow code. 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.
Я не утверждаю, что сгенерированный компилятором код всегда медленнее.Причина в том, 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.
[свернуть]
Что это тест тестирование? Это тестирование C-компилятор сгенерированный код. Это не для тестирования библиотеки.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.
С играх суть ясна. Причина, по которой 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:
62 bytes.Код:_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:
z88dk реализации на ассемблере:
21 байт.Версия 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
Вот один я не буду компилировать как это слишком долго. Просто посмотрите на него, и вы можете видеть, что это гораздо медленнее и гораздо больше, чем 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.
[свернуть]
Глава 4 руководства по разработке игр для ZX Spectrum от Mojon Twins рассказывает о том, что такое спрайты и как их поюзать в парадигме Спектрума и движка Churrera.
http://viva-games.ru/stati/sozdaj-sv...ectrum-chast-4
Epsilon, а какой наиболее корректный перевод "la abadia del crimen"? Поиск выдает различные варианты перевода, какой более правильный не понятно.
___________
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
