[M3devel] [M3commit] CVS Update: cm3

Wed Dec 31 21:30:40 CET 2008

Jay:

First, I do want to say thanks for all you are doing for the cause of Modula-3.  I don't think we say thanks enough for what others do for us.  THANK YOU!

I don't want to be perceived as "complaining", rather I am trying to voice my opinion in the hopes of influencing future direction.  Of course, since I'm not doing the work, I can only make suggestions.

In reading your post, you state that you deoptimized the native implementation to make it match Cygwin.  Now, I'm not sure how much effect this deoptimization has (maybe little), but it is clear that in this case your implementation choice has favored the non-native implementation over the native one.  IMO, tradeoffs of this type are not good.  If one is trying to convince someone to use Modula-3, why would you want to give them a "deoptimized" version just to make it easier to support a non-native environment---indeed, one that they may not even want/use?  If we have to make a trade-off, I say favor the native implementation always over the non-native one.

What I'm trying to say here is that my experience as a software, systems, and program engineer is that I've always been forced to justify the cost/benefit of development tools for any project.  Many times I've had to go head to head with folks higher up in my own organization or in the customer's organization whose preconceived opinions were based on rumor and what they've heard rather than actual factual hands-on experience.  I want to pick the best tool for the job instead of being forced to pick an inferior tool because someone higher in the food chain demanded it based on faulty preconceived opinion.  I like Modula-3.  I've found that I am more productive using it.  But, if the compiler doesn't produce efficient code, I lose ground in arguing with the higher-ups.

As for Python, I've never ventured to learn it, so for me, it is something of a mystery.  But you miss the point.  I'm not arguing the merits of Python, I'm just saying that anything Modula-3 requires on top of what is provided by the standard host platform represents a potential obstacle or barrier to ease of use/implementation.  It also sends the message that somehow Modula-3 is not complete on its own, we have get Python just to install and oh yes we need a C compiler and a linker and a ...?   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, I can run it on Windows, but if you give me an install routine that requires I first install something else, e.g. Python, then that becomes a barrier to the folks who don't know Python or already have it installed.

Am I alone in this line of thought?  If so, I'll just be quiet.

BTW, I can certainly help in maintaining the CMD/BAT install routines or in making a better CMINSTALL.  My problem is that right now, it is hard to understand all the dependencies for proper building of cm3 from scratch.  Indeed, I've contributed some CMD/BAT install stuff in the past, but it is now out of date.  Perhaps if there is a way we could better document the proper build order and dependencies, it would be easier for folks in the community to help in this area.  I certainly would volunteer to do the CMD files as long as I had enough information to do it right.  At one point, I thought we had a file that showed the package build order and dependencies.  Not sure if the format of this file is well-documented or if the file is kept up-to-date.

Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 12/31/2008 1:34 PM >>>
 > you've made the CYGWIN implementation "appear" 
 > be the same as the native Windows implementation.
 > But they are not the same.

But they mostly are, from the front end's point of view.
They are both little endian, x86, use the same jump_buf size (I grew it to match Cygwin's, which is a deoptimization of stack use on native NT386), the same type sizes and alignments..er..not sure about LONGINT.
They might vary in newline and one uses the internal backend and one the external, however which backend they use is actually minor to the front end, though I think it affects if the front end "deals with" calling conventions, particularly left-to-right vs. right-to-left and struct returns.
Object code produced by one can generally be linked with object code produced by the other.

SOLgnu and SOLsun are a better example of this, though they do go ahead and duplicate tons of stuff that if I had implemented them, I would have avoided.
They are truly identical in every respect in the front end and back end.
They only vary in the config file.
This is wasteful, because, "by default", if I'm put together a comprehensive cross build system without being a little smarter, I end up building two identical m3cgs. My config files are willing to "probe across" SOLsun and SOLgnu though, so I need only one m3cg for the two of them.

Given that "NT386" can describe a combinatorial explosion of configurations, it makes some sense to keep it just one if possible. The compiler mostly doesn't care.

 > "- BUILD_DIR does not necessarily equal HOST or TARGET, 
 > because of how I structured I386_CYGWIN to be a "configuration" 
 > where TARGET is still NT386." 
  > IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET".  

BUILD_DIR also does not equal HOST or TARGET when doing profiled builds, which admittedly I never have.
Therefore, BUILD_DIR is arbitrary.
I might be confusing something here though -- since I have never built a profiled build, I also haven't shipped one. It could be that "shipped BUILD_DIR" does equal TARGET, for profiled builds, in which case I did set a precedent. But the "override" code isn't using shipped files, so..
I have to check.

 > as long as it does not compromise the native Windows implementation

Agreed and it basically doesn't.
Show me where it does.
The only thing I can think of is the jmpbuf size.

 >  I don't want to have to install CYGWIN either in order to make
 > the native implementation work on Windows.

Please don't complain about stuff that isn't true or without being more specific.
I know of no dependency by the native implementation on Cygwin.

In fact, installing Cygwin does tend to break the native implementation, depending on $PATH, because it has a link.exe that is a completely different program (ie: ln.exe).
I tried experimenting with using cl to drive link.exe but couldn't quite get it to work, for stupid reasons related to response files, which surely is fixable by extending response file support in cm3...

As it is, I usually delete \cygwin\bin\link.exe, or remove cygwin from $PATH.
True, I don't ever uninstall Cygwin for testing, so the dependency could creep in by accident.

 >  I also still prefer the CMINSTALL, CMD, or BAT files
 > for install as opposed to having to get Python or something else.  Just my 2 cents.

Once built and installed, there is no dependency on cmd, bat, cminstall, or python.
cminstall is pretty worthless imho, as long as you set PATH, INCLUDE, and LIB.
That is also a competing workaround for paths with spaces.
And allows moving around among different versions of Visual C++, which is good and bad.
  Either you can have n installs of cm3, each configured tightly for one specific Visual C++,
  or you can have 1 install of cm3, that is flexibly configured, that you "reconfigure" by altering the environment. I do the second.

If you want to build the system, in a well automated way, with cmd and bat, you are welcome to write them.
  Maybe the ones I left in the tree work, but i never use them any longer.
  I use the Python all the time.

Or you can manually cd around (as I suspect Tony does).
Personally I find cmd/bat among the worst programming languages ever and would rather not write it.
jscript via cscript.exe would be a good alternative, it is always there at least as of Windows 2000 or perhaps with IE installed on older versions, but then you have to duplicate work across Unix and Windows.
That is, for Windows-only no-cmd, no-install command line automation, JScript and VBScript are good choices, but Windows-only rules them out. The install is worth it.
Python is a very decent programming language that is very portable across "all" systems.
Perl would be the next best choice, though..I just don't like much.
sh/bash requires an install on Windows, so its built-inness on Posix I claim isn't a conclusive win.
I strongly encourage you to try out Python.

Another avenue is to merge the sh/cmd/python into cm3 itself.
It shouldn't be all that hard.

Modula-3 still needs a C linker.
And there is C code that I didn't put in -- hand.c and dtoa.c.
If someone writes a linker in Modula-3, or gets the .obj loader working, I'll be more open to eliminating C.

But using C is much less error prone and much more portable, in some parts of the system.

You may label C as "evil", but the other "evil" I am battling is tedious error prone "header cloning".
You pretty much must chose one.
The header cloning can be reduced, and its error proned-ness and difficulty various per system, depending on how gnarled up the headers are with ifdefs, compatibility hacks, processor-specificty, "cleansing" (where the installed headers are processor specific, deriving from #ifdef'ed or somesuch other files, but now I argue both sides, #ifdef is hard to read, but removing them removes information unless you track further back), etc. For example the OpenBSD headers are much more readable. I suspect NetBSD are too but haven't looked yet. The Linux headers contain a lot of #ifdef and they are also processor-specific I think -- you know, my /usr/include/errno.h on one system I think didn't show that x86 and SPARC use different values.

 - Jay

Date: Wed, 31 Dec 2008 10:28:37 -0500
From: rcoleburn at scires.com 
To: m3devel at elegosoft.com 
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Jay:

Please explain what you mean by: 

"- BUILD_DIR does not necessarily equal HOST or TARGET,
because of how I structured I386_CYGWIN to be a "configuration"
where TARGET is still NT386."

IMO, it would be wrong to change the meaning of things like "BUILD_DIR", "HOST", and "TARGET".  Indeed, I have stuff that depends on the meaning of these things.  Your statement seems to imply that "under the covers" you've made the CYGWIN implementation "appear" to be the same as the native Windows implementation.  But they are not the same.

On another note, All this CYGWIN stuff may be a nice way for die-hard Unix fans to run Modula-3 on Windows, and I have no objection to providing it, as long as it does not compromise the native Windows implementation.  My main concern is the native implementation of Modula-3 on Windows.  My preference would be to keep the NT386 implementation's dependencies on other stuff to a bare minimum, i.e., don't introduce anything that would require someone to have to acquire something besides what comes in the standard Windows OS in order to make Modula-3 run.  As it is now, we already have to get a C compiler and linker.  Fortunately, Microsoft has made the Visual Studio Express editions a free download, so this is not too bad.  I don't want to have to install CYGWIN either in order to make the native implementation work on Windows.  I also still prefer the CMINSTALL, CMD, or BAT files for install as opposed to having to get Python or something else.  Just my 2 cents.

Finally, I would go a step further and suggest that the Modula-3 implementation on every platform should strive to require minimal dependencies on anything not provided standard with that platform's operating system.

Call me an idealist, but it just galls me that I have to have a C compiler/linker to build Modula-3.  Modula-3 is a systems programming language.  It should stand on its own.  From a purely economical viewpoint, why should I have to buy something I don't want (C language development environment) in order to have the privilege of using what I do want (Modula-3 language development environment).

Regards,
Randy

>>> Jay Krell <jkrell at elego.de> 12/31/2008 11:52 AM >>>
CVSROOT:/usr/cvs
Changes by:jkrell at birch.08/12/31 11:52:08

Modified files:
cm3/m3-comm/netobj/src/: netobj-ov.tmpl 
cm3/m3-comm/sharedobj/src/: sharedobj-ov.tmpl 
cm3/m3-libs/libm3/src/bundleintf/: bundle-ov.tmpl 
cm3/m3-ui/zeus/src/: m3zume-ov.tmpl 
cm3/m3-ui/juno-2/juno-app/src/: m3makefile 

Log message:
Partly kinda sorta fix some cross build scenarios, without
affecting native builds.

It's a larger more general problem though.

- BUILD_DIR does not necessarily equal HOST or TARGET,
because of how I structured I386_CYGWIN to be a "configuration"
where TARGET is still NT386.

- a cross build can run the shipped binary anyway,
and probably should (I didn't have the unshipped binaries around)

- There should probably be automation to ensure all the tools are build.
ie: do-cm3-tools or do-cm3-crosstools. ie: build just the needed packages,
for the sniffed native platform.

Cross builds have other problems.

I keep hitting the following annoyances:

ignoring foo/bar override when foo\bar already overridden
override paths should either be canonicalized to one slash type
or at least when there is a duplicate, canonicalize then and only
complain if canonicals vary
This is due to mixing I386_NT and I386_CYGWIN.
Similarly the problem demonstrated regarding m3unix.h in Uwaitpid.quake.

Perhaps the change I made to allow forward slashes on Win32 was not good, esp. due to
its apparent inadequacy.

The "lib" directory, specifically \cm3\lib\hand.obj is target..er, configuration dependent
the gcc hand.obj cannot be directly linked by Visual C++, for reasons to do with libgcc

lib should probably have "target" or "build_dir" under it

and/or hand.obj specifically should be merged into m3core.lib

The mentor quake code generally fails in cross environments, probably due to slashes.

host=NT386 (GNU?), target=LINUXLIBC6 m3zume is access violating

I'm also highly suspicious of all this "override" stuff.
It clearly causes too much duplication and distribution of information.
I shouldn't have to know the directory structure of my dependencies,
and even if I do, I should be able to share that knowledge with their many
other dependents. The "scripts" directory also figures this sort of stuff out automatically..
Being able to have multiple package stores is well and good.
I'm not sure they need to ever be used in an "unshipped" form, but instead just
use alternate roots and create new empty roots as needed. ?

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