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

[Jay K]

Stan Lippmann's excellent book "The C   Object Model".. but ok..

Looks like I missed "not" at important place: Modula-3 programmer does NOT need to know this stuff generally. But Modula-3 implementer does.

 Jay/phone

> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? 
> Date: Fri, 3 Sep 2010 08:34:48 -0700
> From: mika at async.async.caltech.edu
> 
> 
> 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 		 	   		  =
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100903/c980af63/attachment-0002.html>