[M3devel] "new old" ports, or no ports at all?

[Randy Coleburn]

Jay:
 
I do have some HP-UX machines that I could use to test whatever you come up with for HPPA.  You are correct that right now I run cm3 v4.1 on these.  I have not tried to move beyond 4.1 on them yet.  
 
Regards,
Randy

>>> Jay <jay.krell at cornell.edu> 1/16/2009 8:05 AM >>>
Would people mind "new" ports like:
 

HPPA32_HPUX (HPPA_HPUX? There is "HPPA")
I386_FREEBSD (There is FreeBSD4.)
I386_NETBSD (There is NetBSD2_i386.)
MIPS32_IRIX (MIPS_IRIX? There is IRIX5.)
ALPHA_FREEBSD (There FBSD_ALPHA.)
and then for that matter:
SPARC32_SOLARIS, I386_LINUX
 

Or some mix?
This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) 
 
 
I can either do the little bit of correct testable valid small etc. work
of using my "more portable" approach to these platforms, which
gets things up and running easily and fast and perfectly acceptably,
or I could "proofread" all the gunk, I mean cloned headers, fix them
for current system, worry if they break old system, or delete them,
possibly doing some hypothetical damage to the old ports.
 
 
It seems easier and a better result to "start over" and leave the old stuff alone,
maybe delete it, depending on what people think of history preservation and
history vs. deletes (deleted stuff isn't very visible).
 
 
Or maybe hardly any of this matters. Nobody uses these platforms or anything like them?
(I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little
long running errand here of getting not ancient but not current systems.. :) )
 

The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong".
 

The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not.
 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \
 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5
 C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6
 

though I think if you look closely, these don't matter to us.
They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend.
 
 
Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am
tempted to make "ARM_LINUX_UCLIBC", which suggests either that
there might be an "I386_LINUX_UCLIBC" or  "generic" "I386_LINUX" that
is portable across libc6/uclibc/dietlibc/newlib either by seeing
what they have in common, or skipping them and using the kernel interfaces
more directly.
 

There is another angle here.
To what extent is the compiler platform specific?
  (I mostly know the answer to this. It is a leading question.)
Could ports go away?
Almost?
 

Historically there were a bunch of platform-specific .i3 files.
That is dwindling much in some platforms and could dwindle much overall.
A little more C code in the system and the Modula-3 .i3 files are all "portable".
 

It ends up being, roughly, that there is:
 

  endian, and even this is often not an issue; I saw like
   one reference in the compiler to it, and there is a little bit in m3core/libm3
    The byte swap functions and maybe the Float stuff (there is endian specific
    and generic stuff, not all is used).
  It would affect e.g. the layout of the Uexec types, but they are gone.
  Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it?
 

  word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms.
  So ok, two ports, 32bit and 64bit. That's a small matrix.
 

  IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) 
   (The compiler seems suspicious here wrt cross building.)
 

  The name of setjmp.
  However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState,
  and use an #ifdef .c file to decide.
 

  The size of the jmpbuf. Ah, there's the rub.
  A "generic" platform could blow up the size of the jmpbuf to something that works
   on all known platforms. Very very wasteful. Some platforms have tiny, some have huge.
 

  I'm not sure where stack layout is done. If the front end does it or not. 
  You could imagine something like M3Try allocating the same..but this seems bad. 
  If the front end defers enough work to the backend, you could introduce an abstracted
   notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target?
   m3cg, in its current form as gcc based is always going to have be configured to be
   target specific.
 
 
  Or all platforms could have stack walkers and this platform-specificity would go away.
   But that is a very long ways off, if ever.
 

 My point is, you know, can we in fact eliminate the notion of porting?
   At least of cm3 knowing anything about the target, and only m3cg?
  Because the system is nearly portable enough? All that is left is configuring gcc?
  It seems very close to possible.
 

Like, "have gcc, will travel"?
And nothing else changes?
No value then in doing any porting work up front?
 

You know..think of the author of hello world..some highly portable program.
  Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc.
They don't go around much and port to this or that or the other system.
  They do a mix of "just try to be portable" and "leave autoconf to figure out".
 

Modula-3 is almost in the same boat?
 
 
 - Jay

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