[M3devel] release status [was something else]

[Tony Hosking]

On 15 Mar 2010, at 21:41, Jay K wrote:

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

If anyone gets a snapshot please also make sure to get a backtrace for all the 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.

Those changes will need bringing over from head to release if Jay's m3back 64-bit support for NT386 are also brought over.  I believe there are a few dependencies.

>   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/9529d2a5/attachment-0002.html>