About C / Z80 optimizations (SDCC)

Page 12/17
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | 17

By ARTRAG

Enlighted (6251)

ARTRAG's picture

14-09-2019, 10:21

Interesting info here

The latest CPM version if Hi-Tech C is v4.11, it is freeware with the permission of Microchip (this is why I link it here)
It seems quite a task to make it work. Anyone willing to try it ?
I stay with the v780pl2 version for ms-dos ;-)

Note: The files include the C sources of the COMPILER, not only of the libraries!

By zPasi

Champion (472)

zPasi's picture

14-09-2019, 14:09

ARTRAG wrote:

Note: The files include the C sources of the COMPILER, not only of the libraries!

Seems that ZC.C only is a frontend, didn't find source of the actual compiler.

The packed .HUF files are probably the runtime library sources.

By PingPong

Prophet (3449)

PingPong's picture

14-09-2019, 14:18

Quote:
Quote:

in the z80 scenario, a very good register allocator toghether with some form of O.R. is the heavy factor in generate better code.

There are not so many general purpose registers in Z80, so how much can that do?

It can do some things, better than the peephole optimization that it's called in this way because have a very limited context knowledge, it is not only a problem of register allocation instead of finding the best way to to a thing given a specific solution

By ARTRAG

Enlighted (6251)

ARTRAG's picture

14-09-2019, 15:11

zPasi wrote:
ARTRAG wrote:

Note: The files include the C sources of the COMPILER, not only of the libraries!

Seems that ZC.C only is a frontend, didn't find source of the actual compiler.

The packed .HUF files are probably the runtime library sources.

nope, gen is the compiler, not libraries
gen.huf should include sources for CGEN.EXE you find in diska and probably for the other compiler files
HUF sounds like a sort of Huffman compressed file.

By ARTRAG

Enlighted (6251)

ARTRAG's picture

14-09-2019, 15:19

In 2008 sdcc was less efficient than htc v780pl2, at least in struct and union manipulations and in the use of th stak for passing parameters
https://sourceforge.net/p/sdcc/mailman/message/19826657/

By PingPong

Prophet (3449)

PingPong's picture

14-09-2019, 16:19

ARTRAG wrote:

In 2008 sdcc was less efficient than htc v780pl2, at least in struct and union manipulations and in the use of th stak for passing parameters
https://sourceforge.net/p/sdcc/mailman/message/19826657/

A lot less efficient. But today what is the status?

By zPasi

Champion (472)

zPasi's picture

14-09-2019, 16:52

ARTRAG wrote:

In 2008 sdcc was less efficient than htc v780pl2, at least in struct and union manipulations and in the use of th stak for passing parameters
https://sourceforge.net/p/sdcc/mailman/message/19826657/

Struct operations still suck on SDCC, except when the structs are static, then it doesn't matter if a var is member of a struct or not.

Sometimes I've even done this kind of optimizations:

	static mystruct_t mystruct;
  // pmystruct is a pointer
	memcpy(& mystruct, pmystruct, sizeof(mystruct_t));
	x = mystruct.x; 
  // etc ...

Looks silly, but when accessing more than one member of a struct, performs better than mystruct->x.

And this is not easily peepholed.

Using stack for passing parameters is not much a problem. When I look at what Hi-Tech does, it passes max two 16 bit parameters by registers, the rest will go through the stack. Using __z88dk_fastcall SDCC passes one parameter by registers. So, only when there are two parameters, Hi-Tech performs better.

By ARTRAG

Enlighted (6251)

ARTRAG's picture

14-09-2019, 17:03

PingPong wrote:
ARTRAG wrote:

In 2008 sdcc was less efficient than htc v780pl2, at least in struct and union manipulations and in the use of th stak for passing parameters
https://sourceforge.net/p/sdcc/mailman/message/19826657/

A lot less efficient. But today what is the status?

Even if I expect significative improvements in 11 years, I cannot find any recent comparison

By zPasi

Champion (472)

zPasi's picture

14-09-2019, 17:34

ARTRAG wrote:

nope, gen is the compiler, not libraries
gen.huf should include sources for CGEN.EXE you find in diska and probably for the other compiler files

No, it's not the compiler.

There is a makefile and sources for zlibc.lib

By ARTRAG

Enlighted (6251)

ARTRAG's picture

14-09-2019, 18:48

How do you unpack HUF files ?

DEHUFF is in the package, it works in dosbox.
Yes you are right, the relevant sources of the compilers are missing.
All HUF files hold only libraries in ASM or C

Page 12/17
5 | 6 | 7 | 8 | 9 | 10 | 11 | | 13 | 14 | 15 | 16 | 17