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

[Tony Hosking]

Historically, there have been non-gcc-based backends.  We would not  
want to preclude those.

On 17 Jan 2009, at 00:05, Jay wrote:

> 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/20090117/b4eed2f9/attachment-0002.html>