[M3devel] Downsides of Modula-3 ?

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Sun Apr 22 19:18:46 CEST 2012


Hi all:
I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space.
Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit.
Then the question what it would be like AMD64.
Thanks in advance

--- El sáb, 21/4/12, Dragiša Durić <dragisha at m3w.org> escribió:

> De: Dragiša Durić <dragisha at m3w.org>
> Asunto: Re: [M3devel] Downsides of Modula-3 ?
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: penn43 at gmx.com, "Mika Nystrom" <mika at async.caltech.edu>, m3devel at elegosoft.com
> Fecha: sábado, 21 de abril, 2012 16:28
> What would be LONGADDRESS? Pointer to
> a location inside LONGRAM? :)
> 
> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D.
> wrote:
> 
> > Hi all:
> > If we accept to exist LONGINT and ADDRESS is a Word.T
> why we don't have LONGADDRESS? That's you don't care if
> that's in UNSAFE TYPE, do you?
> > Assembly in lining was handled about perfect in
> Modula-2 for VMS I wonder why DEC didn't provide Modula-3
> support with that as well.
> > Thanks in advance
> > 
> > --- El vie, 20/4/12, Mika Nystrom <mika at async.caltech.edu>
> escribió:
> > 
> >> De: Mika Nystrom <mika at async.caltech.edu>
> >> Asunto: Re: [M3devel] Downsides of Modula-3 ?
> >> Para: penn43 at gmx.com
> >> CC: m3devel at elegosoft.com
> >> Fecha: viernes, 20 de abril, 2012 15:29
> >> 
> >> Now that I have the rather unpleasant task of
> writing C code
> >> for a client,
> >> I have a few things I "like" about C and that I
> "miss"
> >> somewhat when
> >> I write Modula-3.
> >> 
> >> I find that I sort of like the C
> preprocessor.  But
> >> maybe it's just the
> >> sort of code I'm writing with it... (test programs,
> which
> >> need lots and
> >> lots of annotations and instrumentation, something
> easy to
> >> do with cpp).
> >> 
> >> No alloca....
> >> 
> >> No varargs...
> >> 
> >> No real "const" (Java "final").  Sometimes
> WITH can do
> >> it.
> >> 
> >> No GO TO.............. can't believe I just wrote
> that but
> >> Modula-3 had
> >> as one of its design objectives to be a good target
> for code
> >> generation,
> >> and having goto would make that easier!  (Look
> at the
> >> C-Mix partial
> >> evaluator for an application.)
> >> 
> >> A C++ programmer would undoubtedly miss a lot of
> crazy C++
> >> stuff 
> >> that lets you do tricky stuff entirely without
> heap
> >> allocation.
> >> And operator overloading.
> >> 
> >> Then there are some annoying implementation
> limitations:
> >> 
> >> No EXTENDED floating point in the standard
> implementation.
> >> 
> >> Bugs in the "standard" threading library (pthreads
> >> based).  Have
> >> to use the longjmp hack version.
> >> 
> >> Dubious "enhancements" relative to the Green Book:
> LONGINT,
> >> WIDECHAR
> >> (and a lot of issues with TEXT as a result). 
> And
> >> efficiency problems
> >> in the CM3 code in *some cases* (compared with the
> older SRC
> >> M3).
> >> 
> >> ----
> >> 
> >> My own evaluation of the above is that the things
> lacking
> >> relative to C
> >> are really pretty minor and the language is so much
> easier
> >> to use
> >> and better engineered that you almost never say to
> yourself
> >> "oh I wish
> >> I could write this procedure in C" (you might say
> it of one
> >> line of code).
> >> 
> >> The implementation issues are things that could
> "easily" be
> >> fixed by
> >> someone who had the time..
> >> 
> >> Oh regarding efficiency problems: I still find that
> CM3 with
> >> optimization
> >> turned on produces code that runs faster and with a
> far
> >> smaller memory
> >> footprint than code doing the same thing in Java,
> most of
> >> the time.
> >> That's when you try to do as close to an
> apples-to-apples
> >> comparison
> >> as possible.  If you take into account the
> fact that in
> >> Modula-3 you can
> >> allocate structured memory in "batches" (called
> "arrays"!)
> >> the difference
> >> is even bigger.  Modula-3 also links far
> easier with C
> >> and Fortran than
> >> Java does.
> >> 
> >>     Mika
> >> 
> >> 
> >> 
> >> penn43 at gmx.com
> >> writes:
> >>> An object appraisal must take into account the
> problems
> >> too. So I am asking yo
> >>> u, could you please mention any downsides of
> using
> >> Modula-3, in your experienc
> >>> e?
> >>> 
> >>> Of course, the non-existent language community
> has
> >> already been mentioned as a
> >>> major downside. 
> >>> And the lack of documentation.
> >>> What about other issues, such as compiler
> efficiency? Or
> >> interaction with fore
> >>> ign libraries?
> >>> 
> >>> Thanks
> >>> 
> >>> Marresh
> >> 
> 
> 



More information about the M3devel mailing list