Re: [Tinycc-devel] Using TCC as a backbone for our compiler

[Jerome St-Louis]

> Jerome, feel free to forward this to any eC mailing list if you want.
>

Our main mailing list is the ec-programming google group (
http://groups.google.com/group/ec-programming-language?hl=en ), but
it's not very active. I've referred people to this mailing list
archives. If you think this is off topic here, please feel free to
forward it there.

> I just downloaded ecere-sdk-0.44d1.tar.gz and tried to compile it
> (Debian/Sid/AMD64, Intel(R) Core(TM)2 Quad  CPU   Q9550  @ 2.83GHz, 8Gb RAM)
>
The native 64 bit support is still an upcoming milestone. I'm not sure
what the implications are regarding what you've tried to compile.

> Actually, I copied its ec-pass1.c, indent-ed it, and tried:
>
>
> Obviously, you should hack your C code generator so that its output all the
> struct definition before anything else. That should not be a big deal!
>
The main issue with that is structure types (non pointers) inside
structure declarations.
The other issue is the current design of the compiler where everything
is actually an AST node, is that what starts out as a "class" is
turned into a "struct" (and a bunch of other stuff). It gets a bit
messy and requires re-engineering. But what happens is we're playing
with "declaration id", and sometimes insert "free id" , and when
moving something up assign to the id of the declaration after which
we're moving up etc. The whole thing is a real nightmare. But it's the
current solution to this not so obvious problem. Any sound advice in
this direction would of course me immensely appreciated. But yeah, the
root of the basic problem with putting structs at the top is structs
using other opaque struct types.

> The printf warning should be really annoying to you! Put %ld instead of %d;
> that matters on 64 bits machine!

Again, 64 bit: ain't quite there yet... It is probably that we haven't
caught this one yet.

> And indeed the compilation time is very quick, barely measurable.

"barely measurable" is good.

Thanks for all that great feedback!

>
> I actually suggest that the compiler to run on eC's generated C code should
> be user configurable.
>
This used to be the case, until things started getting serious and it
wasn't practical to keep testing all the compilers.
It is actually configurable in the ide (or is meant to be). The main
obstacle are the gcc extensions that the generator makes use of.
>
>
> Perhaps even, you could have your compiler work in two different modes:

That is the idea, as I was saying. My personal preferences would be
libtcc for the scripting stuff, and a gcc frontend for the compiled
stuff.
>
> You
> won't even have to produce any executable binary. You could run it in the
> same process as your compiler.

That is the goal.

Thanks again,

Jerome