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

[Jay K]

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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100316/485e31b3/attachment-0001.html>