Re: [Tinycc-devel] OSX

[Peter \"Firefly\" Lund]

On Sun, 20 Apr 2003, Steve Dekorte wrote:

> On Sunday, April 20, 2003, at 03:16 AM, Peter "Firefly" Lund wrote:
> > 1) Do you know PPC assembler?
>
> Nope. I did some C64 assembly back in the day. But I don't remember
> much of it.

I have just downloaded your Io stuff and read some of the docs.  If you
can do that and once knew 6510 assembly you shouldn't have any big
difficulties with PPC assembler -- a few new concepts but nothing like the
general concept of machine code + a load of details.  Tedious but not
hard.

> > 2) Do you know the executable format for OS X?  Does it use ELF?  COFF?
>
> Mach-O, I think. I don't know anything about executable formats, btw.
> This sounds difficult...

You'll have to do some research on that.  Maybe you can find some code you
can steal^Wimport into the project somewhere?

> > 3) Do you know anything about compilers in general?
>
> I've written a VM before: http://www.iolanguage.com/

Nice language, nice design :)

> > 4) Do you know 386+ assembler?
>
> Nope.

A shame.  It would have been easier to read/modify i386-gen.c if you did.

> > 5) Do you know Unix build systems?
>
> I'm familiar with make.

Good :)

(I feared you had mostly/only used Macintosh IDEs)

It is a pain to support multiple build systems.  tcc uses the generic Unix
system of using makefiles, which should work on everything.  Windows and
Mac platforms might need some extra packages, though.  The alternative
would be to have an extra build system for Mac OS X (perhaps even several:
one per C compiler with an IDE), an extra build system for Windows (again,
perhaps even several: Microsoft Visual C++, Borland, Symantec...).

We would much rather only use one system and require a sane make on each
build platform.

You might want to check out the Fink project - it is a port of all the
basic GNU stuff to Mac OS X, in some cases replacing not-very-good unix
tools with better ones.

> >  intermediate code, register allocation, a code generator, etc.
>
> I haven't done that before.

Ah.  Those are the things you need to know more about to write the new
backend.  And the assembly/architecture and executable file format I
mentioned earlier.  Probably also a bit on how linking and loading
normally works.

But you can learn as you go :)

> Have you considered using something like GNU Lightning to produce your
> assembly code? It already supports several architectures.

I haven't.  I don't think anybody else has, either.  Now that I have, I
don't think it's a good idea ;)

GNU Lightning is for run-time code generation for VMs, not for compilers.
It's "integer" part seems to be well-supported but last time I checked the
floating-point part wasn't.

Even if it did support floating-point well it wouldn't really help much
for tcc.

Instead of i386-gen.c emitting 386 opcodes directly we would get a
generic-gen.c that used the GNU Lightning macros to emit whatever-cpu
opcodes.  It would not make the generic-gen.c code any easier to follow or
maintain than i386-gen.c currently is.  My gut feeling is also that it
won't even make it easier to support multiple targets.  It definitely
won't generate the code faster (having an extra RISC like layer in between
doesn't help with code generation speed).  It probably also won't generate
better code than we should be able to get with a straight-forward code
generator.

I'm currently adding comments to i386-gen.c to make sure I really
understand it (I'm not quite there yet).

The vstack interactions and the flags a value can have are horribly
underdocumented at the moment but that should improve soonish.

-Peter