Re: [zzdev] systems programming Clang

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Hi A-J,

please think of some way for Plato and Aristotele compiled code to be
referenced structurally from the ZZ space. That would mean we could
really get rid of string matching!

(I think this means that with the parts of an executable which can be
referenced from ZZ, we store the cell version ID this executable binding
was created from; inside ZZ we can then reference to that. Processors,
after all, don't do string matching; the strings are stored in the
linkable files, and in the same way we'd store the cell IDs. And if
we're forced to string matching, e.g. because of targetting the Java VM
/ interfacing with Java code, we can come up with something like
c174_958_20099 incorporating space id, space version, and cell id.)

Whaddya think? (Am I at least barely understandable? ;/ )

-b.


Antti-Juhani Kaijanaho wrote:
> 
> Hi,
> 
> I've been thinking about the Clang after Thales Clang, for systems
> programming.  I'm considering calling it Aristotle Clang, allowing a
> twin language for applications (applitudes?) programming as Plato Clang,
> but I'm open to suggestions.
> 
> The language will be a candidate for developing the bootstrapped client.
> 
> 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.
> 
> 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.  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.
> 
> Comments?
> 
> --
> %%% Antti-Juhani Kaijanaho % gaia@xxxxxx % http://www.iki.fi/gaia/ %%%