[M3devel] layout of objects?

[Dragiša Durić]

Relevant part is:

 LOOPHOLE(res - ADRSIZE(Header), RefHeader)^ :=
        Header{typecode := def.typecode, dirty := TRUE};

So, there ia a header, where data is combined. dirty fields is for GC, and typecode is index into RT0 structures.

--
Divided by a common language

Dragiša Durić
dragisha at m3w.org




On Mar 22, 2013, at 7:44 AM, Tony Hosking wrote:

> 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 University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 

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