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

[Tony Hosking]

There were BURS backends too.

And C is not good for source-level debugging.


On 17 Jan 2009, at 22:36, Jay wrote:

>
> 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
>>
>>