[M3devel] [M3commit] CVS Update: cm3

[Jay]

 > In reading your post, you state that you deoptimized the native implementation to make it match Cygwin.  
 
It is such a slight deoptimization, I think it is ok.
 
Are you comfortable with only slightly optimizing never inlining integrated backend? Not optimal.
But it sure does build faster than gcc.
Great for productivity.
And its "always only slightly optimizing" mode generates much better code than gcc's default "no optimization at all" mode. But gcc with optimizing should be able to beat it handily -- e.g. inline.
 
 
Do you use gcc's optimizer or not?
I usually don't. I want to be able to debug line by line with a close correlation of binary to source.
I have plenty of experience debugging optimized code, and it can be an interesting fun educational challenge, but unless I'm really bored, I'd rather not do it.
If you don't use the optimizer, then again, not optimal.
I wouldn't mind /some/ optimization, esp. some inlining and constant propagation, but I dislike it when the debugger jumps around with no clue as to what "line" of code I am on (because "lines" of code often don't exist in optimized code, a line can go away, or get split up, or become shared with other "lines", etc.).
 
 
Are you aware of the cost of PushEFrame/try/raise/finally in Modula-3?

Nobody seems to care much.
Granted, SOLgnu/sun does it better, so people care.Almost anything is more efficient.
Windows/x86 C/C++ does something similar but way more optimized.
All other C/C++ systems use "stack walking" and incur little cost from the "try" alone.
 Though raise is often more expensive.
 
 
Ok, granted, my deoptimization is to make PushEFrame even less efficient.
It is already space (stack) and CPU inefficient.
I made it more space (stack) inefficient.
Could contribute to stack exhaustion.
 
 
 
 > IMO, ultimately we need a turn-key download and install routine for Modula-3
 > that just works, out-of-the-box.  If you give me an EXE, a CMD, or a BAT, for the install
 
Can you try the uploaded archives I produced?
Are they really too difficult to use?You extract them, optionally rename the root directory, run vcvars, add cm3 to %PATH%, and are done.
Arguably much better than the older interactive cminstall.
Not sure about the non-interactive variant.
 
I understand your point.
 
No Python is needed to download and run.
No Python is really needed to build the system, but cm3 itself only builds a package at a time.
The sh and Python automation is around cd'ing around and building, in the right order, with some filtering, and my Python adds ability to pick target platform on the command line, without messing around every time with config files and %PATH% and such. It is nice and convenient, it adds features that cm3 doesn't provide, but you don't have to have it.
 
 > BTW, I can certainly help in maintaining the CMD/BAT install routines or in making a better CMINSTALL.
 
Your cmd/bat are actually still probably correct or very nearly so.
The dependency orders rarely/never change.
The main change is that sysutils was added.
And perhaps that the dependency order became "more important" but not actually "different".
That is, probably for a long time, an old cm3 could compile a current m3core/libm3.
Now you need a cm3 with LONGINT support to build them (which itself is now a few years old).
So you must first build the compiler with the old compiler, THEN build the current runtime.
The "upgrade" scripts handle this.
Again you can just cd around in the right order, with some repetition (you build the compiler first
against the old runtime, then build the current runtime, then rebuild the compiler against the new runtime; arguably not needed but very much what you want to do).
 
[redundancy here due to bad editing, sorry]
 
Also, if you are bootstrapping from an older build, then you use their m3core and libm3, and then build the compiler up in dependency order starting with sysutils.
 
If you are building from scratch with a current compiler, then you can start with m3core and go up from there.
(Or import-libs on Windows, if needed, but this really just a workaround for old distributions, like 4.1, like before Tony's change to remove the "gcdefs" stuff.)
 
  >  At one point, I thought we had a file that showed the package build order and dependencies.
 
I was a big proponent of this, and it now exists and is in use..but I don't use it usually. :)
It is the scripts/pkginfo.txt file.
All the sh scripts use it I believe. Therefore the tinderbox uses it I believe.
My cmd that I don't use (scripts/win) I think use it.
My python code does not use it. Oops.
Well, I think I did implement it at least, so I didn't push someone else to and then not use it.. :)
(Pick your evil -- do something yourself, and then not use it, or push someone else to, and then not use it).
 
Eh, I should just use it from the Python, not a big deal.
 
Not only the build order, but the file also aids in package set selection.
It doesn't do the filtering though, oh well.
 
 - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20081231/790f371c/attachment-0002.html>