> 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 _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
