[M3devel] [M3commit] CVS Update: cm3

[Mika Nystrom]

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.
Kind of like what they did to TEXTs... good ideas for some users, but
somewhat half-baked implementation.  Given that dynamic loading is used
so little, if at all, and it in any case only happens infrequently itself,
it seems there ought to be a way to achieve what the CM3 guys were trying
to do while retaining the performance of the older implementation, but
not if your code is a "rush job".  I think it would have been sensible
to vet Critical Mass's code a bit better before switching from PM3 to
CM3 for the "official" distribution of Modula-3.

I still use PM3 quite a bit.  I can no longer blame the TEXTs, nor can
I blame the pthreads implementation's being broken since I use CM3 with
user threads.  Now it's mainly because m3gdb works great on FreeBSD-5.5
with PM3-generated code.  I've tried so many times to get things working
on other machines with CM3 and newer m3gdb and there's always something
annoyingly wrong.  Life's too short...

     Mika

P.S. how are the pthreads coming along?  I saw some checkins (Dragisa),
does the thread tester run without hanging or crashing now?  I'd love
to use pthreads but it's not been high on my list to debug as long as
I can live with user threads...

Jay K writes:
>
>Daniel=2C I can't find the email now=2C as usual=2C you are probably wrong.
>
>
>We don't have an older runtime=2C we have a newer one=2C I think.
>With more allowance for dynamic loading.
>
>
>Mika=2C
>Maybe a TYPECASE-intense design is generally poor?
>dynamic_cast is slow in some C++ implementations.
>And I've never seen it used much. Some=2C but not much.
>The "type matching" that C++ exception handling has to do
>isn't particularly fast=2C though there are other costs there.
>Other than the stack walk=2C there is "finding the base of the object"=2C
>and strcmp to do the actual type match -- name-based-type-equality
>and all that=2C with a hope that it suffices and no runtime checking
>of type hashes like Modula-3 does..
>
>
>Maybe you should switch on your own type tag?
>=A0 But I guess Modula-3 doesn't have unions.
>Or use OBJECT and method calls?
>
>
>Which reminds me...it bothers me that OBJECT requires
>heap allocation and garbage collection. It shouldn't require either.
>I know we have function pointers available to simulate it=2C
>without heap allocation=2C but what I don't know=2C is if the "implicit dow=
>ncast"
>in a virtual function/method call is doable in safe code or not.
>I'll have to look into it..but I'm busy now..
>
>
>Maybe there is an optimization whereby the compiler
>can figure out that there is a small set of likely types
>that it could check first?
>
>
>Or maybe the full feature could be implemented more efficiently?
>
>
>Maybe it can be optimized based on the fact that the types
>known to the system are read-mostly=2C rarely written/appended?
>
>
>I don't know.
>I'd really have to look into what the language supports
>and how it is implemented. I'm not certain of either.
>
>
>In C++=2C typeid() is fast=2C and requires there be virtual
>functions (OBJECT). Is TYPECASE limited to OBJECTs?
>Or heap allocated data?
>
>
>Later..
>=A0- Jay
>
>
>
>
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>> Date: Wed=2C 6 Jun 2012 09:18:08 -0700
>> From: mika at async.caltech.edu
>>
>> Jay K writes:
>> >
>> ...
>> >7) Do folks out there really use the Modula-3/gcc optimizer=3D2C and not=
>ice i=3D
>> >t produces code that runs much faster?
>>
>> If we are talking about turning on optimizations in the m3makefile=2C the=
>n the
>> answer is:
>>
>> Yes! At least with CM3 it makes a huge difference in runtime. Without
>> the optimizer CM3-produced code runs far slower than PM3-produced code
>> (I've seen 3X I think.) With it=2C CM3 can sometimes keep up. Unless you
>> use a lot of TYPECASE or other constructs that have a much less efficient
>> implementation in the CM3 libraries than in the PM3 libraries.
>>
>> Mika
> 		 	   		  =