From: Garrett Goebel
> From: Dan Sugalski [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]]
> > (Though if someone comes up with a way to make the
> > platform-dependent bits really small and isolated I'm all for it)
>
[mention of C--]
>
> From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > I don't think so--we want perl to generate the executable
> > code directly. If we're generating an intermediate language
> > that then gets compiled, we might as well use C. (Even
> > though it's rather limited)
Hmm... I'm not asking for enlightenment, well maybe a few more shadows in
what is otherwise darkness ;)
I was thinking more along the lines of the implementation of the Perl
interpreter, etc. in the context of working around the failings of C. Not
the generation of Perl bytecode... So I'm probably wandering off topic
(Which is easy as I'm already having trouble *following* the topic).
Everyone seems to have their favorite laundry list of the failings of C, and
an accompanying list of complex and/or fragile solutions. It seems many of
the perl6-internals discussions are more or less: "How do we get around such
and such failing of C and the Standard Library when doing foo?"
I'm not claiming to understand this laundry list of C's short-comings... I'm
just regurgitating.
C Short-comings:
o Stdio and asynchronous IO
o Tail call optimization
o Garbage collection w/ layout of stack frames
o Memory Aliasing and instruction scheduling
o Returning multiple values in registers from procedures
o Misaligned memory accesses
o Range checks on multi-way jumps
o Data layout
o code generator specific extensions to access stack,
allocation, and environment pointers
o [you're own personal list...]
How to solve some of these problems, such as replacing Stdio with ATT's sfio
library, etc. have already been discussed. Past discussions made mention of
C-- as well.
I don't know if it'd be possible to realistically consider using C-- at all.
Or if it'd be possible to cull ideas from C-- that could be used in the C
implementation or in conjunction with a C implementation. As I said, I'm 99%
ignorant on this topic. But I am fairly capable of regurgitating the C--
overview, and it does appear to touch on the subject of minimizing the Perl6
platform-dependent bits...
C-- Goals:
o Interoperable: C-- <-> C
o Portable assembler intended particularly for garbage-collected
source languages
o Blazingly fast w/ architecture independence considerations
o Exploits existing code generators: gcc, VPO,
o Independent of any particular code generator. I.e., no
commitment to a particular backend
o Largely independent of target architecture. Exception: word size
o Human writable and readable
o Not a distribution format
o Is assembler, not full programming language
C-- Features:
o Interfaces w/ C
o Ordinary procedures
x procedures may return multiple values
x number and type of parameters must match definition
o Weak/Minimal Typing
x Tells code generator
- How big it is
- What hardware resources to use, i.e. floats
x No provision for type security
o Tail Calls
x Guarantees tail call optimization w/o stack growth
o Local Variables
x Allow arbitrary number of LV's to be declared
x mapped to registers instead of stack slots if they'll fit
o Local labels and gotos
o Conditionals that omit range checks
o Backend has complete control of stack
x Parameterized procedures and returns
x C-- implementation is free not to use a control stack
o Detailed control of static and dynamic memory allocation
x Explicit flagging of mis-aligned or over-aligned accesses
x No support for varying Endian-ness
x No aliasing directive for pointers
o Generalized support for GC, Debuggers, and Exception Handlers
o Global registers
o Arithmetic operations and conversions between data types
o Separate compilation
And if you're still with me and interested, the C-- website can be found at
www.cminusminus.org
