Ищу Си для Z80

[Alcoholics Anonymous]

HiTech C постоянно выдаёт более быстрый код. Я перекопал форум msx, там довольно много кода сравнивали с z88dk, sdcc, msx-c и htc (как 3.09 так и 7.50/7.80). Почти всегда хайтех в лидерах.
вот пример странички
http://www.msx.org/forum/development...rison-part-two
а тут конкретно z88dk и htc
http://www.msx.org/forum/development...art-two?page=2
6 пост сверху

Есть ли у вас ссылка на полной программе, чтобы проверить? Ни один из программ в этой дискуссии не будет полным - часть исходного кода была отрубили по некоторым причинам.

Скрытый текст

Do you have a link to a complete program to test? None of the programs in that discussion is complete -- some of the source code has been chopped off for some reason.

[свернуть]

В общем, люди не используют компиляторы должным образом. Например, вы не должны использовать встраиваемые ASM с SDCC, потому что это мешает локальной оптимизации. Вы можете получить некоторые странные код из SDCC как статических нагрузок не избежать, если встроен ASM вставляется в C коде. С sccz80 (родной компилятор z88dk), а на самом деле со всеми компиляторами, лучше Код производительности должны использовать глобальные или локальные статику, если это разумно. Особенно с sccz80 это может сделать большую разницу в производительности. Оптимизация должна быть положить на макс, и многие люди не знают, как это сделать. С sccz80 Это -O3 и SDCC, который заходящего --max-allocs-per-node на что-то высокое (как 200000). Обычно вы можете получить лучший код из SDCC, запрещая использование слишком гу, добавив --reserve-regs-iy.

Скрытый текст

In general, people are not using the compilers properly. For example, you should not be using inlined asm with sdcc because it interferes with peephole optimization. You can get some weird code out of sdcc like dead loads not being eliminated if inlined asm is inserted into C code. With sccz80 (z88dk's native compiler) and actually with all the compilers, best performance code should be using globals or local statics if that is reasonable. Especially with sccz80 this can make a big difference in performance. Optimizations should be put on max and many people don't know how to do that. With sccz80 that's -O3 and with sdcc that's setting --max-allocs-per-node to something high (like 200000). You can usually get better code out of sdcc by forbidding use of iy too by adding --reserve-regs-iy.

[свернуть]

sccz80-сгенерированный код никогда не будет самым быстрым. Причина он пытается реализовать компилятора операции, используя вызовы подпрограмм, чтобы быть наименьшим. При том, что в сочетании с языка ассемблера библиотеки, где производительность, как предполагается, пришли, результат маленький и быстрый код. sccz80 сгенерированный код, как правило, меньше, чем SDCC или HITECH, иногда с большим отрывом, но sccz80 требует программировать для компилятора, а не делать вид, что это 32-битная платформа с кодом. Вы можете видеть, что в некоторых крупных программ, составленных мы. Например, clisp.c - это Lisp interpretter> 1200 строк в C - компилирует 27000 байт под sccz80 и 32000 байт под HTCv7.50. startrek.c (> 2100 строк в C) доходит до 41000 байт под HTCv7.50 и 32600 байт под z88dk + SDCC. Последнее особенно связано в основном с более библиотек z88dk так размер кода похож на HTC и SDCC если код библиотеки исключены.

Скрытый текст

sccz80-generated code is never going to be the fastest. The reason is it's trying to implement compiler operations using subroutine calls in order to be the smallest. When that is combined with assembly language libraries, where the performance is supposed to come from, the result is small and fast code. sccz80 generated code is normally smaller than sdcc or hitech, sometimes by a large margin, but sccz80 requires you to program for the compiler rather than pretend it's a 32-bit platform with the code. You can see that in some of the large programs we compiled. Eg, clisp.c -- a lisp interpretter > 1200 lines in C -- compiles to 27000 bytes under sccz80 and 32000 bytes under HTCv7.50. startrek.c (> 2100 lines in C) comes to 41000 bytes under HTCv7.50 and 32600 bytes under z88dk+sdcc. The latter especially is due mainly to better libraries in z88dk since code size is similar for HTC and sdcc if library code is excluded.

[свернуть]

Версия z88dk на sourceforge (1.10) не является текущей. Текущая версия может использовать SDCC, как компилятор, улучшить свой код несколько, и поставить на ассемблере библиотеки из z88dk. Это то, что, кажется, превосходит все остальное большую часть времени в скорости, размер кода и полноты. Я очень заинтересован в поиске, когда эта комбинация не так хорошо, другие компиляторы, чтобы увидеть, где некоторые очевидные улучшения могут быть сделаны.

Скрытый текст

The version of z88dk at sf (v1.10) is not current. The current version is able to use sdcc as compiler, improve its code somewhat, and supply assembly language libraries from z88dk. This is what seems to be outperforming everything else most of the time in speed, code size and completeness. I'm very interested in finding out when this combination does not perform as well as other compilers to see where some obvious improvements can be made.

[свернуть]

[Advertiser]

[Sergey]

Let me know if it doesn't work.

It works fine. 512 sec. Great!

Can You give "magic" command line options for ZCC?

[Alcoholics Anonymous]

Can You give "magic" command line options for ZCC?

You must have sdcc installed.

sdcc must be modified a little bit to be compatible with z88dk. If you are running on windows, copy zsdcc.exe from this zip file to sdcc's bin directory sdcc/bin. If you're not running on windows, check out http://www.z88dk.org/wiki/doku.php?id=temp:front#sdcc1 .

You must have a recent version of z88dk installed. I'd suggest waiting until the Dec 15 build is finished in about 3 hours from now. I put in a fix so the tools will not crash if the source contains Cyrillic letters. The nigthly build is here: http://nightly.z88dk.org/ Click on the latest win32 build and unzip where you like. You must set a few environment variables as described here: http://www.z88dk.org/wiki/doku.php?i...:front#windows sdcc should also be in the path.


z88dk compiles are very configurable so one compile line (and a set of pragmas in your source code) does not always fit. The library can also be rebuilt to make the compiled code faster or smaller by selecting different options. For example, you can opt out of individual printf/scanf converters to reduce size or you can enable the fast integer library if you are ok with an additional ~1k code. The latter makes z88dk's integer math several times faster than all other compilers. If you read through the links mentioned in this section: http://www.z88dk.org/wiki/doku.php?i...ling_with_sdcc you will have an idea of how things work.


A general magic compile line for the zx looks like one of these:

32 column stdin/stdout/stderr z88dk terminal drivers
zcc +zx -vn -SO3 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test

64 column stdin/stdout/stderr z88dk terminal drivers
zcc +zx -vn -SO3 -startup=4 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -startup=4 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test

fzx proportional fonts stdin/stdout/stderr z88dk terminal drivers
zcc +zx -vn -SO3 -startup=8 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -startup=8 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test

Nothing on stdin/stdout/stderr
zcc +zx -vn -SO3 -startup=31 -clib=sdcc_ix --reserve-regs-iy --max-allocs-per-node200000 test.c -o test
zcc +zx -vn -SO3 -startup=31 -clib=sdcc_iy --max-allocs-per-node200000 test.c -o test


The "-clib=sdcc_iy" compile gives IX to sdcc and IY to the c library. This will be the smallest and fastest code. However, you must disable interrupts or have your own isr installed because the rom interrupt uses iy and if it runs, it will be poking random stuff into memory and eventually cause a crash.

The "-clib=sdcc_ix" option has sdcc and the c library sharing IX. The rom isr can continue to run.


You must add "-lm" if using floats. If you need to printf floats (%aefg) you must re-build the library because the default build has %aefg disabled. You can also use stdlib functions dtoa / ftoa, etc to render floats into text.


The default zx crt is doing something we call an "automatic malloc". It creates a heap between the end of the program and the bottom of the stack automatically when the program runs. If it finds the available space is 0 or less, the program will just exit without any indication. This can happen if you CLEAR before loading the program because CLEAR moves the stack underneath the executable. So by default the crt also moves the stack pointer underneath the UDGs. For someone new to C and just wanting to compile stuff, this is most often what is wanted. But for more complicated programs this is often not what you want. You can put pragams into the source to change the crt behaviour. These two may be helpful:

#pragma output REGISTER_SP = -1 // do not change the stack pointer
#pragma output CLIB_MALLOC_HEAP_SIZE = 0 // do not create a heap

z88dk's library and crts are very configurable so if you use it, take some time to learn these things in order to make best use of the compiler.


If you get things working, try compiling your program in the zip I posted a little further back. The compile line I used is listed at the top of the .c file. You can make the result a little bit faster by changing the function linkage of put__ch() and print() like this:

unsigned char* put__ch(char sym) __z88dk_fastcall
void print(char* str) __z88dk_fastcall

Adding "__z88dk_fastcall" will make sdcc pass a single parameter by register instead of by stack. This shaves another 10 seconds or so from running time.


There are a few example programs in z88dk/libsrc/_DEVELOPMENT/EXAMPLES

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

Когда пытался использовать sdcc и z88dk столкнулся с непониманием как разделить код по необходимости компиляции в медленную/быструю память. Как сделать ?

В z88dk пространство памяти делится на разделы. Раздел представляет собой контейнер, чем может удерживать код или данные и может иметь дополнительный Org. По умолчанию компилирует настроить карту памяти, которая будет производить один двоичный в разделе "CODE" (так выходные двоичные файлы из z88dk всегда будет под названием "name_CODE.bin"); это на самом деле содержит двоичный код традиционной / части DATA / BSS исполняемого все слиплись.

Это очень легко иметь код компилятора компиляции на 32768 и есть один раздел определяемые пользователем отображается на 23296, например, что вы положили данных или подпрограммы по сборке в. Просто создайте другой файл, как это:

Скрытый текст

In z88dk the memory space is divided into sections. A section is a container than can hold code or data and can have an optional ORG. The default compiles set up a memory map that will produce a single binary in the "CODE" section (so output binaries from z88dk will always be called "name_CODE.bin"); this binary actually contains the traditional CODE/DATA/BSS parts of an executable all stuck together.

It's very easy to have the compiler compile code at 32768 and have another user-defined section mapped to 23296, eg, that you put data or assembly routines into. Just create another file like this:

[свернуть]

SECTION LOWMEM
org 23296

PUBLIC _map

_map: defs 100

...

И добавить его к линии компиляции. Тогда выход будет два бинарных файла: "name_CODE.bin", содержащий C код компилятора на 32768 и "name_LOWMEM.bin", содержащий другие вещи, которые должны быть загружены по адресу 23296.


Это, как большинство людей используют нижние области памяти, потому что это легко. Если вы действительно хотите, чтобы скомпилировать код там, вы должны сказать SDCC использовать другое имя раздел, и это делается по линии компиляции. Я никогда не делал этого, так что я не могу дать конкретные указания. В любом случае, если вы сообщите его скомпилировать в разделе "Lowmem", код будет поставить там. Но SDCC можно скомпилировать только одной секции с каждого исходного файла. Так что вам нужно сделать, это разделить ваш источник C, так что каждый С файла относится к собственной секции. Тогда ты скомпилировал бы каждый файл C объектный файл, а затем, наконец, положить все это вместе на последнем этапе компиляции. Затем выводе будет одним двоичным в разделе определенной которые вам придется загрузить в память.

Вот как это будет работать с z88dk но я никогда не делал этого раньше.

Скрытый текст

And add it to the compile line. Then the output will be two binaries: "name_CODE.bin" containing the C compiler code at 32768 and "name_LOWMEM.bin" containing the other stuff that should be loaded at address 23296.


This is how most people are using the lower areas of memory because it's easy. If you actually want to compile some code there, you have to tell sdcc to use a different section name and this is done on the compile line. I have never done this so I can't give specific instructions. Anyway if you tell it to compile into the "LOWMEM" section, code will be put there. But sdcc can only compile to one section with each source file. So what you need to do is divide up your C source so that each C file belongs to its own section. Then you would compile each C file to an object file and then finally put it all together in the last compile step. Then the ouput will be one binary per section defined which you will have to load into memory.

That's how it would work with z88dk but I have never done this before.

[свернуть]

[Sergey]

Добавил в табличку информацию об эффективности WarpC: 0,066.

[savelij]

Добавил в табличку информацию об эффективности WarpC: 0,066.

Как насчет измерения для BDS C и вот этого компилера раз пошла такая пьянка

[Sergey]

С BDS не помню, почему до сих пор не потестил. А по второму, - вот:
Занятная штуковина этот Mescc. Подвид Small C Compiler, синтаксис K&R. Не умеет инициализированные массивы. Зато очень беспечен ко всему, что заключено между #asm/#endasm. Так массивы и впихнул Особенно порадовала работа с объявлением функций, написанных на асме. Главное, чтобы у неё была своя метка. Остальное - мало..учий факт: компилятор передаст ей столько аргументов, сколько захочешь, любых типов - сам отвечаешь, что у тебя подпрограмма из этого "скушает", не нужно каким-либо образом формально сообщать компилятору количество и тип аргументов, а также и тип возвращаемого значения и то, есть оно или нет. Анархия - мать порядка!
Интересная особенность: аргументы передаются в порядке, обратном обычному: первым со стека снимается последний аргумент, а не первый.
Выдаваемый код ужасен. По каждому чиху call на runtime-функции, состоящие из 3-х-4х комманд, а с локальными переменными какие пляски с бубном устраивает, - зрелище не для слабонервных. Хоть он и заявлен, что Z80, от Z80 у него только мнемоники в выходном ассемблерном файле, - локальные переменные используются через мудрёные спецпроцедуры, - про индексные регистры компилятор не в курсе . Итак: MeSCC: 0,0386/0,0667.

Но есть и положительные моменты: если использовать его как макроассемблер с Си-синтаксисом, ужасность его кода для конечного результата особого значения не имеет. И, учитывая, что есть исходники и компилятора и используемого им ассемблера, его возможно достаточно легко портировать в ТR-DOS. Нативный компилятор Си, выдающий верный код, на Спеке лишним не будет

Прилагаю архивчик с SCL, а также исходники теста, модифицированный mescc.h (обязательно инклюдить) и скрипт на REXX, который поможет интересующимся собирать на Mescc приложения для Спектрума. (Изменения внесены на скорую руку. Если кому-то интересно, - тогда уже отрехтую для серьёзной работы ).

[Sergey]

BDS C так и не осилил - очень ограниченный. Трудновато слепить на нём печаталку.
Зато побаловался с MI-C. Результат таков: 0,0776/0,0859.
В процессе не удалось пока собрать всё штатными средствами - m80/l80. Поэтому поступил так:
Сгенерил компилятором ассемблерный файл и перенёс его в ALASM. То же самое сделал и с runtime библиотекой, которая хранится в ассемблерном файле.
Добавил служебных процедурок для замера времени, и всё. Ассемблится и запускается ручками в ALASM/STS. Результат можно посмотреть в дампе памяти по адресу #60BC ("PASSED:nnn"). Полуфабрикат, конечно, зато интересующиеся смогут посмотреть выдаваемый MI-C код. ТРДшник прилагаю.
Как компилятор K&R, MI-C, вполне, адекватный, каких-либо неудобств с точки зрения совместимости С-кода не ощутил. BDS C с ним не сравнить.
Однако, особенностей Z80 компилятор не использует, а лишь способен выдавать ассемблерный текст в соответствующих мнемониках. Ну, и, понятно, к локальным переменным обращается не через индексные регистры, а через HL, складывая указанное в ней смещение со значением SP.

[Totem]

а zds 3.68 от зилога не встречалось никому с невыпеленым компилятором С ?

[Sergey]

Добавил в табличку сведения по HiSoft-C.
Вообще, я хотел проверить версию для TR-DOS, однако не вышло - компилятор почему-то ругается на нехватку памяти. Поэтому, чтобы получить представление о возможностях спектрумовского компилятора пришлось использовать его cp/m-ного собрата. Правда, на спектруме используется более старая версия: 1.1.
Для версии с глобальными переменными коэффициент относительно аналогичной программы на ассемблере составил 0,0882.
256 вызовов отработали за 366 секунд.
Этот компилятор генерит сразу машинный код, минуя стадию ассемблера, и не даёт возможности компиляции под произвольный адрес - только с 0x100.
Но, поскольку каких-либо функции, завязанных на CP/M я не использовал, то решил задачу в лоб: полученный com-файл CP/M запустил на Пентеве с адреса 0x100. И всё получилось.
HiSoft-C заточен именно на Z-80, обращается к локальным переменным через IX. Однако качество кода настолько низкое, что по эффективности, фактически, ничем не отличается от компиляторов для I8080.

[Smalovsky]

Установил SDCC и Codeblocks.
Настройку для среды делал по сайту http://www.ibm.com/developerworks/ru...locks_and_sdcc
В Compilier settings установил флаги [CPU]Zilog Z80[-mz80] и [Z80]When lincing, skip stsndard crt0.o object file[--no-std-crt0]
В Linker settings добавил флаги в поле Other linker options:
--code-loc 0x7530
--data-loc 0xA530
Создап проект. В настройках проекта на вкладке Build targets для Debug и Release выбрал Type не Console Applications, а Native, при этом убрал флажок Auto-generate filename extension и вручную прописал расширение HEX.
Правильно ли я сделал настройки? Сделал пробную пробную сборку. Как делать ассемблерные вставки и как передаются параметры для ассемблерной процедуры?