[z88dk-dev] Creating a better compiler for the Z80

Bridge to the z88dk-developers mailing list
Philipp Klaus Krause

[z88dk-dev] Creating a better compiler for the Z80

Post by Philipp Klaus Krause »

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear z88dk developers,

for years I have been reading this list, and I have taken a quick look
at your website, wiki and forum.

It seems the strengths of z88dk are mostly the following:

* Support for lots of systems
* Peephole optimizer

On the other hand z88dk seems to lack in the compiler stages that come
before the peephole optimizer. Some constructs of standard C are not
supported, optimization could be better, etc.
In the forums in noticed comments such as the following: "A new compiler
is needed, it's just a question of time which".
However creating a new compiler for the Z80 would be a lot of work and
there already is another free C compiler trageting the Z80: sdcc.

sdcc currently generates code which in general is smaller and faster
than the one generated by z88dk (see the table at
http://sourceforge.net/apps/trac/sdcc/wiki/Philipp%27s%20TODO%20list for
a comparison of Z80 compiler code sizes). It does support a more
complete subset of stadard C compared to z88dk. It is actively
maintained (releases about once a year) and keeps improving.
While the peepholes have been improved a lot over the years they
probably are not as good as z88dk's yet. There is practically no support
for various z80-bases systems: sdcc just offers a way to tell where code
and variables should go in memory space, and the option specify the use
of custom startup code.

To me it seems that the strengths and weeknesses of sdcc and z88dk
complement each other. Combining efforts could eliminate the weaknesses
and combine the strengths.

What's your opinion on this?

Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyTtbQACgkQbtUV+xsoLprl1QCgye34OzRqSHTrdUvrGlasLaA+
uPUAn2U01xHSsqB1CPpo63Y3t9n20x1X
=UtuV
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

Hi Philipp,

for years I have been reading this list, and I have taken a quick look
at your website, wiki and forum.

It seems the strengths of z88dk are mostly the following:

* Support for lots of systems
* Peephole optimizer

Indeed, the system support is the main feature of z88dk, just this week
Stefano has added Einstein support. The other thing is depth, some
platforms (i.e. ZX/z88) have very extensive libraries.

On the other hand z88dk seems to lack in the compiler stages that come
before the peephole optimizer. Some constructs of standard C are not
supported, optimization could be better, etc.
In the forums in noticed comments such as the following: "A new compiler
is needed, it's just a question of time which".
However creating a new compiler for the Z80 would be a lot of work and
there already is another free C compiler trageting the Z80: sdcc.

I'm not sure there is any optimisation in the compiler :)

Time is the killer, and I'm not convinced that I'll ever have enough
time to do it.

To me it seems that the strengths and weeknesses of sdcc and z88dk
complement each other. Combining efforts could eliminate the weaknesses
and combine the strengths.

What's your opinion on this?

I've no attachment to the compiler (my hacks taught me how not to write C
but that's about all I can say about it), so I'm amenable to switching in
sdcc or indeed to any other compiler.

The last time I looked at sdcc I couldn't actually compile it, though I've
just downloaded a snapshot and it did compile.

There's a few questions that need to be considered though:

Framepointer:

Is it possible to turn off the framepointer? Having sp relative addressing
would ensure more compatibility and make Rabbit life easier.

Calling convention:

sdcc as I understand it calls in the more standard right->left rather than
sccz80's left->right - can it emit code in the reverse order - possibly on
a per function basis?

Register passing convention sccz80 passes everything on the stack - what
does sdcc use?

Return value conventions for the different types?

Fastcall and callee stack clear up?

Floating point:

z88dk tends to use the native systems FP package (which are mostly written
in the same way) which aren't held in registers, whereas I believe sdcc
uses ieee754 using 2 register pairs. Using the native system tends to save
a lot of memory - how easy is to adjust the behaviour of sdcc?

Extensions:

z88dk supports far pointers, can this be done with sdcc?

Carry flag, z88dk supports the non-standard return_c, return_nc and
iferror which allows easy grafting of assembler code, can this be
supported with sdcc?

Integration with assembler:

Does sdcc handle the initialisation of C global variables using assembler?

Can you define a static prototype in C and then implement in assembler?

Assembler:

We've got a lot of assembler code, can the asz80 derivative in sdcc have a
different syntax module bolted on to understand z80asm/extended to have a
more natural syntax?

Or alternatively can sdcc be easily coaxed to output z80asm?

Linker:

Same as above really.

Hacks:

z88dk supports a bunch of pragma commands to tune to the crt0 code for
size, features etc - how would this be achieved with sdcc?

Licensing:

....

I think there is possibility for improving both projects, so I'm
interested in your answers.

Regards,

dom


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Philipp Klaus Krause

Post by Philipp Klaus Krause »

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.09.2010 22:40, schrieb Dom Morris:

What's your opinion on this?

I've no attachment to the compiler (my hacks taught me how not to write
C but that's about all I can say about it), so I'm amenable to switching
in sdcc or indeed to any other compiler.

The last time I looked at sdcc I couldn't actually compile it, though
I've just downloaded a snapshot and it did compile.

There's a few questions that need to be considered though:

Framepointer:

Is it possible to turn off the framepointer? Having sp relative
addressing would ensure more compatibility and make Rabbit life easier.

Currently not. However it shouldn't be a lot of work to implement: We
already use sp relative addressing for variables we cannot reach via the
framepointer (i.e. when we have lots of local variables).
The only z80 variants currently supported are the Z80 istslef and the
gbz80 as used in the Gameboy (and gbz80 support is currently
unmaintained). We have an open feature request for supporting the Rabbit.

Calling convention:

sdcc as I understand it calls in the more standard right->left rather
than sccz80's left->right - can it emit code in the reverse order -
possibly on a per function basis?

No, but implementing it shouldn't be difficult either.

Register passing convention sccz80 passes everything on the stack - what
does sdcc use?

Passing everything on the stack is the default. Support for passing
arguments in registers is not complete.

Return value conventions for the different types?

8-bit values: l
16-bit values: hl
32-bit values: dehl

Unfortunately sdcc does not yet support larger return types.

Fastcall and callee stack clear up?

We currently do not have z88dk's __FASTCALL__. Shouldn't be too much
work to add it though.
I looked into passing parameters in registers some time ago, but gave
up, when I found that the C standard does not allow to change calling
convention based on the use of the register keyword in the function
prototype.

In sdcc the stack is always cleared up by the caller (except for iy).

Floating point:

z88dk tends to use the native systems FP package (which are mostly
written in the same way) which aren't held in registers,
whereas I
believe sdcc uses ieee754 using 2 register pairs.

It does use ieee754 32 bit floats. It's up to the register allocator to
place them in register pairs or memory.


Using the native
system tends to save a lot of memory - how easy is to adjust the
behaviour of sdcc?

How do these native systems work? I mostly target the ColecoVision,
where there is no such system (and to save speed and memory I usually
use my own fixed-point math library instead of float).

Extensions:

z88dk supports far pointers, can this be done with sdcc?

The z80 port of sdcc currently does not support far pointers, however
other ports, e.g. mcs51, do.

Carry flag, z88dk supports the non-standard return_c, return_nc and
iferror which allows easy grafting of assembler code, can this be
supported with sdcc?

Integration with assembler:

Does sdcc handle the initialisation of C global variables using assembler?

I'm not sure I get what you mean (English is not my native language).
Sure you can access any global C variable from asm code and thus
initialize them, e.g. in assembler code in your custom crt0.

Can you define a static prototype in C and then implement in assembler?

Yes.

Assembler:

We've got a lot of assembler code, can the asz80 derivative in sdcc have
a different syntax module bolted on to understand z80asm/extended to
have a more natural syntax?

Or alternatively can sdcc be easily coaxed to output z80asm?

The z80 port has a mechanism for outputting different asm formats,
including z80asm, but I never touched it or tried it. It's not unlikely
that it will need a bit of work.
The current plan is to sync the asz80 in sdcc with upstream 5.0. Borut
is working on it.
However improving support for other output formats IMO would be a
sensible thing to do, too.

Linker:

Same as above really.

Unfortunately I don't know about the linker, I never touched the code.
Borut working on syncing it with upstream 5.0.

Hacks:

z88dk supports a bunch of pragma commands to tune to the crt0 code for
size, features etc - how would this be achieved with sdcc?

Could you elaborate on these, what they do and how they work?
http://www.z88dk.org/wiki/doku.php?id=usage:pragmas is not very verbose.

Licensing:

sdcc itself is licensed under GPL. The libraries are currently being
converted to GPL+LE (which allows linking with non-free programs). The
conversion will be mostly complete for the upcoming 3.0.0 release. There
are still a few library files that are under other licenses, such as GPL
and LGPL, but AFAIK they only affect the mcs51 and pic16 ports. All
libraries relevant to the Z80 port have already been placed under GPL+LE.

I think there is possibility for improving both projects, so I'm
interested in your answers.

Well, sdcc has, among other features, support for bitfields (very useful
for saving RAM), protoyping function pointers, inline functions. I
believe z88dk could benefit from these.

Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyT5jkACgkQbtUV+xsoLpoPeACgq8ryNKA8jfnQplv1sAEExXBL
3sQAoOeSH+/JxUOI41Ebye19MwQqugIP
=qPjn
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Philipp Klaus Krause

Post by Philipp Klaus Krause »

Am 17.09.2010 22:40, schrieb Dom Morris:

Carry flag, z88dk supports the non-standard return_c, return_nc and
iferror which allows easy grafting of assembler code, can this be
supported with sdcc?

Hmm, to me these look like ugly hacks I wouldn't want to use; but they
could be implemented as preprocessor macros, that expand into inline asm
code.

Philipp

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

On Sat, 18 Sep 2010, Philipp Klaus Krause wrote:

Currently not. However it shouldn't be a lot of work to implement: We
already use sp relative addressing for variables we cannot reach via the
framepointer (i.e. when we have lots of local variables).
The only z80 variants currently supported are the Z80 istslef and the
gbz80 as used in the Gameboy (and gbz80 support is currently
unmaintained). We have an open feature request for supporting the Rabbit.

I've been playing around and see that iy is used when the frame is large
which is not viable for a lot of z88dk targets. Usually one of them can be
used, but not both.

sdcc as I understand it calls in the more standard right->left rather
than sccz80's left->right - can it emit code in the reverse order -
possibly on a per function basis?

No, but implementing it shouldn't be difficult either.

This would purely be for compatibility purposes, without it there's a
large amount of work rewriting assembler.

In sdcc the stack is always cleared up by the caller (except for iy).

It's not a big thing, but it's something that we've found can reduce
memory usage when not running with a frame pointer (where you can just do
ld sp,ix rather than a manual stack adjust)

Using the native
system tends to save a lot of memory - how easy is to adjust the
behaviour of sdcc?

How do these native systems work? I mostly target the ColecoVision,
where there is no such system (and to save speed and memory I usually
use my own fixed-point math library instead of float).

We use a fixed 6 byte buffer for FP variables - this covers pretty much
all the native formats which are either 4,5,6 bytes long. There's a
portion of memory set aside for the FP accumulator. Math operations are
performed by loading the FA space and passing the second float on the
stack.

For conversion to native format either the compiler conversion or the
native FP package can be used - it depends on the format. If native
conversion is used then it happens at runtime.

The z80 port of sdcc currently does not support far pointers, however
other ports, e.g. mcs51, do.

That can come later - only the z88 actually uses them.

The z80 port has a mechanism for outputting different asm formats,
including z80asm, but I never touched it or tried it. It's not unlikely
that it will need a bit of work.
The current plan is to sync the asz80 in sdcc with upstream 5.0. Borut
is working on it.
However improving support for other output formats IMO would be a
sensible thing to do, too.

Ah, yes I spotted that, the output looks okish and doesn't look that
broken.

Could you elaborate on these, what they do and how they work?
http://www.z88dk.org/wiki/doku.php?id=usage:pragmas is not very verbose.

Yup, that page is just the mechanism, each platform may have individual
tweaks, examples:

- defining the stack pointer
- defining the org
- indicating which version of printf to include
- indicating whether to include dos stubs and which version
- indicating whether fp support is needed
- indicating which sort of build to make (Application, rom etc)
- indicating whether stdio is needed
- indicating whether sound report is needed
- indicating memory setup for z88 applications
- indicating whether we need to include far pointer mapping
- setting the application name/icon
etc

A lot of these could be passed on the command line, but that could make
for a frustrating user experience.

return_nc etc

Hmm, to me these look like ugly hacks I wouldn't want to use; but they
could be implemented as preprocessor macros, that expand into inline asm
code.

You're entitled to your opinion of course, but twiddling the carry flag is
very common paradigm for z80 firmwares to indicate errors, being able to
do this directly can be very useful, though it's not often used.

I see that we can take the following steps to get this moving:

1. sccz80 can be swapped out for a call to sdcc in the zcc driver
2. The platform stubs (mul, div etc) can be sorted out
3. Fixing up of sdcc's z80asm output format (I think it kicks out a .opt
line)

That leaves in a state where we should be able to link an executable and
have it work on (most) platforms but any calls to z88dk asm lib functions
with more than one parameter will fail.

4. sdcc needs to be able to pass parameters in reverse order to get
support of the z88dk libs (with a holding number of args for va_args
funcs)

We're now in a state where you can compile code and have it working across
most platforms calling z88dk library funcs.

5. Option in sdcc not to use ix and iy.

This now gets us working on all platforms.

6. Applying some of z88dk's peephole rules to sdcc

Some may not be relevant others will be.

7. Sorting out the tweaks - there's a few extra function decorators about
the place that come in useful when writing shared libraries etc.

8. Far pointer handling.

I'm happy to tackle 1-3 if you can look into 4.

cheers,

dom



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
Philipp Klaus Krause

Post by Philipp Klaus Krause »

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 18.09.2010 21:09, schrieb Dom Morris:
[...]

I see that we can take the following steps to get this moving:

1. sccz80 can be swapped out for a call to sdcc in the zcc driver
2. The platform stubs (mul, div etc) can be sorted out
3. Fixing up of sdcc's z80asm output format (I think it kicks out a .opt
line)

That leaves in a state where we should be able to link an executable and
have it work on (most) platforms but any calls to z88dk asm lib
functions with more than one parameter will fail.

4. sdcc needs to be able to pass parameters in reverse order to get
support of the z88dk libs (with a holding number of args for va_args funcs)

We're now in a state where you can compile code and have it working
across most platforms calling z88dk library funcs.

5. Option in sdcc not to use ix and iy.

This now gets us working on all platforms.

[...]

I'll look into 4 and 5 after the sdcc 3.0.0 release, which is scheduled
for mid to late october.

Philipp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyVNtkACgkQbtUV+xsoLpoOxwCdGk0hjRBSYnFUEpwE4ViFUMpI
0J4AoN7X2IHlu3ybqcaNeDeqV39EYUwD
=irEr
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

On Sun, 19 Sep 2010, Philipp Klaus Krause wrote:

[...]

I'll look into 4 and 5 after the sdcc 3.0.0 release, which is scheduled
for mid to late october.

That's cool, I've got enigma.c up and running on the CPM target though the
results are wrong because the GSINIT code isn't being called (I'm guessing
there's an option I haven't found that initialises variables inline as it
were and does away with the GSINIT code).

regards,

d.

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Guys,
this sounds challenging, I like it, I'm with you !



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Hello, I could build SDCC with cygwin with no hassle (but the time to configure and compile).
A first impression, the syntax checking seems to me a bit restrictive, and I have to work on the sources to make the compiler like them, but it looks very powerful (i.e. I like the options to declare the I/O port addressing as if it is memory space and so)..

I still couldn't get to the same result as Dominic (which damn is the right command line ??) but I will.

In the meantime I'm thinking at a trick for the parameter passing problems: to just add a call to a 'stack reverser' for all the functions with more than one parameter).
It won't work for long types but I drop it here as an idea ..

Code: Select all

stub:
ld a,parms_number
ld hl,func_addr
jp _invert_stack

func:
; original function
..


sv_inv_param: defb 0

_invert_stack:
ld (sv_inv_param),a
ld (sv_func_addr+1),hl
call  ; code to reverse data in stack
sv_func_addr:
call  0  ; SMC is just an idea..
ld a,(sv_inv_param)
jp  ; code to reverse data in stack

; code to reverse data in stack
;... here A holds the number of parameters, and the stack is ready at SP
..

The same trick could help importing alien code, i.e. to link functions coming from old CP/M environment (REL libraries, etc..).



------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

Hello, I could build SDCC with cygwin with no hassle (but the time to configure and compile).
A first impression, the syntax checking seems to me a bit restrictive, and I have to work on the sources to make the compiler like them, but it looks very powerful (i.e. I like the options to declare the I/O port addressing as if it is memory space and so)..

Yup it's very strict - all prototypes need to be defined correctly (eg () is effectively treated as (void)) which is a bit painful with old K&R style sources. adv_a was the first thing I tried and the errors were a tad cryptic due to the line numbers being off.

I still couldn't get to the same result as Dominic (which damn is the right command line ??) but I will.

The magic should be zcc +cpm -compiler=sdcc enigma.c, if it doesn't work I've probably forgotten to check something in.

The diffs for enigma.c were to work around the argument order issue by switching to single parameter calls:

Code: Select all

RCS file: /cvsroot/z88dk/z88dk/examples/console/enigma.c,v
retrieving revision 1.3
diff -r1.3 enigma.c
32c32
< #define ARGC
---
> //#define ARGC
50c50
<       puts("Usage: enigma [text to be encoded]");
---
>       puts_cons("Usage: enigma [text to be encoded]");
57c57
<     puts("Enter text to be (de)coded, finish with a .");
---
>     puts_cons("Enter text to be (de)coded, finish with a .");
65c65,66
<       ch = getchar();
---
>       ch = getkey();
>         fputc_cons(ch);
66a68
>         fputc_cons(ch);
170c172
<       putchar(ch);
---
>       fputc_cons(ch);
173c175
<               putchar('\n');
---
>               fputc_cons('\n');
175c177
<               putchar(' ');

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

The magic should be zcc +cpm -compiler=sdcc enigma.c, if it doesn't work I've probably forgotten to check something in.

Seems to work (great job, Dom !!!), just it was unstable before I added 1 byte to the 'mustmalloc' call in zcc at line 325/326 ;)

Code: Select all

        buffer = mustmalloc(strlen(processor) + strlen(extraargs)
+ strlen(filelist[number]) + strlen(outname) + 9);

Now I'm at sdcc (current latest devel version 2.9.7 #5988) complaining for the extern __LIB__ declarations:

/cygdrive/c/PROGRA~1/z88dk/include/cpm.h:94: syntax error: token -> 'bdos' ; column 23


The diffs for enigma.c were to work around the argument order issue by switching to single parameter calls:
(...)

ok, I'll experiment a bit but help is welcome in any case :)


I like this approach, at the moment it keeps both the sccz80 and sdcc ways open, making also possible to mix them. It adds flexibility with possibly no side effect.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

Now I'm at sdcc (current latest devel version 2.9.7 #5988) complaining for the extern __LIB__ declarations:

sys/compiler.h should work these out - you may not have updated the include folder.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

sys/compiler.h should work these out - you may not have updated the include folder.

You're right as usual, sorry I thought I copied that tree :/
The trick, in my opinion, is pure genius.


Now I just passed the pain of getting CygWin safe from itself (with the latest version some rules are changing again,,)

The current developement version of sdcc is pushing in the asm source an annoying ".optsdcc" directive, driven by a Z80_LIKE option, which I just removed in the dirty way :P

And.. wow, now the build process, with a lot of strange messages.. gets to the end !

world.c is much smaller but crashes, time to patch enigma.c !



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

lf (with the latest version some rules are changing again,,)

The current developement version of sdcc is pushing in the asm source an annoying ".optsdcc" directive, driven by a Z80_LIKE option, which I just removed in the dirty way :P

Yeah, I just removed that line from my sdcc tree.

And.. wow, now the build process, with a lot of strange messages.. gets to the end !

world.c is much smaller but crashes, time to patch enigma.c !

Yup, *printf is probably the prime candidate for the functions least likely to work! It's only much smaller because stdio isn't being dragged in - the vprintf core is being linked in at all - I've yet to add "command line pragmas" to zcc to get stuff being pulled in correctly.

You might be able to rebuild the .c part of the library to run well with sdcc - there's an extra flag passed through to the assembler with -make-lib to sort out the XLIB/MODULE differences.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

lf (with the latest version some rules are changing again,,)

The current developement version of sdcc is pushing in the asm source an annoying ".optsdcc" >directive, driven by a Z80_LIKE option, which I just removed in the dirty way :P

Yeah, I just removed that line from my sdcc tree.

For the record, here is my 'fix' in SDCCglue.c:

Code: Select all

//  else if (TARGET_Z80_LIKE || TARGET_IS_HC08)
else if (TARGET_IS_HC08)
{
fprintf (asmFile, "\t.optsdcc -m%s\n", port->target);
}

Yup, *printf is probably the prime candidate for the functions least likely to work! It's only much smaller because stdio isn't being dragged in ...

Yes, but changing the source and dumping a list of fputc_cons calls, one for every char works in both the cases.. with the difference of reducing the binary size of the COM program from 1.270 bytes with SCCZ80 to 764 bytes when I add the '-compiler=sdcc' option, still perfectly working, including the MS/DOS protection stub !!!

In this case nothing is left to do for our peephole optimizer:

Code: Select all

._main_start
._main
;world.c:12: fputc_cons('H');
ld        a,$48
push        af
inc        sp
call        _fputc_cons
inc        sp

Not bad, really !

To build 'enigma.c' is being a bit more difficult, it looks I miss __MODUINT_RRX_S, needed to promote a char variable to integer..

Code: Select all

enigma.c:76: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int
enigma.c:83: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int
enigma.c:86: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int
enigma.c:94: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int

You might be able to rebuild the .c part of the library to run well with sdcc - there's an extra flag passed through to the assembler with -make-lib to sort out the XLIB/MODULE differences.

I will, possibly it solves the problem above.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

In this case nothing is left to do for our peephole optimizer:

Code: Select all

._main_start
._main
;world.c:12: fputc_cons('H');
ld        a,$48
push        af
inc        sp
call        _fputc_cons
inc        sp


Hopefully that stack adjustment is just a one-off for a single parameter, if not we could have some fun with the asm code.

To build 'enigma.c' is being a bit more difficult, it looks I miss __MODUINT_RRX_S, needed to promote a char variable to integer..

They're there. Just not enabled! Add @sdcc.lst to the crt0list and rebuild the crt0 library and they'll be pulled in. We need to review the routines and see if we can reduce duplication.

You may need to rebuild z80asm since there was a 64bit bug with non XLIB imports.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I just spent a few hours reading the sdcc manual and asz80 documentation.

I am not sure if the linker, as is, is up to doing what we might want done regarding compiling larger than 64k programs into user definable memory configurations but more on that below.

sdcc is certainly much better at the standards compliance and optimization of intermediate code but I think there may still be some work involved at the back end code generation and the linker/asm level as I already mentioned. But I don't disagree sdcc is much much closer to where we might want to go in both regards.

Some things I think can be improved:

* The back end is reserving registers for specific roles in code generation. IX is assigned frame pointer, BC/DE hold variables, DE and IY are temps. Doing this has already crippled the quality of code output by the compiler. Z80 code written by experts very rarely uses a frame pointer and perform register allocations that minimize code size or maximize speed as affected by the non-orthogonal instruction set and task at hand (personally I think the libraries should be hand coded for speed and the compiler should be going for code size). I think the back end should be focussed on generating best code for the most deeply nested basic blocks and working out from there so that any shuffling of variables from stack to registers occur at least frequency possible. Just as a human programmer would consider, the compiler could choose to make copies of variables deep in the stack frame and have them sit near the top of the stack for quick access within deeper nested basic blocks!
that
use them. It should also not shy away from using the EXX set or splitting the IX.IY registers into their 8-bit components IXH,IXL,IYH,IYL. Although not officially documented in the z80 family, these instructions have always been there, have always been intended to be there by Zilog (they are officially documented in z80-compatible successors), and have not been found not to work on real hw to my knowledge. But the back end also needs to be configurable to not use certain registers in code generation. This has to do with several z80 target architectures reserving some registers for other uses. Eg, the zx81 uses IY to generate the video display and some systems may reserve some EXX set registers for their operating system.

* Another reason I don't like the reservation of registers is that it hurts the usability of the libraries. I believe as much of the libraries in the C compiler should be handcoded in assembler as possible. This is to reduce code size, increase resulting speed and to encourage assembler programmers to at least consider using the libraries in their own projects. For library functions at least (or functions the compiler can't peek into), I think the back end should follow a caller-save model where a code segment calling to a library should save what it needs to save before calling. The libraries should not have to worry about what registers may not be safe to modify. This will strip any unnecessary prologue and epligoue code from the libraries which not only makes them faster but also more attractive to asm programmers. I will make one note here while it is on my mind: one z80 idiom is the use of an index register as function pointer (because of the jp(ix) instruction).!
As
mentioned above, some z80 targets reserve the index registers, especially, for other uses. We have found that you can get away with using one index register pair but not necessarily both. So the libraries have been written to use IX and the assembler has a switch to swap the use of IX/IY in the binary output. This way if a target reserves IX but allows use of IY, the same library source code can be used with the swap IX/IY flag in the assembler.

* Addition of CALLER and FASTCALL linkage for functions will significantly contribute to code size reduction and library routine usability. In the former the caller pushes parameters onto the stack but the subroutine is responsible for cleaning up the stack. In the latter parameters are passed in registers rather than through the stack. To simplify matters z88dk only supports a single parameter in FASTCALL linkage. An assembler-friendly implementation of va_args (etc) needs to be available as well. In the sdcc C lib src it looks like a static variable is being initialized with information to support variable arguments? It is not necessary to restrict function reentrancy like that on the z80 and I would prefer some means for this information to be made available by the compiler in registers on entry to a subroutine. z88dk intiializes A with the number of arguments passed, which is available only at the beginning of a variable argument function. This may be a problem f!
or
va_arg stuff in C functions (as it means va_start needs to be called first thing on entering a function) so maybe something else can be figured out.

* The compiler should not be generating a full stack frame for compiler primitives. Eg, the 16 bit multiply code is treated as any subroutine call and gets a full-fledged stack frame generated for it. It will greatly speed up programs and reduce code size if these compiler primitives are rewritten to accept all parameters in registers and all return values in registers. The compiler then generates code to place parameters in the relevant registers and the compiler primitive is called without generation of any stack frame. It also turns out the fastest code for adding, multiplying, etc 32-bit longs uses an index register. The reservation of IX by the compiler for frame pointer would mean we couldn't make use of that code for longs and this is something that could as much as double execution time.

* It would be nice if the assembler supported standard zilog mnemonics. For example "ld a,(ix+2)" in addition to "ld a,2(ix)". I also think the undocumented instructions should be added so that assembly priogrammers can use them if they choose to. I do not use many of them but I do use the IXH,IXL,IYH,IYL 8-bit registers quite frequently.


One thing I need to ask is is it going to be a problem if the z80 port diverges significantly from the rest of sdcc? What I mean is z88dk has hundreds of library routines coded in assembler that will not be available on other ports. stdio.h, stdlib.h, etc will see many new routines that the other ports will not support. It would almost make sense for the z80 port (and perhaps other ports) to have its own include, lib abd libsrc directory structure. Some of these additions are not in the C standard. I support the idea of following the standard but do think the standard needs to bend to the target not the other way around. I saw the distinction --stdc99 and --stdsdcc99 in compile time flags so maybe one of these things defines a macro that can be used to selectively ifdef out non-standard compliant additions to stdio, etc?

I do think if a merger of the two projects is to happen, it is an opportunity to finally reorganize the libraries and come up with a vision for future development. z88dk has grown a lot over the years and the growth has manifested into a kind of spaghettiness in the directory structure, the list of pragmas, coding styles, the variations in startup code with -startup, etc. So this may be the time when the slate can be wiped and we can rebuild in a clean room.


Concerning the linker:

What we need is not yet clear to me but the idea is this. We want the compiler to be able to generate code for systems with >64k memory in bankswitched configurations. These configurations vary in flexibility. For example some may divide the 64k area into pages, any page can be occupied by any memory bank from a pool. That is maximum flexibility. Other systems might be more limited only allowing one section of memory to be occupied from a pool of memory banks. The compiler or linker will also need to determine or be told when and where library code needs to be duplicated. Some configurations may be limited to such an extent that it is impossible to have all library code reachable in a single memory bank that can be active all the time. In this case there will have to be more than one copy of library routines in the project.

A near and far memory model will need to be introduced at some point. Each function in, eg, string.h will need both near and far implementations. Selection of the near model will #define the standard names to the near versions of functions. This will allow the far versions to still be available through augmented names and vice versa. Near pointers would be 16 bit and far at least 24 bit (z88dk uses 24-bit in ehl).

I am going to stop there as it is getting late but I am not sure yet whether the existing area directives in the linker can support the kind of things I think we will need in future. I'll try to nail down exactly what I think we will need and maybe see if asz80's existing area stuff can do it.



------------------------------------------------------------------------------
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security
easier or more difficult to achieve? Read this whitepaper to separate the
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Alvin,
I share most of your view, expecially the first part, concerning on the optimization and I appreciate very much the precision of the analisys.
Also remarking the goals we gave to ourselves onto finding a way to make the code/data splitting into memory pages is important, even if my feeling about this is that it will still take long time.

By the way I think the approach Dominic permits us to postpone many questions: the z80asm linker/assembler is still the same because SDCC is invoked in such a way to generate compatible code, and the compiler itself can be transparently substituted.
I think z88dk and sdcc at the moment can still live their own life but permitting a first light integration.

I succesfully experimented a quick'n' dirty way to get to the end of the compilation with no need to touch the current sdcc code, based onto the optimizer rules ;)

Code: Select all

        push        hl
call        __moduint_rrx_s
pop        af
pop        af
=
push        hl
LIB        __moduint_rrx_s
call        __moduint_rrx_s
pop        af
pop        af

Got the idea ?
This could also temporairly fix the ".optsdcc" output bug ..


About my current experiments, I'm stuck with a not working program, enigma.c runs but its decrypted output is crippled or inconstant.
It doesn't seem to have to do with the ix/iy registers (in any case Alvin guessed rightly telling the index registers are a big point), perhaps the developement version I'm trying is not good ?

BTW it is so funny to try compiling in this way:

Code: Select all

zcc +zx -compiler=sdcc -Cz--fomit-frame-pointer -notemp -create-app enigma.c

last question: what are these ?

Code: Select all

z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node
z80instructionSize() failed to parse line node
...

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Yes !
following the Dom's suggestions (that for some odd reason haven't been replicated on the board) I could apply those fixes necessary to make enigma run an a Spectrum.
It runs ! ..but with hand-adjustment.

I try to recap all I've done.
- as Dom suggested I changed the I/O calls to puts_cons() and getk()
- Changed the 'flag' paramenter in the enigma program to 'unsigned char' type (to make it easier to fix the IY problem
- Did a first compilation with -notemp flag (and, obviously -compiler=sdcc) and edited enigma.opt as follows
- commented out '.optsdcc -mz80'
- added the LIB inclusion for the *_rsx* lib imported by Dom (I think I could invoke a native one, I'll try it)
- moved 'main' entry before the gsinit code
- got rid of iy, adjusting the code to use the accumulator and directly pointing to (_flag) instead
- hand-completed the build process

The resulting program is abt 500 bytes bigger than sccz80, but perhaps it is due to initialization.
At least we already have a great opportunity to try rebuilding the C portion of our libraries and see it there is some space we can save ;)

So before thinking at the way to manage the parameter passing I'd first think at leaving iy alone and fixing the few z80asm export limits.



------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

The va_args comment you can ignore... the right to left pushing of parameters solves that problem as far as the printf, scanf family is concerned :-)

Besides the optimizations sdcc can perform at the intermediate level the one thing I would like to see change the soonest is to incorporate multiple code sections, at minimum a text segment, an uninitialized data segment and an initialized data segment (maybe called CODE, SPACE, DATA). The uninitialized segment can be set to zero by an ldir in the crt0 and the initialized segment could be either part of the image (as in z88dk) or created at runtime (as in sdcc, and this is the more C standard-compliant route). Although I would get away from a ld(NN),a initialization and look at a decompression at runtime instead and perhaps leave the option to use image as a command line switch.

This would solve some of the hackery in the libraries and solve the ROM/RAM separation issue. I believe the libraries can be written to use just those three segments and they would still be future proof for the long term goal of compiling for a bankswitched target. We could even add in commented out and unimplemented directives indicating a register input list, register output list and a register kill list that some fictional future compiler, assembler or code improver could read to generate better code. I would be willing to do this, cleaning up existing standard library code to begin with, cleaning up the includes and making sure that it is complete and standard compliant (eg qsort, etc) but we would have to commit to an assembler with sections in the short term.

Also recent comments in the sdcc developer thread indicate they would like to keep sdcc as a strictly C-standard compliant compiler and would prefer to keep everything else out as an SDK or 3rd party library add-on. This would mean much of the platform specific code we have (graphics library, sprite libraries, probably native math libraries, and maybe crts for specific targets) would have to exist outside of sdcc in a separate project. I understand the motive for this and it makes sense but it is something to keep in mind.



------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
Philipp Klaus Krause

Post by Philipp Klaus Krause »

Am 06.10.2010 19:10, schrieb Dom Morris:
last question: what are these ?

[code]z80instructionSize() failed to parse line node

I think those are due to the peephole in sdcc operating on assembler
output and the rules being tailored to the asXXXX format.

Yes. This is another problem that will need to be solved. The
versatility of the peephole optimizer is one of sdcc's strengths.
Unfortunately currently a large part of it only works with asXXXX output.
Maybe automatically translate the peephole rules for the different
assemblers, e.g. using some sed script?

Philipp

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Yes. This is another problem that will need to be solved. The
versatility of the peephole optimizer is one of sdcc's strengths.
Unfortunately currently a large part of it only works with asXXXX output.
Maybe automatically translate the peephole rules for the different
assemblers, e.g. using some sed script?

I'm trying to get an overall view of the compiler source, it is very well
structured and full of suggestions for new ideas in any corner.
On the the optimization side there are various ideas coming up, I try to
drop down some:
- that fast way to do some calculation (i.e. sequences of add a,/rla for
multiplications) could generate the same instructions list in several
portions of the resulting program. It could be 'extracted', put somewhere
a single time and 'called', but probably this requires a new optimizing
engine.
- With z88dk we're getting two peephole optimizers, a quick and dirty way
could be to convert the sdcc rules into z88dk and invoke them only when the
"-compiler=sdcc" option is used.
- Managing the arithmentic differently for char and int types is worth for
speed only, a single sub call could save a lot of space.
- _FASTCALL_ and _CALLEE_, please :P
- (this is for z88dk too).. what about a sort of FASTCALL way to pass two
parameters ?
- ?? I'm missing one, just can't remember now, I'll post it when I'll find
it :)

By the way that long list of "z80instructionSize()" can be hidden avoiding
to display the warning when a zero length instruction name is found.

I'm trying to find a way to preserve IY, and I'm very curious on the reason
for sdcc choosing to hassle that it for the '_flag' variable only ? Could
if be just for it is initialized with 0 and not with '\0' ?
For now I got only a fancy but useless trick to prefer RHS to IY pointer :)

Last but not least, I like the Alvin proposal of a less flexible (but
easier) approach to the segments.
I'd drop down another idea, what about a new linker option capable to
prepare two code segments, one for the current code along with a 'far call'
list and the other one containing the 'far' libraries being linked in ?
Im most of the cases there will be about 32K for the main program plus 16K
for the libraries..



------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
Philipp Klaus Krause

Post by Philipp Klaus Krause »

Am 14.10.2010 21:48, schrieb Stefano Bodrato:
Yes. This is another problem that will need to be solved. The
versatility of the peephole optimizer is one of sdcc's strengths.
Unfortunately currently a large part of it only works with asXXXX output.
Maybe automatically translate the peephole rules for the different
assemblers, e.g. using some sed script?

I'm trying to get an overall view of the compiler source, it is very well
structured and full of suggestions for new ideas in any corner.
On the the optimization side there are various ideas coming up, I try to
drop down some:
- that fast way to do some calculation (i.e. sequences of add a,/rla for
multiplications) could generate the same instructions list in several
portions of the resulting program. It could be 'extracted', put somewhere
a single time and 'called', but probably this requires a new optimizing
engine.

I already thought about this some time ago. To be most effective this
would have to be a link-time optimization instead of a compile-time
optimization.

- With z88dk we're getting two peephole optimizers, a quick and dirty way
could be to convert the sdcc rules into z88dk and invoke them only when the
"-compiler=sdcc" option is used.

I don't think z88dk can handle all the peephole rules sdcc can handle.
In particular I suppose this will be a problem for the most powerful
ones (e.g. those using notUsed() function). In the medium term the
peephole support in sdcc should be fixed to work with other assemblers.

Philipp

------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

- that fast way to do some calculation (i.e. sequences of add a,/rla for
multiplications) could generate the same instructions list in several
portions of the resulting program. It could be 'extracted', put somewhere
a single time and 'called', but probably this requires a new optimizing
engine.

I've been doing something similar already within some of the library routines. For example, this snippet of code initializes a data structure to some value (probably 0):


****************
ld (hl),a
inc hl

ld (hl),a
inc hl

...

ld (hl),a
ret

l_setmem equ $

*****************

Then a function would "call l_setmem-2*num" where num is some constant to initialize num bytes of the data structure. It's faster and shorter than an ldir and it avoids using bc or affecting the flags. The compiler could choose to implement multiply code in a similar way but I think if space/speed tradeoffs are being made, maybe a compile time flag set by the user could choose which way to go.

- Managing the arithmentic differently for char and int types is worth for
speed only, a single sub call could save a lot of space.

I would keep that stuff in. I had already begun to do this in z88dk as many library routines needed to do 16x8 divides or 32x8 divides and there is a very high cost in time in using a generic 16x16 or 32x32 divide in these cases, not to mention the headache brought on by the divide routines using up all the registers. I have a whole set of specialized routines that do things faster and with fewer registers. The code from gbdk in sdcc does something really good as well -- it tries to eliminate redundant looping when the arguments are 8 bit rather than 16 and this can save a lot of time and is something I will try to bring into the new multiply and divide routines. I didn't spot any 32 built multiply or divide in the z80-specific dir of sdcc so I assume the generic one using a bunch of 16x16s in the main directory is used? Anyway this reduction of loop iterations is something that can benefit the 32 bit multiply and divide code especially I think.

- _FASTCALL_ and _CALLEE_, please :P
- (this is for z88dk too).. what about a sort of FASTCALL way to pass two
parameters ?

There is an unimplemented stub in the z80 code generator for caller-save functions (caller saves registers it needs before calling) which would be ideal to qualify calls made into asm-implemented library routines. This would solve the ix problem (as in we don't want a bunch of extra C-related code in the libraries since they are to target asm programs as well) easily and simply.

I also saw mention of FASTCALL in the source code with the possibility of passing two parameters in DE, HL.

Anyway, yes, fastcall and callee linkage are a must. I suppose with fully typed function pointers there will be no trouble with calling a fastcall, callee or standard linked subroutine though there would need to be 3 different methods for doing a call through a function pointer.

Last but not least, I like the Alvin proposal of a less flexible (but
easier) approach to the segments.
I'd drop down another idea, what about a new linker option capable to
prepare two code segments, one for the current code along with a 'far call'
list and the other one containing the 'far' libraries being linked in ?
Im most of the cases there will be about 32K for the main program plus 16K
for the libraries..

sdcc is generating several segments for the z80 now: one for global statics (as in ROM data, including strings), one for intiialized golbal statics (in RAM), one for uninitialized global data (zeroed at startup) and one for code, I believe (it's been a week since I looked and I only glanced at it). Anyway these are the minimum set of segments that would be needed.

I am thinking an incremental linker (one that can resolve some references among a set of files) and a means for the user to create segment aliases so that he can say "all code segment stuff should go in this new segment, etc" can be used to generate bankswitched code. Maybe a new asm directive with file scope as in "using codeseg2::strlen" could also give instruction to the linker as to which bank's strlen is to be called from the current segment. From C perhaps a pragma could enclose a header file or function prototypes to say in which segment the functions are to be located.

Anyway, long story short I believe using the small set of directives in the first paragraph which target intended use of the code/data combined with a means to incrementally link and specify aliases for those segments would make it possible to create any kind of bankswitched program. I haven't thought through the details as this is still a long way off but I am satisfied with using the basic set of segments as they are for now. I know what you are thinking of regarding these far libraries stef and I believe this sort of arrangement makes it unnecessary to specify a new segment just for far code.



------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
Philipp Klaus Krause

Post by Philipp Klaus Krause »

Am 19.09.2010 00:02, schrieb Philipp Klaus Krause:

4. sdcc needs to be able to pass parameters in reverse order to get
support of the z88dk libs (with a holding number of args for va_args funcs)
We're now in a state where you can compile code and have it working
across most platforms calling z88dk library funcs.
5. Option in sdcc not to use ix and iy.
This now gets us working on all platforms.
[...]

I'll look into 4 and 5 after the sdcc 3.0.0 release, which is scheduled
for mid to late october.

Philipp

Just to give you an update: The sdcc 3.0 release has been delayed a bit
and is now scheduled for the first of November. You might want to try
our current release candidate.

Philipp

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
Post Reply