[M3devel] [M3commit] CVS Update: cm3

[Hendrik Boom]

On Thu, Jun 07, 2012 at 09:36:41AM -0700, Mika Nystrom wrote:
> Hi Jay,
> 
> TYPECASE is limited to "reference" types, which effectively means
> heap-allocated.  Unless you can get alloca in there, I suppose... what
> I mean is that in Green Book Modula-3 the only way to get a reference
> type is either through a heap allocation or an UNSAFE operation.
> 
> TYPECASE is sometimes the only way to do things.  In the Green Book
> there are examples of using subtyping to have multiple generations
> of objects in the same pickles, for example.  In my program, it was
> inside an interpreter that's figuring things out without any prior
> type information, using ISTYPE or TYPECASE.
> 
> The issue with TYPECASE that I brought up is actually that the
> implementation of TYPECASE and ISTYPE is far slower in the CM3 m3core than
> in PM3's (= SRC M3 as far as I know).  The reason (which you allude to)
> is that Critical Mass did a lot of work on supporting dynamic loading
> of Modula-3 code (loading in types not known at compile time) and as
> with many of the other projects they carried out, the code quality was
> so-so.  Because of the restrictions of SRC and P M3, types are statically
> allocated at compile time and all their subtyping relationships are known
> at that time.  There is simply a static array of the types.  CM3, on the
> other hand, has some more complicated dynamic data structure that makes
> all the TYPECASE and ISTYPE operations much more cumbersome.  It's all
> in RT0 somewhere.  In short, CM3 does "more" than SRC M3 did but at a
> heavy performance cost.  And of course no one uses the "more" bit now.

I'd like to, if I only knew how.  I'd be really interested in having the
low-level infrastructure for JIT code generators.

-- hendrik