[M3devel] arbitrary use of LONGINT for testing? target/ABI alteration/generation via command line?

[Tony Hosking]

Let's not right now. We need to get the release out. I suggest a  
freeze on compiler changes for now.  Bug fixes only!

Sent from my iPhone

On Mar 15, 2010, at 7:54 PM, Jay K <jay.krell at cornell.edu> wrote:

> Tony et. al. I'm wondering/fishing if you any ideas, like a cm3  
> command line switch, that might be used to make INTEGER 64bits to  
> increase coverage/testing of 64bit integer support.
>
>
> The problem is *at least* interfacing with external code/files, if  
> not breaking everything.
>   Maybe also a problem around sizeof(INTEGER) vs. sizeof(ADDRESS).
>   Probably such a setting would grow ADDRESS too.
>
>
> Like, maybe stuff like m3core/unix, m3core/win32 should never use  
> plain INTEGER or LONGINT, but "BITS FOR", to allow this to work? Or  
> maybe <* EXTERNAL *> would be the hint?
>   No, <* EXTERNAL *> isn't adequate, due to the case of callbacks.
>
>
> I'd like to somehow, without too much effort, significantly increase  
> testing of LONGINT.
>
>
> Maybe a wierdo platform NT386_64 that does this just for test  
> purposes?
> I might try that, if "BITS FOR" is enough to actually let it work  
> (interface with C).
>  (or generally, cm3 -test64 would append "_TEST64" to target name,  
> so we could have LINUXLIBC6_TEST64, I386_DARWIN_TEST64, etc.)
>
>
> I can do some initial experiments along this -test64 line, see if it  
> completely blows up or not.
>  A few minutes thought suggests it should work easily and provide  
> value.
>
>
> (There's probably something similar to try around a 16 bit CHAR. vs.  
> BITS 8 FOR CHAR, but I'm not going there..)
>
>
> Such command line driven target/ABI alterations seem like a somewhat  
> good idea.
> e.g. cm3 -userthreads would append _USERTHREADS.
> cm3 -extended80 would use an 80 or 96 bit extended on x86 (96 bits  
> for alignment).
>   -extended128 on ppc
>   etc.
>
>
> cm3 -msvc80 could probe around in enviroment for a Visual C++ 8.0  
> compiler/linker/header/libraries and append "_MSVC80" to target,  
> else fail.
>
>
> I'll just try -test64 for now.
> The rest aren't as immediately useful.
>   -userthreads would be my next "favorate".
>
> Hm. Instead of -test64, how about -64.
> If integer is 32 bits, change it to 64 and append _64 (and address).
> If integer is already 64bits, do nothing.
>
>
> This is quite different than gcc's -m64 though.
>  Maybe not good that way.
>
>
> You can see parallels in several older C compilers.
>
> Metrowerks for Mac/68K let you chose integer size and either double  
> or extended size (I forget which).
> That gave you a cross product set of ABIs, each with their own  
> libraries.
>
>
> Similarly you could chose to issue FPU instructions directly, which  
> might have altered the ABI, or maybe the alternate libraries were  
> just faster.
>
>
> Similarly Microsoft and memory models. Various switches changed the  
> size of a pointer and implied a need for different libraries.
>
>
> Current gcc and ppc floating point sizes I believe is a contemporary  
> example.
>  Even sometimes the affect that -pthread has -- chosing different  
> libraries (unnecessary
> mess imho, but one that seems to persist on HP-UX.)
>
>
> It's kind of an ugly area, to offer too many choices, produces  
> confusion, but the limited important goal of increasing 64bit  
> integer testing seems worth going here. And increasing userthread  
> testing. People have expressed an interest in higher precision  
> floating point, esp. 80 bit on x86, so this maybe a good way to  
> proceed there also.
> You could also imagine flags -SSE, -SSE2, etc.
>
>
> It is important to only support a very limited number of these flags.
>  Large cross products are not fun to worry about and test.
>  But for example, with SSE, that nets you several targets all at  
> once, without per-target work.
>
> (I lose the term "SSE" loosely. Could be I mean "SSE2" or 3 --  
> whatever is sufficient to largely replace the stack based x87.)
>
>
>  - Jay