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

[Mika Nystrom]

Jay can you please not use the term "object model" for what you're
describing here?  I think "object model" should be limited to what
is in the Green Book and Cardelli's paper on the Modula-3 type system.
What you're talking about is "object implementation", specific to CM3 and 
perhaps a few other compilers, not the Modula-3 programming language.
It is very confusing to see the expression used to cover both concepts,
which, though obviously related, are quite different.

And no you don't have to know many of these things when programming
in Modula-3.  As you say, the book is sometimes deliberately vague.
For some of the points you raise, the programmer should write the program
so it can deal with any possible implementation; for some others it helps
if he knows, but if he doesn't, the compiler may reject some perfectly
legal Modula-3 programs ("implementation restrictions").  Just please
don't mix that up with the language definition...

    Mika

Jay K writes:
>
>more type improvements in m3cc/parse.c?
>
>
>So=2C the initial goal of fixing SPARC64_SOLARIS
>without breaking anything seems to have worked.
>=A0I have to check all the platforms still.
>
>
>And debugging of records is much much better in gdb.
>=A0 (again=2C needs testing..)
>
>
>Now I'd like to continue:
>=A0enums
>=A0packed
>=A0objects
>=A0function pointer types
>=A0arrays
>=A0open arrays
>=A0
>=A0
>This requires a fairly complete understanding of the "object model".
>Basically what Modula-3 looks like in C.
>=A0 Yes=2C this dovetails into generating C.
>
>
>Stuff like:
>=A0Are enums always 32 bits?
>=A0Or are they chosen among 8=2C 16=2C 32 bits=2C as needed to fit their va=
>lues?
>=A0Or are they always integer sized but we limit them to 2^32 values?
>=A0
>=A0
>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?
>=A0It can grow enums/subranges?
>=A0
>=A0
>=A0What do objects look like?
>=A0I assume they are something like C++ classes with single inheritance.
>=A0A vtable pointer followed by the data.
>=A0
>
>What do arrays look like?
>=A0This was answered recently. Including it here for completeness.
>=A0I should commit what was said.
>
>=A0
>What are the ramifications of the ability to do type switching at runtime?
>Maybe another field in objects?
>
>
>What do exceptions look like?
>=A0Just records?
>=A0
>
>Just read m3front to learn all this?
>And look at generated code?
>I can=2C but I'm lazy.
>
>
>If anyone knows all this stuff off the top of their head=2C
>checking it into doc/notes/objectmodel.txt is roughly
>my preference.
>
>
>I will have to put together a bunch of small samples=2C that
>both RTIO.PrintWhatever their data=2C and step through in gdb
>and see if things match.
>
>
>How much=2C if any of this is subject to change?
>I suspect none of it.
>Sure=2C you are supposed to know it when you write Modula-3.
>But parse.c can/should=2C caveat about making the same decisions as m3front=
>.
>
>
>Thanks=2C
>=A0- Jay 		 	   		  =