[M3devel] NEW in RTType.m3

[Mika Nystrom]

Well I'm not calling Typecase and IsSubtype directly---the compiler
is inserting the calls.

Here's an example of my code:

170           IF x # NIL AND ISTYPE(x,Symbol) THEN
171             RETURN env.lookup(x)
172           ELSIF x = NIL OR NOT ISTYPE(x,Pair) THEN 
173             RETURN x
174           ELSE

this code actually winds up in here (RTType.m3):

PROCEDURE IsSubtype (a, b: Typecode): BOOLEAN =
  VAR t: RT0.TypeDefn;
  BEGIN
    IF (a = RT0.NilTypecode) THEN RETURN TRUE END;
    t := Get (a);
    IF (t = NIL) THEN RETURN FALSE; END;
    IF (t.typecode = b) THEN RETURN TRUE END;
    WHILE (t.kind = ORD (TK.Obj)) DO
      IF (t.link_state = 0) THEN FinishTypecell (t, NIL); END;
      t := LOOPHOLE (t, RT0.ObjectTypeDefn).parent;
      IF (t = NIL) THEN RETURN FALSE; END;
      IF (t.typecode = b) THEN RETURN TRUE; END;
    END;
    IF (t.traced # 0)
      THEN RETURN (b = RT0.RefanyTypecode);
      ELSE RETURN (b = RT0.AddressTypecode);
    END;
  END IsSubtype;

Again this is an example of something where the CM3 code seems to
be hurting more than PM3, but it could be that for some reason I
have more visibility into the CM3 code, or that there's an optimization
difference (I haven't been able to investigate this fully yet).  In
any case, it's clear that if IsSubtype could be replaced with a
table lookup, this kind of code would be accelerated by potentially
a lot.

Note that while in the above example the code might be accelerated
by (in my opinion, less clear) use of TYPECODE (since I never subtype
Symbol or Pair---for now!), this is not so for some NARROWs.  The
NARROWs also wind up calling RTType.IsSubtype, and they arise because
I have types that depend on each other, and unless I want to introduce
extra complexity (new partial revelations) or stick everything in
the same interface, I am forced to NARROW something to avoid a
circular dependency of interfaces...  A method of A.T takes a B.T
and a method of B.T takes an A.T, so I make a supertype X.T s.t.
A.T <: X.T ; then I can declare B.T.m to take an X.T and NARROW it
to A.T within B.T.m... triggering a call to the above code.  (For
simplicity's sake, X.T could be REFANY or ROOT.)  An attempt to
declare B.T.m as taking A.T would lead to a circular dependency
between A and B.  The code is really rather simple and it's a shame
if you have to make it look much more complicated to avoid issues
like these which might equally well be solved by tweaking the runtime
implementation a bit.

     Mika

Tony Hosking writes:
>Could be dangerous depending on module link orderings.  Might be  
>better to cache your own lookups in your interpreter.
>
>On 23 Oct 2008, at 09:24, Mika Nystrom wrote:
>
>> Hello Modula-3 people,
>>
>> Does anyone know whether there is anything that prevents using NEW
>> in RTType.m3?
>>
>> I added a lot of memory recycling to the Scheme interpreter I am
>> working on, and now it seems it is spending a lot of time in Typecase
>> and IsSubtype.  I was wondering if it is possible to memoize IsSubtype
>> inside RTType.m3...  (specifically just replacing IsSubtype with an
>> array lookup).
>>
>> It is the nature of the interpreter that it spends a lot of time
>> checking types and narrowing things back and forth, as Scheme and
>> Modula-3 references share the same representation.
>>
>>      Mika