[M3devel] Compiling Modula-3 to C

[Jay K]

Agitation not necessarly inferred. :)


Mika, the thing is.. consider "safety".
I can argue..as a C programmer..I know what is safe, I don't
need the language protection.
Practise proves this is somewhat true, somewhat false.
   
 
Similar to your argument:
 I know what is opaque, I don't need the language protection.

 
I don't think a comment declaring opacity is strong enough.


C++ does this better, even though also a little weak.
In C++ I would put in "private:" and the compiler enforces it.
If someone is determined to break through, they must
edit the header, possibly recompile, or duplicate the declaration
without private and cast. There is no accidental violation
of private.
I understand there is the issue of the size still being revealed
  which is an important practical matter in terms of coupling
  and need to rebuild. But at the abstract enforced interface
  level, it doesn't matter.


I understand that C++ is a little bit complicated, with public/private/protected, and friends.
And C# has more options (visible to the assembly/.dll).
I think at least one bit is worthwhile though.
public or private.
Public to all or nobody.
I doubt new syntax would even be needed.
Just like:

foo.i3:
TYPE Foo;
or TYPE FooPublic = RECORD END; TYPE <: FooPublic;

foo.m3
 REVEAL Foo = RECORD ... END;


Target.Int I think is a good example.
It is small, fixed size, not a reference, not separately/heap allocated.
But it is opaque only via comment.


I have a 2.x tree somewhere, recently downloaded from the web.
It does Modula-3-to-C within what was and is m3front.
The "design" of the output C can be reclaimed.
The code has to/should be sprinkled around elsewhere, behind an implementation
of CG.i3.
And as you allude, I might try doing it from scratch anyway. :)


 - Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Sat, 24 Apr 2010 15:23:18 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Compiling Modula-3 to C
>
> Jay,
>
> My point in sharing that was not to agitate for making the changes in
> Modula-3 that Rustan did for his project. (It's his M.S. thesis.)
>
> I wanted to show the quality of the assembly code that one existing
> Modula-3-to-C-to-ASM toolchain has generated. It doesn't look
> *horrendous* to me, honestly, only maybe the footprint is a bit on the
> large side. One thing one could try of course is to type in Rustan's
> generated C code and compare what gcc spits out from compiling it it to
> the ASM generated by compiling the original M3 code. (On one's favorite
> modern architecture.)
>
> I have Modula-3D in source form so I am sure the Modula-3-to-C compiler is
> in there, and most of it is in the SRC sources anyhow. MIPS especially.
> No need to write a brand new one.
>
> No you cannot have a type with compiler-enforced opacity without requiring
> heap allocation. It's a shortcoming of the language, yes. But you know,
> you can just leave a comment that says the type is opaque.
>
> The point of M3's safety rules is to prevent unchecked runtime errors.
>
> M3's opaqueness rules are defined in terms of OBJECT which are always
> references. The designers felt that the C++ objects were too hard to
> achieve.
>
> BY THE WAY, the whole way Modula-3 does opaqueness is in the minds of
> anal-retentive OO people completely wrong (I think it is brilliant).
> They would have you declare in your object type who can touch the
> bits of it. friends, protected, etc. In Modula-3 it's mostly up to
> the *client* to decide how much opaqueness is right.
>
> For example:
>
> INTERFACE Q; TYPE T <: Public; END Q.
>
> INTERFACE QFriends; REVEAL Q.T <: Friendly; END QFriends.
>
> INTERFACE QPrivate; REVEAL Q.T <: Private; END QPrivate.
>
> A client R of Q can then go ahead and IMPORT QFriends and QPrivate as
> it pleases, regardless of what the relationship between R and Q is.
> (There is a hack in quake to hide certain interfaces but it's only
> done at one level and it's not part of the Modula-3 language proper.)
>
> Thus, Modula-3 assumes that programmers are a bit more responsible than
> the hiding rules available in C++ or Java. Which is why I say that
> not having the opaqueness available for non-ref types is not such a big
> deal, really. The language is trying to help you not make stupid
> mistakes---it's not some kind of "OO cleanliness police".
>
> I have written a lot of M3 code and have indeed missed opaque nonreference
> objects from time to time, but you learn to live with it, just like
> you learn to live with the idiosyncracies of any programming language.
> From personal experience all I can say is that M3's idiosyncracies
> are far less annoying than those of any other "practical" programming
> language I've ever used. (This is not a criticism, but how much M3 have
> you actually written?)
>
> Oh, regarding link-time optimization, see:
>
> http://www.modula3.org/threads/2/#linkTimeOptimization
>
> Mika
>
>
>
> Jay K writes:
>>
>>I haven't read this closely yet=2C I admit.
>>
>>
>>I'm sure we'll get a Modula-3 to C backend before much longer.
>>It greatly increases your real and theoretical platform support for
>>one medium upfront cost=2C and perhaps a little bit of ongoing maintenance =
>>if some oddities are reported.
>>I'll be tired of the old way fairly soon.
>>There remain too many viable but unsupported targets.
>>If it has pthreads (or sigaltstack)=2C POSIX (or NT)=2C and a C compiler=2C=
>> that should be all it takes.
>>Notice that there are now affordable and somewhat performant MIPS laptops t=
>>hat
>>=A0 run at least Linux and OpenBSD. Notice that FreeBSD is slowly expanding
>>=A0 its targets=2C including PowerPC=2C MIPS=2C SPARC64.
>>
>>
>>There will probably be an option to generate C++ as well=2C which
>>should offer more efficient exception handling than portable C.
>>
>>Whether or not it it is all idiomatic and intuitive to interoperate with=2C=
>> unknown.
>>
>>Regarding that paper:
>>
>>One should try to remain mindful of when language change is needed vs. mere=
>>ly library.
>>=A0=A0 I didn't read enough to see if they need language changes.
>>=A0=A0 I do believe Modula-3 could benefit from some language changes. Thou=
>>gh that might be mitigated
>>=A0=A0 and/or eliminated by me knowing Modula-3 better. For example=2C can =
>>I have a type with
>>=A0=A0 compiler-enforced opacity without requiring heap allocation?
>>
>>C compilers are probably better these days.
>>=A0Look -- gcc 4.5 just caught up some with Visual C++ and others and has "=
>>LTO": link time optimization.
>>=A0 I believe Sun also has had this a while=2C and I'm sure others.
>>=A0 I rarely turn on optimization though=2C I admit.
>>=A0 Disk and network I/O tend to dominate all costs. I don't do heavy compu=
>>tation.
>>
>>
>>Shared libraries are always going to seem bloated because they export every=
>>thing=2C
>>even unused stuff.
>>
>>
>>The paper seems little confused on this matter=2C depending on the
>>quality/behavior of the linker=2C and whether or not functions are "separat=
>>ed" within
>>object files. Visual C++ has the -Gy flag which you should *always* use.
>>I don't know why it is an even an option. It makes each function within an =
>>object
>>separate=2C so you only link in what you use=2C and what that references=2C=
>> transitive closure.
>>For better and for worse=2C data is not linked in with that same high level=
>> of granularity.
>>If you get any data from an object=2C you get it all.
>>And that includes pointers to functions=2C and whatever those functions cal=
>>l=2C even
>>if the data isn't referenced.
>>
>>
>>I know that historically linkers didn't strip out anything.
>>I'm surprised such linkers existed. Are they still in use?
>>(What do GNU=2C Sun=2C Mac do?)
>>
>>
>>=A0- Jay
>>
>>----------------------------------------
>>> To: m3devel at elegosoft.com
>>> Date: Sat=2C 24 Apr 2010 14:29:52 -0700
>>> From: mika at async.async.caltech.edu
>>> Subject: [M3devel] Compiling Modula-3 to C
>>>
>>>
>>> The question of making a Modula-3 compiler emit C code as output comes
>>> up on this mailing list from time to time.
>>>
>>> I just discovered a reference to a real example of this.
>>>
>>> http://caltechcstr.library.caltech.edu/218/01/93-15.pdf
>>>
>>> Note pages 49-50 (54-55 in the PDF).
>>>
>>> I also find the byte counts on page 49 interesting. I wish my m3core
>>> were that small!
>>>
>>> Mika
>> =