<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
I don't understand what LONGADDRESS is either.<BR> <BR>> >> Bugs in the "standard" threading library (pthreads<br>> >> based). Have<br>> >> to use the longjmp hack version.<br><BR>1) please elaborate<BR> <BR>2) We don't use longjmp as much any more, but get/set/make/swapcontext on platforms that support them.<BR>And where we do use longjmp, we have a more portable use than before -- we no longer hack on the jmpbuf.<BR>There is a "trick" where you use sigsetstack or some such to get the stack pointer into the jmpbuf.<BR>Look at the code and read the paper referenced. It is possible it didn't work on all platforms.<BR> <BR> <BR>But anyway, see #1.<BR>We'd really prefer to just use pthreads.<BR>Hm. I'd like to look again at what pthreads features we use -- I suspect pthreads/Win32 can be<BR>abstracted more thinly and the Modula-3 code less-forked/more-shared. But later..<BR> <BR> - Jay<BR> <BR><div><div id="SkyDrivePlaceholder"></div>> From: dragisha@m3w.org<br>> Date: Sat, 21 Apr 2012 23:28:15 +0200<br>> To: dabenavidesd@yahoo.es<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] Downsides of Modula-3 ?<br>> <br>> What would be LONGADDRESS? Pointer to a location inside LONGRAM? :)<br>> <br>> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote:<br>> <br>> > Hi all:<br>> > 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?<br>> > 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.<br>> > Thanks in advance<br>> > <br>> > --- El vie, 20/4/12, Mika Nystrom <mika@async.caltech.edu> escribió:<br>> > <br>> >> De: Mika Nystrom <mika@async.caltech.edu><br>> >> Asunto: Re: [M3devel] Downsides of Modula-3 ?<br>> >> Para: penn43@gmx.com<br>> >> CC: m3devel@elegosoft.com<br>> >> Fecha: viernes, 20 de abril, 2012 15:29<br>> >> <br>> >> Now that I have the rather unpleasant task of writing C code<br>> >> for a client,<br>> >> I have a few things I "like" about C and that I "miss"<br>> >> somewhat when<br>> >> I write Modula-3.<br>> >> <br>> >> I find that I sort of like the C preprocessor. But<br>> >> maybe it's just the<br>> >> sort of code I'm writing with it... (test programs, which<br>> >> need lots and<br>> >> lots of annotations and instrumentation, something easy to<br>> >> do with cpp).<br>> >> <br>> >> No alloca....<br>> >> <br>> >> No varargs...<br>> >> <br>> >> No real "const" (Java "final"). Sometimes WITH can do<br>> >> it.<br>> >> <br>> >> No GO TO.............. can't believe I just wrote that but<br>> >> Modula-3 had<br>> >> as one of its design objectives to be a good target for code<br>> >> generation,<br>> >> and having goto would make that easier! (Look at the<br>> >> C-Mix partial<br>> >> evaluator for an application.)<br>> >> <br>> >> A C++ programmer would undoubtedly miss a lot of crazy C++<br>> >> stuff <br>> >> that lets you do tricky stuff entirely without heap<br>> >> allocation.<br>> >> And operator overloading.<br>> >> <br>> >> Then there are some annoying implementation limitations:<br>> >> <br>> >> No EXTENDED floating point in the standard implementation.<br>> >> <br>> >> Bugs in the "standard" threading library (pthreads<br>> >> based). Have<br>> >> to use the longjmp hack version.<br>> >> <br>> >> Dubious "enhancements" relative to the Green Book: LONGINT,<br>> >> WIDECHAR<br>> >> (and a lot of issues with TEXT as a result). And<br>> >> efficiency problems<br>> >> in the CM3 code in *some cases* (compared with the older SRC<br>> >> M3).<br>> >> <br>> >> ----<br>> >> <br>> >> My own evaluation of the above is that the things lacking<br>> >> relative to C<br>> >> are really pretty minor and the language is so much easier<br>> >> to use<br>> >> and better engineered that you almost never say to yourself<br>> >> "oh I wish<br>> >> I could write this procedure in C" (you might say it of one<br>> >> line of code).<br>> >> <br>> >> The implementation issues are things that could "easily" be<br>> >> fixed by<br>> >> someone who had the time..<br>> >> <br>> >> Oh regarding efficiency problems: I still find that CM3 with<br>> >> optimization<br>> >> turned on produces code that runs faster and with a far<br>> >> smaller memory<br>> >> footprint than code doing the same thing in Java, most of<br>> >> the time.<br>> >> That's when you try to do as close to an apples-to-apples<br>> >> comparison<br>> >> as possible. If you take into account the fact that in<br>> >> Modula-3 you can<br>> >> allocate structured memory in "batches" (called "arrays"!)<br>> >> the difference<br>> >> is even bigger. Modula-3 also links far easier with C<br>> >> and Fortran than<br>> >> Java does.<br>> >> <br>> >> Mika<br>> >> <br>> >> <br>> >> <br>> >> penn43@gmx.com<br>> >> writes:<br>> >>> An object appraisal must take into account the problems<br>> >> too. So I am asking yo<br>> >>> u, could you please mention any downsides of using<br>> >> Modula-3, in your experienc<br>> >>> e?<br>> >>> <br>> >>> Of course, the non-existent language community has<br>> >> already been mentioned as a<br>> >>> major downside. <br>> >>> And the lack of documentation.<br>> >>> What about other issues, such as compiler efficiency? Or<br>> >> interaction with fore<br>> >>> ign libraries?<br>> >>> <br>> >>> Thanks<br>> >>> <br>> >>> Marresh<br>> >> <br>> <br></div> </div></body>
</html>