[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] systems programming Clang
- To: Antti-Juhani Kaijanaho <gaia@xxxxxx>
- Subject: Re: [zzdev] systems programming Clang
- From: Tuomas Lukka <lukka@xxxxxxxxxxx>
- Date: Thu, 31 Aug 2000 23:15:48 +0300 (EETDST)
- Cc: ZZ Development <zzdev@xxxxxxxxxx>
- In-reply-to: <20000831221612.C25248@xxxxxxxxxxx>
> A list of design criteria for the language: instead of targetting a VM
> inside the ZZ structure like Thales Clang, it will target bare metal
> (ie. the various machine languages); it will allow writing portable
> systems programs in the style of C; it will allow machine-dependent
> low-level bit fiddling (for OS kernel development); it will have
> conservatively designed abstraction mechanisms for developing big
> programs; it will be biased for hand-writing programs but will avoid
> constructs that make automatic generation hard; it will include effectivce
> and efficient FFI.
The language probably shouldn't include abstraction mechanisms but rather
meta-abstraction mechanisms to allow the coder to create new abstractions
easily. This would be basically code generation combined with reflection.
These would be Plato libraries connecting with the compiler code.
The compiler, BTW, should probably be written in Plato (or initially
Thales), not Java.
> A design problem: Tuomas would like that the initial compiler targetted C,
> but I don't think that's a viable choice, since we need a way to allow
> efficient garbage collection for some programs written in this language,
> and C as the target language effectively prevents that.
Oh, that's actually not true: to do that, we just make our own memory
allocator and a schema for the memory inside that area. Garbage collection
will need to be completely synchronized so that no pointers to that are
are saved anywhere except in that area.
General C programs are impossible to GC, but since we are writing the
whole program, the situation is very different. We don't need to use any
of the standard libraries, but simply system calls like sbrk() for more
memory or open(), write/read for IO.
Hmm, probably we will want e.g. Xlib... so we have to do this so that we
have both system malloc area and our own chunk.
> Personally I'd
> target GNU/IA32 first, since it is widely used, and Win32/IA32 as the
> first port, for the same reason. Then would probably come ARM or whatever
> the handhelds use, since we're targetting those anyway.
Targetting machine code just won't be viable since we want to be able to
run on Suns and especially SGIs, Macs etc. Also, we want to be able to
target Java or JVM as well.
The systems programming Clang should work with several *different*
platforms from the beginning: doing one platform first will give no end of
trouble when moving.