Ищу Си для Z80

[Alcoholics Anonymous]

HI-TECH Z80 C Compiler написан на Си HI-TECH Z80 C Compiler. ВО!!!. Академичные алгоритмы мало интересны для Z80 если они не могут переплюнуть разработку 83 года) Тем более не адекватностью генерируемого кода зашкаливает у новоделов.

Знаем, смотрели Си HI-TECH Z80 в IDA Pro с хитрыми макросами. Написан на СИ.

Hitech C CPM уступает по справедливой отрывом z88dk / SDCC. Hitech C v7.50 для DOS ближе. Вы можете взглянуть на некоторые из сравнений, которые мы сделали 10 месяцев назад с использованием реальных программ и общих критериев:

http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1

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

Где Hitech действительно выходит вперед в скорости в плавающей точкой, когда он работает. Но причина этого в том, что реализация флоат Hitech является 32-бит, тогда как z88dk является 48-битный.

Есть и другие факторы, помимо качества генерации кода, которые являются важными или более важными. Такие вещи, как соответствие стандартам качества, библиотек и гибкого набора инструментов. Я бы сказал Hitech был превзойден по всем этим пунктам. Так что нет, я не совсем согласен с вашей оценкой, что современные инструменты не лучше, чем в 1983 г. продукт

Существует текущее развитие при помощи LLVM с C фоновым, а затем передавая, что через компилятор Z80 C для генерации кода. LLVM выполняет больше оптимизацию, чем SDCC и, похоже, может быть, LLVM-> sdcc-> z80 может генерировать лучший код. Еще одна интересная возможность это открывает использует LLVM для компиляции других языков на C, которые затем могут быть скомпилированы для Z80. Это именно то, как работает Оберон Олега.

Зачем идти от LLVM-> C, а не LLVM-> z80? Причина заключается в задний конец инструмента LLVM являются не подходят для генерации кода для 8-битных целей. Много усилий придется вложить, чтобы сделать это. Маршрут LLVM-> C ярлык и выглядит, как это может быть нормально, даже для перевода C-> C. Но я думаю, что более интересный аспект будет на других языках, переведенных на C после оптимизации с помощью LLVM.

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

Hitech C CPM is outperformed by a fair margin by z88dk/sdcc. Hitech C v7.50 for DOS is closer. You can have a look at some of the comparisons we did 10 months ago using real programs and common benchmarks:

http://www.z88dk.org/wiki/doku.php?i...#dhrystone_2.1

Since then I would not expect much change in speed for z88dk/sdcc but some types of programs will be significantly smaller now.

Where Hitech does come out ahead in speed is in the floating point, when it works. But the reason for that is that Hitech's float implementation is 32-bit whereas z88dk's is 48-bit.

There are other factors besides quality of code generation that are important or more important. Things like standards compliance, quality of libraries and flexible toolchain. I would say Hitech has been surpassed on all these points. So no, I don't quite agree with your assessment that modern tools are no better than a 1983 product

There is current development in using LLVM with a C back-end and then passing that through a Z80 C compiler to generate code. LLVM performs more optimizations than sdcc and it looks like maybe LLVM->sdcc->z80 might generate better code. Another interesting possibility this opens up is using LLVM to compile other languages to C which could then be compiled to z80. This is exactly how Oleg's Oberon works.

Why go from LLVM->C rather than LLVM->z80? The reason is LLVM's back end tools are not suitable for generating code for 8-bit targets. A lot of effort would have to be invested to do that. The LLVM->C route is a shortcut and looks like it might be ok even for C->C translation. But I think the more interesting aspect would be other languages translated to C after optimization by LLVM.

[свернуть]

[Advertiser]

[Oleg N. Cher]

Alcoholics Anonymous, let me request a feature :-)

Can you improve the functionality of the convention call __z88dk_fastcall to pass not only one argument, but two too? The register that be used for passing the second argument will be determined in advance.

To reduce the complexity, I suggest yet to allow the second argument only of size 1 (or 2) bytes, and use C (or BC) to pass it. For the first argument, let everything is as it is now: L, HL, HL : DE

Yeah, it looks like a half-measure, but can you have a better idea? Or, you never want to pass arguments in this manner?

P.S. I have functions like Plot(char x, char y), Draw(char x, char y), etc, and I want to pass the arguments using registers.

[Alcoholics Anonymous]

Can you improve the functionality of the convention call __z88dk_fastcall to pass not only one argument, but two too? The register that be used for passing the second argument will be determined in advance.

I can have a look at it but it may take a while to get to it.... the to-do list is long

[Oleg N. Cher]

Now for a function that uses two arguments, I use this way:

/*--------------------------------- Cut here ---------------------------------*/
unsigned char Basic_ATTR_callee (unsigned char y, unsigned char x) __z88dk_callee {
__asm
  POP  HL
  POP  BC
  PUSH HL
  CALL 0x2583
  CALL 0x2DD5
  LD   L,A
__endasm;
} //Basic_ATTR_callee

/*--------------------------------- Cut here ---------------------------------*/
unsigned char Basic_ATTR_fastcall (unsigned int yx) __z88dk_fastcall {
__asm
  LD   C,L
  LD   B,H
  CALL 0x2583
  CALL 0x2DD5
  LD   L,A
__endasm;
} //Basic_ATTR_fastcall

//----------------------- ATTR (y, x: TextCoords): UBYTE -----------------------
extern unsigned char Basic_ATTR_callee (unsigned char y, unsigned char x) __z88dk_callee;
extern unsigned char Basic_ATTR_fastcall (unsigned int yx) __z88dk_fastcall;
#ifndef ATTR_fastcall
#  define Basic_ATTR Basic_ATTR_callee
#else
#  define Basic_ATTR(y,x) Basic_ATTR_fastcall(((x)<<8) + (y))
#endif

If the token ATTR_fastcall is defined, two unsigned char arguments x, y are packed to one unsigned int, and calls Basic_ATTR_fastcall. It's efficient for constant arguments, but may has some calculations in run-time for non-consts - the inevitable overhead of this method. So the solutions is rather indirect. And I thought, maybe it is possible to expand the scope of the __z88dk_callee to pass at least two 1-byte arguments in registers.

P.S. Excellent developers have the to-do list is long always ;-)

[Smalovsky]

А у меня вопрос - можно ли использовать не поддерживаемые компиляторы си - хайтеч и иар? Разрешено ли их использование в коммерческих целях без лицензии ?

[s_kosorev]

только в играх без магии

[Oleg N. Cher]

Когда-то переписывался с IAR на тему использования их компилятора для Z80, мне предложили его купить, выслали демо-версию со сроком работы 1 мес. Про хайтек не в курсе. Но скорее всего он так и помер коммерческим продуктом, никто его безплатным не делал.

Чем SDCC не устраивает? Вкуснейший компилятор, особенно в свете фич __z88dk_fastcall, __z88dk_callee, __preserves_regs. Или z88dk?

[Sayman]

Вкуснейший компилятор, особенно в свете фич __z88dk_fastcall, __z88dk_callee, __preserves_regs. Или z88dk?

что там вкусного? баги двухлетней давности не могут устранить, а новые только плодятся. проекты собираются по 10 - 15 минут на 4х головой машине. от версии к версии один и тот же исходник перестают собираться и его каждый раз нужно править.
что-то не очень вкусно, знаете ли.

[Oleg N. Cher]

Чтобы устраняли баги - надо их активно репортить. Да, некоторые зависают, бывает. Но это издержки разработки. В отличие от багов, которые уже никогда не исправят в хайтек и иар Си, это, знаете ли, очень приемлемо.

Вопросы раздельной компиляции мы уже обсудили. Руки отрывать за монолитный исходник. Более того, в SDCC можно воспользоваться старым аллокатором регистров (его оставили) --oldralloc, он шустрее. Такая длительная компиляция, как я понимаю, она из-за поиска оптимального размещения в регистрах, реализована, видимо, перебором.

"От версии к версии перестаёт собираться и надо править" - а что ж вы хотели, не всегда есть смысл тащить совместимость с отмершими вещами. Например, убрали обязательный фрейм PUSH IX : LD IX, 0 : ADD IX, SP для каждой функции, так что же, плакать из-за этого? Да я лучше порадуюсь и код перепишу, эффективнее будет.

[Alcoholics Anonymous]

Когда-то переписывался с IAR на тему использования их компилятора для Z80, мне предложили его купить, выслали демо-версию со сроком работы 1 мес. Про хайтек не в курсе. Но скорее всего он так и помер коммерческим продуктом, никто его безплатным не делал.

Обращались ли вы IAR в последнее время? Они не упоминают свои Z80 инструменты на их веб-страницы больше.

Hitech был куплен Microchip которого первым делом должен был убить всех компиляторов Hitech, не связанные с ПОС. До этого было сделано, Hitech дал разрешение на использование и распространение компилятор C, который работает на CP / M (не версия DOS, которая работает под управлением MS-DOS).

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

Did you contact IAR recently? They don't mention their z80 tools on their webpage anymore.

Hitech was bought by Microchip whose first order of business was to kill all Hitech compilers not related to the PIC. Before that was done, Hitech gave permission to use and distribute the C compiler that runs on CP/M (not the DOS version that runs under MSDOS).

[свернуть]

что там вкусного? баги двухлетней давности не могут устранить, а новые только плодятся. проекты собираются по 10 - 15 минут на 4х головой машине. от версии к версии один и тот же исходник перестают собираться и его каждый раз нужно править.
что-то не очень вкусно, знаете ли.

Дайте z88dk попробовать. Мы ликвидировали множество ошибок в SDCC и получили доступ к библиотекам SDCC z88dk в, которые написаны в машинном коде и гораздо более полным. Она может быть нацелена спектра непосредственно без махинаций с КРТ и программ будет быстрее и меньше по сравнению с нативным SDCC. Вы можете собрать любое количество исходных файлов (ASM или С среди них) в одну линию прямо к водопроводной или двоичном.

Скорость компиляции является медленным, согласился, но вы можете уменьшить оптимизацию при разработке, чтобы ускорить или настроить Makefile только перекомпилировать файлы, которые изменились.

Я бы не использовать старую ralloc в SDCC - есть много ошибок в там.

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

Give z88dk a try. We've eliminated many of the bugs in sdcc and given sdcc access to z88dk's libraries, which are written in machine code and are much more complete. It can target the spectrum directly without fiddling with the crt and programs will be faster and smaller compared to native sdcc. You can compile any number of source files (asm or c among them) in one line straight to tap or binary.

The compilation speed is slow, agreed, but you can turn down the optimization while developing to speed things up or set up a makefile to only recompile files that have changed.

I wouldn't use the old ralloc in sdcc -- there are many bugs in there.

[свернуть]