[M3devel] LINUXLIBC6

[Jay]

For dwarf et al: there "nothing" to it: "just" generate reasonable "code" (LLVM whatever, gcc "tree", C, etc) and the next level down handles it. Er, but for some bigger & smaller problems. 


Currently cm3cg -g for dwarf crashes. That is a small problem actually. But even if fixed, not a good experience -- no type information.


Larger "problem" & "good thing" is that the "front end" is more of a compiler than you might expect. It does "low level" things like "layout" and generates "variable plus offset" references "instead of" "field accesses".


That isn't necessarily bad. It is why/how we get away with giving gcc so little type information though.
And it might otherwise hurt debugging.


But ok. I have some ideas & plans, & some procrastination-enabling diversions.


 1. Update to gcc 4.6. Making good progress recently. This buys nothing. Procrastination.
 2. Update to gcc 4.7. Ditto.


Then there are a few more valuable things to get on to.


A. Better type info for gcc, so stock gdb much more useful. I'll probably NOT do this.


B. Use LLVM. I probably won't. But if there is a C-backend, then maybe, as that accomplishes two things at once (newer?better?cleaner?faster backend, portable C distribution)


C. Remove jmpbuf size knowledge from front end.
C.1 and maybe word size
C.2 and maybe endian
I.e. remove target dependentness


D. cooperative suspend 
i.e. again drastically increase portability


E. A C-generating backend.


The idea is, if these are all done, the system becomes "automatically" portable to "all" systems, with a pretty broad definition of "all": having a C?C++ compiler, being Posix but not too fancy (pthreads/open/read/write/close/send/recv/fork/exec, but nothing signal/semaphore related nor extensions to direct suspend threads or get stack pointer), or Win32, and optionally X Windows. 
At that point, time permitting, I might try again AIX, OpenVMS, Irix, iPhone/iPad, etc.


The remaining nagging portability concerns would be just: systems without public C compiler (windows phone, browser), and getting the second stack pointer on Itanium.


AT that point, if we ever get there, backends targeting Java, C#, JavaScript become maybe interesting (threads in JavaScript??). & the project could be considered very much more done. Maybe write other integrated backends, or linker, or target kernel interfaces instead of libc (esp. regarding threads on Linux)


Other projects at that time could include better interop between C, C++, and Modula-3. I'd like to see an end to fragile hand-written interop.


It'd also be good to move Trestle to the new X C bindings (xcb?).


I need to go back & explain something. Normally gcc compilers don't know anything about debug formats: stabs, coff, dwarf, etc. The reason cm3cg is different because what it does is mostly ignore all debugging infrastructure and generate its own custom information, for consumption by associated custom code in m3gdb. It just uses stabs as container or transport, for arbitrary data.


 - Jay (briefly/pocket-sized-computer-aka-phone)

On May 20, 2012, at 1:11 PM, Dragiša Durić <dragisha at m3w.org> wrote:

> 
> On May 18, 2012, at 9:49 PM, Jay K wrote:
> 
>> LLVM isn't a bad idea, but there is more expertise out there (and in me) with C and C++, so C and C++ are easier to generate.
>> It is a bit of a chore to learn and use.
>>  
>>  
>> JIT isn't a crazy idea either..or rather, an interpreter.
>> If you look at parse.c..and you add a few thread locals..I think it's not hard to turn it into an interpreter.
>>   (In reality you don't want to start with parse.c because of the GPL.)
> 
> LLVM and JIT are close enough. You do LLVM, you get JIT.
> 
> Also, for debugging we need DWARF. Not incompatible with LLVM. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120520/57a5410d/attachment-0002.html>