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

[Jay]

Ah -- you mean if there more integrated backends written in Modula-3, then it would become "impossible" to push such knowledge of the target as its processor, endianness, etc. out of cm3?
Or rather, it would be /possible/, but it would be counterproductive.
That makes sense. Good point.
But that could be added back.
 
 
 if platform = "nt386" 
   UseIntegratedBackend(); 
 else if ... 
   ...  
 else 
   gcc backend handles it (almost) all ? 
 
 
No need, perhaps, for a big enum and switch.
Just about.
 
 
You know..as it stands..cm3 knows just a little about each target, and it doesn't even use all it knows kinda. Word size it uses in computing layout. Endianness it uses rarely I think. "aligned procedures" it uses in about one place. Some of the data in Target.i3 was unused and I removed it. I guess nevermind. I'm just thinking about, you know, declaring all ports either done, or so trivial that there is little point in doing one until someone needs it, merely tedium. That isn't actually the case yet -- there should be C program(s) to generate the "residue", Usysdep.i3, Csetjmp.i3, etc.
 
 
The other backends are the NT386 one, and it adapted to Linux/x86, right?
And maybe what used to generate C?
(Can someone give me details as to why C generation isn't a great idea?)
 
 
 - Jay



________________________________
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] "new old" ports, or no ports at all?
> Date: Sat, 17 Jan 2009 22:03:19 +1100
>
> 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
>
>