<HTML><HEAD>
<STYLE>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</STYLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV>Jay:</DIV>
<DIV> </DIV>
<DIV>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. </DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Randy<BR><BR>>>> Jay <jay.krell@cornell.edu> 1/16/2009 8:05 AM >>><BR>Would people mind "new" ports like:<BR> <BR><BR>HPPA32_HPUX (HPPA_HPUX? There is "HPPA")<BR>I386_FREEBSD (There is FreeBSD4.)<BR>I386_NETBSD (There is NetBSD2_i386.)<BR>MIPS32_IRIX (MIPS_IRIX? There is IRIX5.)<BR>ALPHA_FREEBSD (There FBSD_ALPHA.)<BR>and then for that matter:<BR>SPARC32_SOLARIS, I386_LINUX<BR> <BR><BR>Or some mix?<BR>This is not hypothetical. I do now have HPPA, Alpha, SGI hardware. :) <BR> <BR> <BR>I can either do the little bit of correct testable valid small etc. work<BR>of using my "more portable" approach to these platforms, which<BR>gets things up and running easily and fast and perfectly acceptably,<BR>or I could "proofread" all the gunk, I mean cloned headers, fix them<BR>for current system, worry if they break old system, or delete them,<BR>possibly doing some hypothetical damage to the old ports.<BR> <BR> <BR>It seems easier and a better result to "start over" and leave the old stuff alone,<BR>maybe delete it, depending on what people think of history preservation and<BR>history vs. deletes (deleted stuff isn't very visible).<BR> <BR> <BR>Or maybe hardly any of this matters. Nobody uses these platforms or anything like them?<BR>(I recall Randy saying he is still using 4.1 on HP-UX though. I'm on a fun little<BR>long running errand here of getting not ancient but not current systems.. :) )<BR> <BR><BR>The "4", "2", "5" in FreeBSD4, NetBSD2_i386, IRIX5 make them seen somewhat "wrong".<BR> <BR><BR>The "4" in FreeBSD4 (err, in i686-freebsd4) does have a surprising semantic, in the backend..but maybe not.<BR> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(53): builtin_define_with_int_value ("__FreeBSD__", FBSD_MAJOR); \<BR> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(122):#if FBSD_MAJOR < 5<BR> C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\config\freebsd-spec.h(141):#if FBSD_MAJOR < 6<BR> <BR><BR>though I think if you look closely, these don't matter to us.<BR>They affect the gcc driver and the C/C++ front end, but maybe not the m3cg backend.<BR> <BR> <BR>Even the "LIBC6" in "LINUXLIBC6" seems dubious, because, for example, I am<BR>tempted to make "ARM_LINUX_UCLIBC", which suggests either that<BR>there might be an "I386_LINUX_UCLIBC" or "generic" "I386_LINUX" that<BR>is portable across libc6/uclibc/dietlibc/newlib either by seeing<BR>what they have in common, or skipping them and using the kernel interfaces<BR>more directly.<BR> <BR><BR>There is another angle here.<BR>To what extent is the compiler platform specific?<BR> (I mostly know the answer to this. It is a leading question.)<BR>Could ports go away?<BR>Almost?<BR> <BR><BR>Historically there were a bunch of platform-specific .i3 files.<BR>That is dwindling much in some platforms and could dwindle much overall.<BR>A little more C code in the system and the Modula-3 .i3 files are all "portable".<BR> <BR><BR>It ends up being, roughly, that there is:<BR> <BR><BR> endian, and even this is often not an issue; I saw like<BR> one reference in the compiler to it, and there is a little bit in m3core/libm3<BR> The byte swap functions and maybe the Float stuff (there is endian specific<BR> and generic stuff, not all is used).<BR> It would affect e.g. the layout of the Uexec types, but they are gone.<BR> Such endian-specificity could occur anywhere but maybe "cm3 -generic" errors for it?<BR> <BR><BR> word size -- 32bit or 64bit. There is no escaping this, as long as there are any 32bit platforms.<BR> So ok, two ports, 32bit and 64bit. That's a small matrix.<BR> <BR><BR> IEEE or not -- everything is IEEE now. I don't plan on getting a VAX. :) <BR> (The compiler seems suspicious here wrt cross building.)<BR> <BR><BR> The name of setjmp.<BR> However this could be made the same everywhere -- m3_setjmp or M3Try or M3SaveState,<BR> and use an #ifdef .c file to decide.<BR> <BR><BR> The size of the jmpbuf. Ah, there's the rub.<BR> A "generic" platform could blow up the size of the jmpbuf to something that works<BR> on all known platforms. Very very wasteful. Some platforms have tiny, some have huge.<BR> <BR><BR> I'm not sure where stack layout is done. If the front end does it or not. <BR> You could imagine something like M3Try allocating the same..but this seems bad. <BR> If the front end defers enough work to the backend, you could introduce an abstracted<BR> notion of the jmpbuf and leave it to m3cg to fill in? Leave it to #ifdef on the target?<BR> m3cg, in its current form as gcc based is always going to have be configured to be<BR> target specific.<BR> <BR> <BR> Or all platforms could have stack walkers and this platform-specificity would go away.<BR> But that is a very long ways off, if ever.<BR> <BR><BR> My point is, you know, can we in fact eliminate the notion of porting?<BR> At least of cm3 knowing anything about the target, and only m3cg?<BR> Because the system is nearly portable enough? All that is left is configuring gcc?<BR> It seems very close to possible.<BR> <BR><BR>Like, "have gcc, will travel"?<BR>And nothing else changes?<BR>No value then in doing any porting work up front?<BR> <BR><BR>You know..think of the author of hello world..some highly portable program.<BR> Or more realistic example such as bash, awk, make, ld and gcc on a particular host (not target), etc.<BR>They don't go around much and port to this or that or the other system.<BR> They do a mix of "just try to be portable" and "leave autoconf to figure out".<BR> <BR><BR>Modula-3 is almost in the same boat?<BR> <BR> <BR> - Jay<BR><BR></DIV></BODY></HTML>