[M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c?

[Jay K]

more type improvements in m3cc/parse.c?


So, the initial goal of fixing SPARC64_SOLARIS
without breaking anything seems to have worked.
 I have to check all the platforms still.


And debugging of records is much much better in gdb.
  (again, needs testing..)


Now I'd like to continue:
 enums
 packed
 objects
 function pointer types
 arrays
 open arrays
 
 
This requires a fairly complete understanding of the "object model".
Basically what Modula-3 looks like in C.
  Yes, this dovetails into generating C.


Stuff like:
 Are enums always 32 bits?
 Or are they chosen among 8, 16, 32 bits, as needed to fit their values?
 Or are they always integer sized but we limit them to 2^32 values?
 
 
What can/does packed do?
The language spec was deliberately vague.
It can add arbitrary padding to the end of records?
It removes any possible padding at end of records?
It can shrink enums and subranges to other than 8/16/32/64 bits?
 It can grow enums/subranges?
 
 
 What do objects look like?
 I assume they are something like C++ classes with single inheritance.
 A vtable pointer followed by the data.
 

What do arrays look like?
 This was answered recently. Including it here for completeness.
 I should commit what was said.

 
What are the ramifications of the ability to do type switching at runtime?
Maybe another field in objects?


What do exceptions look like?
 Just records?
 

Just read m3front to learn all this?
And look at generated code?
I can, but I'm lazy.


If anyone knows all this stuff off the top of their head,
checking it into doc/notes/objectmodel.txt is roughly
my preference.


I will have to put together a bunch of small samples, that
both RTIO.PrintWhatever their data, and step through in gdb
and see if things match.


How much, if any of this is subject to change?
I suspect none of it.
Sure, you are supposed to know it when you write Modula-3.
But parse.c can/should, caveat about making the same decisions as m3front.


Thanks,
 - Jay