<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Release status as far as I know:<BR>
<BR>
- cvsupd hang<BR>
Reported over a year ago. Needs investigation.<BR>
Can anyone confirm it with a recent version?<BR>
And, as Tony asked, with user threads?<BR>
<BR>
<BR>
- NT386 has no 64bit longint in release branch. Partly the point of this question.<BR>
<BR>
<BR>
- 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?<BR>
<BR>
<BR>
- I believe there is "new" divergence in m3front between head and release -- whatever came along with the TInt changes.<BR>
<BR>
<BR>
Otherwise I'd have to look through trac.<BR>
<BR>
<BR>
There's maybe some stuff not merged from release to head, but that's ok for release.<BR>
(I need to check which branch Randy fixed the examples in.)<BR>
I need to re-test the .msis.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> From: hosking@cs.purdue.edu<BR>> To: jay.krell@cornell.edu<BR>> Subject: Re: [M3devel] arbitrary use of LONGINT for testing? target/ABI alteration/generation via command line?<BR>> Date: Mon, 15 Mar 2010 20:00:27 -0500<BR>> CC: m3devel@elegosoft.com<BR>> <BR>> Let's not right now. We need to get the release out. I suggest a <BR>> freeze on compiler changes for now. Bug fixes only!<BR>> <BR>> Sent from my iPhone<BR>> <BR>> On Mar 15, 2010, at 7:54 PM, Jay K <jay.krell@cornell.edu> wrote:<BR>> <BR>> > Tony et. al. I'm wondering/fishing if you any ideas, like a cm3 <BR>> > command line switch, that might be used to make INTEGER 64bits to <BR>> > increase coverage/testing of 64bit integer support.<BR>> ><BR>> ><BR>> > The problem is *at least* interfacing with external code/files, if <BR>> > not breaking everything.<BR>> > Maybe also a problem around sizeof(INTEGER) vs. sizeof(ADDRESS).<BR>> > Probably such a setting would grow ADDRESS too.<BR>> ><BR>> ><BR>> > Like, maybe stuff like m3core/unix, m3core/win32 should never use <BR>> > plain INTEGER or LONGINT, but "BITS FOR", to allow this to work? Or <BR>> > maybe <* EXTERNAL *> would be the hint?<BR>> > No, <* EXTERNAL *> isn't adequate, due to the case of callbacks.<BR>> ><BR>> ><BR>> > I'd like to somehow, without too much effort, significantly increase <BR>> > testing of LONGINT.<BR>> ><BR>> ><BR>> > Maybe a wierdo platform NT386_64 that does this just for test <BR>> > purposes?<BR>> > I might try that, if "BITS FOR" is enough to actually let it work <BR>> > (interface with C).<BR>> > (or generally, cm3 -test64 would append "_TEST64" to target name, <BR>> > so we could have LINUXLIBC6_TEST64, I386_DARWIN_TEST64, etc.)<BR>> ><BR>> ><BR>> > I can do some initial experiments along this -test64 line, see if it <BR>> > completely blows up or not.<BR>> > A few minutes thought suggests it should work easily and provide <BR>> > value.<BR>> ><BR>> ><BR>> > (There's probably something similar to try around a 16 bit CHAR. vs. <BR>> > BITS 8 FOR CHAR, but I'm not going there..)<BR>> ><BR>> ><BR>> > Such command line driven target/ABI alterations seem like a somewhat <BR>> > good idea.<BR>> > e.g. cm3 -userthreads would append _USERTHREADS.<BR>> > cm3 -extended80 would use an 80 or 96 bit extended on x86 (96 bits <BR>> > for alignment).<BR>> > -extended128 on ppc<BR>> > etc.<BR>> ><BR>> ><BR>> > cm3 -msvc80 could probe around in enviroment for a Visual C++ 8.0 <BR>> > compiler/linker/header/libraries and append "_MSVC80" to target, <BR>> > else fail.<BR>> ><BR>> ><BR>> > I'll just try -test64 for now.<BR>> > The rest aren't as immediately useful.<BR>> > -userthreads would be my next "favorate".<BR>> ><BR>> > Hm. Instead of -test64, how about -64.<BR>> > If integer is 32 bits, change it to 64 and append _64 (and address).<BR>> > If integer is already 64bits, do nothing.<BR>> ><BR>> ><BR>> > This is quite different than gcc's -m64 though.<BR>> > Maybe not good that way.<BR>> ><BR>> ><BR>> > You can see parallels in several older C compilers.<BR>> ><BR>> > Metrowerks for Mac/68K let you chose integer size and either double <BR>> > or extended size (I forget which).<BR>> > That gave you a cross product set of ABIs, each with their own <BR>> > libraries.<BR>> ><BR>> ><BR>> > Similarly you could chose to issue FPU instructions directly, which <BR>> > might have altered the ABI, or maybe the alternate libraries were <BR>> > just faster.<BR>> ><BR>> ><BR>> > Similarly Microsoft and memory models. Various switches changed the <BR>> > size of a pointer and implied a need for different libraries.<BR>> ><BR>> ><BR>> > Current gcc and ppc floating point sizes I believe is a contemporary <BR>> > example.<BR>> > Even sometimes the affect that -pthread has -- chosing different <BR>> > libraries (unnecessary<BR>> > mess imho, but one that seems to persist on HP-UX.)<BR>> ><BR>> ><BR>> > It's kind of an ugly area, to offer too many choices, produces <BR>> > confusion, but the limited important goal of increasing 64bit <BR>> > integer testing seems worth going here. And increasing userthread <BR>> > testing. People have expressed an interest in higher precision <BR>> > floating point, esp. 80 bit on x86, so this maybe a good way to <BR>> > proceed there also.<BR>> > You could also imagine flags -SSE, -SSE2, etc.<BR>> ><BR>> ><BR>> > It is important to only support a very limited number of these flags.<BR>> > Large cross products are not fun to worry about and test.<BR>> > But for example, with SSE, that nets you several targets all at <BR>> > once, without per-target work.<BR>> ><BR>> > (I lose the term "SSE" loosely. Could be I mean "SSE2" or 3 -- <BR>> > whatever is sufficient to largely replace the stack based x87.)<BR>> ><BR>> ><BR>> > - Jay<BR> </body>
</html>