[A86] SDCC v2.3.0
[Prev][Next][Index][Thread]
[A86] SDCC v2.3.0
> Van: David Phillips <david@acz.org>
>
> > you could write a frontend (?right word?) that generates iCode for your
> > language, and the backends do the rest.
>
> That would defeat the purpose of doing a new language. Having a portable
> intermediate language is good when wanting multiple front ends of back
> ends to a compiler, but it doesn't help you a whole lot with
optimization.
Okay, but at the moment what I get from SDCC is better than all other (z80
targeting) compilers I've seen.
> This is likely the reason that gcc does not produce very good code, and
> probably never will.
You told lately something about 'vectors' that GCC doesn't (but should)
use. Can you explain a bit further? In the iCode dump of SDCC I see the
term 'bitVector', could that be the same you were talking about?
> A new language is necessary because C is not the best language
> for making programs for the z80. It was designed for UNIX systems, not
> calcs.
Well, that something I can't deny.
> > The major problem I see is that it hasn't got a decent lib (only fairly
> > basic standard C stuff). You can also still only compile for one target
> > (let's say CrASH[82], versus Ion[83(+)]), and you need to 'manualy'
> > switch to another target by copying a new crt0.o file into the Z80-lib
> > directory.
> > Which also means that 'descriptions' and 'icons' (stored in the shell
> > header) would be always the same unless you assemble a new crt0.o file.
> > This are all 'fixable', but your compiler will have the same problems
> > in advance (no matter what road you take to create your compiler),
> > untill it has 'grown' enough to get supported by the users.
>
> Do you really need libc when writing calc programs? If you do, then you
> probably need to rethink what you are doing. Again, that's not the
> purpose here.
Uhm, I didn't mean standard stuff (text I/O, string.h, etc.), but graphics
(routines) and the such. At the moment you can make a tremendously
beautiful C compiled program that can't output anything (graphics text
whatever), not usefull I think...
You could off coarse define some ROM routines as 'external' (like _puts),
SDCC passes the first argument via HL.
> It seems like you would want to just compile the crt0 module along with
> the project. Have a skeleton project available, and copy it when
starting
> a new project. Doesn't seem like that big of a problem.
Okay some script (batch, whatever) that you can input the name, icon-data
(going to be difficult), and shell type. It will first assemble the right
crt0 with the input, copy the crt0.o file to the right dir and start the
compiler?
I think that's quite inconveniant in comparsion to the z88dk where you can
do (in your c file):
#pragma output string name Description
#pragma output data icon 0xFF, 0x02,...
Which will let the compiler ouput a file (zcc_opt.def) which get's picked
up by the crt0 file. So you don't get something like:
$>SDCC tetris.c -mz80 --name="Nibbles!!!"
Because you state that in the .c file itself.
Henk Poley <><
Follow-Ups: