[M3devel] layout of objects?

[Jay K]

I'd like to reference a member in a struct, a typed function pointer.I think I see your point though.Each partial revelation describes a subset of the methods.Almost like multiple inheritance, multiple vtables, but subsequences within one linear vtable.More later..  - Jay
 From: hosking at cs.purdue.edu
Date: Fri, 22 Mar 2013 17:09:33 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] layout of objects?

From the language spec:
There are two kinds of revelations, partial and complete. A program can contain any number of partial revelations for an opaque type; it must contain exactly one complete revelation.

Are you typing the method table as an array?Why not simply index the array?
I don't think there is any C type that natively captures the notion of opaque types.The whole point is that you don't know all the parent types.But you do know that, given the offset of the opaque type's methods in the method table, you can compute the offset of any given method.
For example:
TYPE T <: U;
Without seeing the revelation of T there is no way to know what methods are inherited from everything between T and U.But, so long as at run time you are told the method offset of T's methods in its method table then you can find any method defined in T at a known index from that offset.
On Mar 22, 2013, at 2:18 PM, Jay <jay.krell at cornell.edu> wrote:Can it have zero revelations?

Can you assist lazy me and suggest an accurate way to describe opaque types in a typeful way in C? 

Ultimate goal would be to get m3front & m3back optionally out of the business of computing offsets, instead using C structs and members and pointers and leave layout to the C compiler.Ultimately generating one architecture-independent, pointer-size-independent C.

 I understand there are multiple challenges here and eventually m3cg and m3front will need changes, to pass down more higher level information.


 - Jay
On Mar 22, 2013, at 11:11 AM, Tony Hosking <hosking at cs.purdue.edu> wrote:

Every opaque type in a linkage must have only one revelation.

Sent from my iPad
On Mar 22, 2013, at 12:13 PM, Jay K <jay.krell at cornell.edu> wrote:




Are opaque types always revealed eventually? Or only sometimes?
I'd like to generate structs and member references and not be adding offsets to pointers.
For method calls and record field references.
And, ugh, the GC data needs to be generated using "offsetof". But probably all we get is a bunch
of integers and no indication where the frontend got them from.. :(


Thanks,
 - Jay


From: hosking at cs.purdue.edu
Date: Fri, 22 Mar 2013 03:08:04 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] layout of objects?

x>=0 means a known constant method offset at compile time.Otherwise, offset must be loaded at run time.  This is needed for opaque types, where the offset cannot be computed at run time.  Given TYPE T <: U we can't know at compile time how many methods are defined between U and T so the offset cannot be a compile time constant.
On Mar 22, 2013, at 2:01 AM, Jay K <jay.krell at cornell.edu> wrote:Do you understand hereabouts m3front/src/exprs/MethodExpr.m3?


PROCEDURE Compile (p: P) =
  VAR
    x := ObjectType.MethodOffset (p.holder);
    method: Method.Info;
  BEGIN
    Type.Compile (p.object);
    Method.SplitX (p.method, method);

    Type.LoadInfo (p.object, M3RT.OTC_defaultMethods, addr := TRUE);
    IF (x >= 0) THEN
      INC (method.offset, x);
    ELSE (* runtime offset to methods *)
      Type.LoadInfo (p.holder, M3RT.OTC_methodOffset);
      CG.Index_bytes (Target.Byte);
    END;
    CG.Boost_alignment (Target.Address.align);
    CG.Load_indirect (CG.Type.Addr, method.offset, Target.Address.size);
    CG.Boost_alignment (Target.Address.align);
  END Compile;


"runtime offset to methods"?

ObjectType.MethodOffset:

PROCEDURE MethodOffset (t: Type.T): INTEGER =
  VAR p := Confirm (t);
  BEGIN
    IF (p = NIL) THEN RETURN Unknown_w_magic END;
    GetOffsets (p, use_magic := TRUE);
    RETURN p.methodOffset;
  END MethodOffset;


PROCEDURE Confirm (t: Type.T): P =
  VAR info: Type.Info;
  BEGIN
    LOOP
      t := Type.CheckInfo (t, info);
      IF (info.class = Type.Class.Object) THEN
        RETURN t;
      ELSIF (info.class = Type.Class.Opaque) THEN
        t := Revelation.LookUp (t);
      ELSE
        RETURN NIL;
      END;
    END;
  END Confirm;


...



 - Jay





Subject: Re: [M3devel] layout of objects?
From: hosking at cs.purdue.edu
Date: Fri, 22 Mar 2013 01:44:37 -0500
CC: jay.krell at cornell.edu; m3devel at elegosoft.com
To: dragisha at m3w.org

Not quite.  I just checked RTAllocator.m3 and it is pointer to methods at offset 0, followed by fields.Heap header is at -ADRSIZE(Header).The type information in RT0 is used to initialize the object instances.

On Mar 22, 2013, at 1:34 AM, Dragiša Durić <dragisha at m3w.org> wrote:It's not m3front, it's RT0.
First data field is at offset 0, and pointer to type information is at -BYTESIZE(POINTER). Type information records are specified in RT0.
On Mar 22, 2013, at 5:56 AM, Jay K wrote:layout of objects?



How are Modula-3 objects layed out?
i.e. "OBJECT"/"METHODS"/"OVERRIDES"
I skimmed m3front and it wasn't obvious.



A common way for C++ "objects" to be layed out,
in the face of no RTTI and only single inheritance,
and virtual functions, is that a pointer to a record
of function pointers is first in the record.


Like this:


class Type
{
virtual void F1();
virtual void F2();
int data1;
int data2;
};


ends up lik more this:


struct TypeFunctions
{
 void (*F1)(Type*);
 void (*F2)(Type*);
};


struct Type
{
TypeFunctions* Functions; /* always first,
or at least a fixed offset, and located independent
of the size of the data; could also be at "-1" or such */.
int data1;
int data2;
};


Type* x;
x->F1();


=>
x->Functions->F1(x);


Functions added in more derived types go at the end.
Ditto for data.
In the absence of multiple-inheritance and RTTI, it is simple and predictable.
(RTTI makes only small modifications.)


Looking through m3front, it wasn't at all obvious if it works this way.


I would like to declare something in C (or possibly C++, but not likely),
such that I might actually recognize the various low level operations
and "uncompile" it back to a typeful/typesafe form, like the above C++
to C transform.



I can't likely uncompile to C++ with virtual functions,
because the actual layout in C++ is not guaranteed.



Granted, I am being lazy.
I should/could compile some small samples.
But I might not get the entire story that way.



Thanks,
- Jay





Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAMobile +1 765 427 5484
 		 	   		  

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130322/264a5dd3/attachment-0002.html>