<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">Historically, there have been non-gcc-based backends. We would not want to preclude those.</span></div></span> </div><br><div><div>On 17 Jan 2009, at 00:05, Jay wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">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. :)<span class="Apple-converted-space"> </span><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. :)<span class="Apple-converted-space"> </span><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.<span class="Apple-converted-space"> </span><br> You could imagine something like M3Try allocating the same..but this seems bad.<span class="Apple-converted-space"> </span><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></span></blockquote></div><br></body></html>