About C / Z80 optimizations (SDCC)

Page 10/15
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15

By PingPong

Prophet (3413)

PingPong's picture

11-09-2019, 21:26

Compile both sources with both compilers then see what win. Do not only search some segments to advocate sdcc at aNY cost

By PingPong

Prophet (3413)

PingPong's picture

11-09-2019, 21:31

ARTRAG wrote:

Sorry, your example if very partial.
When the function parameters do not need to be stored, e.g. when they do not appear in repeated expressions the Hi-tech compiler is much faster that SDCC. Look at this other example, where parameters are stored in registers only:

   21   000B'                   _vrampeek:
   22                           ;CIRCLE.C: 19: asm("di");
   23                           	line	19
   19   000B' F3                di ;#
   20                           ;CIRCLE.C: 20: (*(port unsigned char *)(0x99) = 
                                (addr & 255));
   21                           	line	20
   22   000C' 7B                	ld	a,e
   23   000D' D3 99             	out	(099h),a
   24                           ;CIRCLE.C: 21: (*(port unsigned char *)(0x99) = 
                                ((addr >> 8) & 0x3f));
   25                           	line	21
   26   000F' 7A                	ld	a,d
   27   0010' E6 3F             	and	03Fh
   28   0012' D3 99             	out	(099h),a
   29                           ;CIRCLE.C: 22: asm("ei");
   30                           	line	22
   22   0014' FB                ei ;#
   23                           ;CIRCLE.C: 23: return (*(port unsigned char *)(0
                                x98));
   24                           	line	23
   25   0015' DB 98             	in	a,(098h)
   26   0017' 6F                	ld	l,a
   27   0018' C9                	ret

Hi-Tech C outperform sdcc pratically in all situations. Compile the same source and see
Someone told about Incorrect results from Hi-Tech C but I never seen this. Would be interesting to reproduce the bugs that lead to some results. Otherwise there is no match. Hi-Tech C is by far more performant than sdcc
The ability to use registers make also more performant even assembly routines because there is not need to setup the stack frame in the asm code

By PingPong

Prophet (3413)

PingPong's picture

11-09-2019, 21:37

Quote:

So, what is it doing here?

	ld	sp,ix
	pop	ix
	pop	hl
	pop	af
	pop	af
	jp	(hl)

I'm still not impressed.

please contextualize. is this code used to rebalance the stack?

Obviusly if the compiler uses registers it does not need ( should be i MUST NOT ) to generate rebalance code.
So if this code is to rebalance the stack, it does not use registers...

There cannot be code to rebalance the stack if using registers otherwise on exit the program crash...

By ARTRAG

Enlighted (6228)

ARTRAG's picture

11-09-2019, 22:15

DarkSchneider wrote:

In the case of ports SDCC uses something custom for doing that way. It has been posted above I think, but it is mentioned in manual in any case. It is defining variables in a special way. It also includes some interesting function definition. IMO it is worth to take a look at SDCC manual. Not sure completely as I have read it very fast, but looks like it mention that sometimes could use some memory locations to store local variables instead the stack unless using parameters to force the use of the stack.

If I hadn't used SDCC or Hi-Tech C and if I was unsure of what I was saying, I just had avoided adding noise to the discussion.

The fact is that Hi-Tech C has evolved from 1984 (first CPM version) to 2001 (last MS-DOS) version, to be abandoned about in the same year. It is the effort of a single private company, but it is the result of 18 years of development.
I cannot say if it is still generating the best code under all circumstances, but for sure no other current project has such a long history of improvements and evolution.

Anyway, as already I've said, while coding games, provided that the time critical sections have to go in ASM, to me the best compiler is the one that best fits in your development framework. That means e.g. that running dosbox of CPM each time you compile can be a pain in the XXX and a waste of precious time.

By zPasi

Champion (410)

zPasi's picture

11-09-2019, 22:34

PingPong wrote:

Compile both sources with both compilers then see what win.

I did and saw nothing.

Sometimes Hi-Tech shines and sometimes SDCC.

And frankly, I don't even care who wins. As long as I don't have MSX-libraries for Hi-Tech, it's useless for me.

By zPasi

Champion (410)

zPasi's picture

11-09-2019, 22:50

ARTRAG wrote:

The fact is that Hi-Tech C has evolved from 1984 (first CPM version) to 2001 (last MS-DOS) version, to be abandoned about in the same year. It is the effort of a single private company, but it is the result of 18 years of development.
I cannot say if it is still generating the best code under all circumstances, but for sure no other current project has such a long history of improvements and evolution.

Really? SDCC has been around since 1999, perhaps longer. 20+ years Smile

Quote:

Anyway, as already I've said, while coding games, provided that the time critical sections have to go in ASM, to me the best compiler is the one that best fits in your development framework.

That's right. Absolutely.

By ARTRAG

Enlighted (6228)

ARTRAG's picture

11-09-2019, 23:18

I agree about libraries, writing your own libraries is a very time consuming task and starting from something already tested can make the real difference. Often you end writing (and over-optimizing) libraries instead of coding what you was initially trying to do (it happens to me at least).

About the speed of the generated code, it cannot be the sole parameter to make the choice. Despite the fact that Hi-Tech C was more efficient than other compilers (at least till few years ago), it is a dead product, abandoned in 2001, so its destiny, sooner of later, is to be outperformed by a modern compiler (provided that the interest of its community of developers persists - and it is not assured in 2019 for a z80 compiler).
Probably, in the long term, it could be wiser to adopt a modern compiler with an active community of users and developers and to contribute to its evolution, suggesting improvements and helping fixing bugs, rather than to stay with a very good, but unsupported and dead compiler (I know, I've done this latter ;-)

BTW, googling around I've found a version of Hi-Tech C v780pl2 complete of manual and crack (no link here)
Wink

By DarkSchneider

Paladin (854)

DarkSchneider's picture

12-09-2019, 08:22

Agree with last comments. Critical sections need ASM for full use of CPU. But if someone have to use C because don't have time to learn Z80 ASM (could be mainly a compilers programmer profile) it's fine.

There is a repository of a korean guy full of HiTech libraries, but for the CPM one. Not sure if they could be used with the last one. Also, only binaries, and maybe not having the sources, I usually don't like much using things that don't know how are made, as maybe your program crashes because something in the libraries, and is hard to find the crash source.

And, I don't have problem to use DOSBOX or CPM emulator. I already tried the free HiTech for CPM with its emulator and is not really much trouble (you usually use cursors to repeat the commands). If I wanted and had time to create a full IDE for MSX development, integrating the compiler and assembler within a modern PC IDE, then yes having it native would be nice.

By ARTRAG

Enlighted (6228)

ARTRAG's picture

12-09-2019, 10:07

By PingPong

Prophet (3413)

PingPong's picture

12-09-2019, 10:44

zPasi wrote:
PingPong wrote:

Compile both sources with both compilers then see what win.

I did and saw nothing.
Sometimes Hi-Tech shines and sometimes SDCC.

You cannot say "i see nothing". If you compile both artrag sources and measure the time took to draw a circle you can have three different situations:
- Hitech C faster than SDCC
- SDCC faster than Hitech C
- They are equally faster (unlikely)

for the library SDCC have the library not by magic. It's because someone created this. the same could be done for hitech-c and probably will result in faster/smaller code. the convertion is not so dramatic.
i will prepare some benchmarks to see what is the overall result.
Obviously there may be some situation where one compiler perform better than other but they cannot be considered a rule. To determine what is doing best what is count is the overall result.

Page 10/15
3 | 4 | 5 | 6 | 7 | 8 | 9 | | 11 | 12 | 13 | 14 | 15