[A83] Re: GBDK


[Prev][Next][Index][Thread]

[A83] Re: GBDK




> Van: Kirk Meyer <kirk.meyer@colorado.edu>
> 
> I still don't know where this GBDK thing came from unless it's exactly
the
> same as SDCC. I got SDCC from the CVS linked to at

http://gbdk.sourceforge.net/ - The GameBoy Development Kit, uses the SDCC
compiler since a couple of releases.

> http://sdcc.sourceforge.net/ and it built perfectly on my Windows system
> under Cygwin (!)

First need to find a way to get the (15Meg?) Cygwin installation file onto
my PC, can't be via internet (at least not now, with my very slow modem).

I think I'll download the full SDCC source from CVS saturday, and try to
compile it under Suse 6.4
As far as I know the compiler in the GBDK is SDCC v2.2.1, and the last
Windows builds I could find on the SDCC site(s) are v2.2.2...
So in CVS there *might* be some even newer code hanging around (probably
with bugfixes in the Z80 code generator).

>, which has a habit of not building everything correctly.
> Realistically speaking, I think what may need to be done with SDCC is to
> rewrite the Z80 conversion. When running in its native mode, it compiles
> everything great. But once you switch to Z80, you get weird errors
> sometimes. 

A year or so ago (25 july 2000) Micheal Hope mailed me back, that he would
like it if people helped him with the GBDK/SDCC with more Z80 knowledge
then he had. I've mailed him yesterday (back) that there are now a couple
of people who could (potentialy) help him, unless they are realy going for
porting GCC...

> So yes, this means we could also take the C compiling part of
> SDCC and put it into Z88DK -- but is this possible? It seems as though
the
> compilers would use different forms for the output and targetting, which
> would mean rewriting most of Z88DK anyway.

The SDCC uses (just like GCC) some sort of intermediate code to compile to,
the backend then "translates" this into the end language (in our case Z80
assembly), the backend currently used is written for the ASZ80 (asxxxx
assembler series), but could 'easely' be rewritten to output Z80ASM code.

Why do it this way? Because we have a whole lib (in the Z88DK) which relies
on the Z80ASM assembler, and porting that (770kb of code) is somewhat more
difficult, than fixing up some errors that might occure because of change
of compiler...

	Henk Poley