[M3devel] release status [was something else]

[Jay K]

Release status as far as I know:

 

 - cvsupd hang

   Reported over a year ago. Needs investigation.

   Can anyone confirm it with a recent version?

   And, as Tony asked, with user threads?

 

 

 - NT386 has no 64bit longint in release branch. Partly the point of this question.

 

 

 - Should maybe improve build/packaging to get NT386-VC80.msi, NT386-VC90.msi etc. (not the same as "target/abi alteration via command line" expressed below, though that is a possibility, but separate clean builds for now and/or separate CVS checkouts); really more of a Hudson task now, to have multiple build environments installed and used, I think I already updated the .msi building to append the tag. Olaf?

 

 

 - I believe there is "new" divergence in m3front between head and release -- whatever came along with the TInt changes.

 

 

Otherwise I'd have to look through trac.

 

 

There's maybe some stuff not merged from release to head, but that's ok for release.

  (I need to check which branch Randy fixed the examples in.)

I need to re-test the .msis.

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: [M3devel] arbitrary use of LONGINT for testing? target/ABI alteration/generation via command line?
> Date: Mon, 15 Mar 2010 20:00:27 -0500
> CC: m3devel at elegosoft.com
> 
> 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100316/a66ba86a/attachment-0002.html>