[M3devel] M3CG

[Daniel Alejandro Benavides D.]

Hi all:
Although I haven't followed closely recent developments I think Abstract machines interface are needed to better interface the system.
Currently reliance in M3CGen as door-step to other compilers could make things less stable admittedly, but we need to take account of the compiler view internally and externally, where are proofs of this per-se view I don't know but If you can read this abstract (2nd paragraph, first part) of:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5167

I could abstract INTERFACES but Larch Style seems correct path (and I know of a tool called Benton for LM3 to retrieve specification requirements from knowledge base) I could extract some info from it and try to recover automaton specification and from there a specification that can readily tract the compiler (Internal language) from one of the two other and backwards SOURCE and OBJECT (and so interfaces to debug, link and load).
Thanks in advance

--- El mar, 4/9/12, Antony Hosking <hosking at cs.purdue.edu> escribió:

De: Antony Hosking <hosking at cs.purdue.edu>
Asunto: [M3devel] M3CG
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel at elegosoft.com developers" <m3devel at elegosoft.com>
Fecha: martes, 4 de septiembre, 2012 09:11

Jay,

I’ve been looking over some of your changes to M3CG interfaces.  You’ll notice that I removed your import of Cstdlib.int into M3CG_Ops.i3.  It does not belong there.  The type as declared:

 TypeUID = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];

is correct as is.  It is a 32 bit value that encodes a particular subrange, REGARDLESS of target machine.  It is improper to change that definition to rely on some C type.

I also have some other questions.  Why did you add the type Cardinal.T?  This seems entirely unnecessary, since targets don’t have a Cardinal type.  The only type they have is a target integer.  All other Modula-3 ordinal types should be simulated in the compiler using TInt.T.  I would advise that it be removed.  Also, I don’t understand why you changed descriptions of the primitive types to use this Cardinal.T instead of the original CARDINAL to hold information about the bit size, alignment, and byte size.  There is no situation in which a host will need to emulate the behavior of CARDINAL for these values (all can be represented using CARDINAL no matter what the host).

I am concerned that these changes reflect a desire on your part to change the world to fit your specific needs (whether justified or not).  The interfaces defined in M3CG were carefully designed and inherit from a long code-chain going back to the 1980’s and have not see huge changes since then.  I strongly advise against making changes unless you have good reason, because there are a number of tools that rely on M3CG (not just those in the public sources).

I am going to do a pass to revert some of your changes, since they are causing a number of my systems to fail to build.  (cf. Niagara on tinderbox).

I strongly advise that you try to use a private branch when developing new functionality.  We as a community can then go through a revision process to vet substantive changes before merging them into the trunk.

— Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120904/6514013c/attachment-0002.html>