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

[Jay]

I assume they can run 64bit?
My system can/is.
I have to research if 1.1 is 32bit, 2.0 is 64bit, or if there is a larger matrix.
 
 
Any preference among "HPPA64_HPUX" vs. "PA64_HPUX" -- the double "HP" is kind of redundant.
 The minimum gcc configuration names I found to work are hppa64-hpux11 and presumably hppa-hpux11. The major version is required, else configure errors out "unsupported".
 
 
Similarly: reusing existing "HPPA" or introduce "HPPA32_HPUX" or "PA32_HPUX"?
My inclination is PA32_HPUX, PA64_HPUX, but any is ok.
"PA" is shorter, but "HPPA64" is not record settingly long -- we have "SPARC64", and "SPARC32" that I introduced.
 
 
The names will then apply to *_LINUX as well.
 
 
Also you must have GNU as for this port.
m3cc/src/m3makefile indicates that was already the case for the old HPPA.
gcc 3.3.6 is ok with the HP assembler, though I don't remember if -g worked.
But gcc 4.3.2 is not ok with the HP assembler.
 
 
 - Jay

________________________________
> Date: Fri, 16 Jan 2009 11:04:53 -0500
> From: rcoleburn at scires.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] "new old" ports, or no ports at all?
>
>
>
>
>
>
>
>
>
> 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 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
>