<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
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></body>
</html>