<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>No.<BR>
<BR>
(I fully admit I don't know yet what the problem is, and the way the system is designed in my understanding, variations like this are "impossible", therefore throw out nearly all expectations and entertain nearly all ideas, but I don't think this is related. It'll just have to be debugged and code studied and skimmed for hints, and I apologize for the long delay. Maybe some code checks for function equality?? (not sure Modula-3 even supports that, but it's one the small subtleties of dynamic linking that can trip up some unusual slightly sleazy C code))<BR>
<BR>
- Jay<BR><BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Fri, 1 Feb 2008 20:08:59 -0500<BR>From: rcoleburn@scires.com<BR>To: hosking@cs.purdue.edu; jayk123@hotmail.com<BR>CC: hosking@elego.de; m3devel@elegosoft.com<BR>Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR><BR>
<META content="Microsoft SafeHTML" name=Generator>
<DIV>Hey Jay, do you suppose this may have some explanation for why pixmaps only work on NT386 when buildstandalone() is given?</DIV>
<DIV>--Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 2/1/2008 8:02 PM >>><BR>"I386_LINUX"? You aren't off renaming platforms now are you Tony? :)<BR>Agreed. I stopped looking when I noticed the license..<BR>Aha..I guess that is the point of the two "integrated" x86 backends?<BR>There's just one code base, there there is m3back and m3staloneback. One builds a .lib, one builds an .exe.<BR>The .exe probably reads the binary file and then replays the function calls..it's marshaling layer and all that...<BR>You can move the code around to avoid spreading the license and all that..<BR> <BR> <BR> - Jay<BR><BR></DIV>
<DIV>
<HR id=EC_stopSpelling>
</DIV>
<DIV><BR>> CC: hosking@elego.de; m3devel@elegosoft.com<BR>> From: hosking@cs.purdue.edu<BR>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR>> Date: Fri, 1 Feb 2008 19:56:18 -0500<BR>> To: jayk123@hotmail.com<BR>> <BR>> It would be nice to have the x86 integrated backend for I386_LINUX <BR>> and LINUXLIBC6 too -- just like the old PM3 did.<BR>> <BR>> On Feb 1, 2008, at 7:45 PM, Jay wrote:<BR>> <BR>> > Hey, I'd kind of like that backend to stay actually. It's quite <BR>> > fast and generates better code than unoptimized gcc and competitive <BR>> > code with optimized gcc. There's no AMD64 support anywhere yet in <BR>> > Modula-3 that I know of. Maybe it will appear here first? :)<BR>> ><BR>> > I don't think it is all that gnarly either. But somewhat. It's a <BR>> > bit like code I've see that is so often handling one case after <BR>> > another case after yet another case, yet who knows what all the <BR>> > cases are and which order (if any particular) they should be <BR>> > handled in? That is, it's actually kind of easier to read it and <BR>> > understand what it does do, and realize that is "correct" in the <BR>> > "necessary" sense, but hard to know if it is "sufficient".<BR>> > I've got outstanding diffs for int64 support I'd like to get back to.<BR>> ><BR>> > AMD64 shouldn't be difficult...that's kind of the point, eh?<BR>> > It's just a slight alteration of x86..<BR>> ><BR>> > Granted, it isn't set up, doesn't have a "framework", to generate <BR>> > substantially better code.<BR>> > It doesn't remember much, doesn't make multiple passes, doesn't <BR>> > have a high level representation, etc.<BR>> ><BR>> > In the unlikely event that I succeed, presumably PPC would be <BR>> > next...:)<BR>> ><BR>> > (But yeah yeah, LLVM is probably easier and much more fruitful, <BR>> > both in terms of platform each and optimization..and hopefully <BR>> > build speed.)<BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> > > CC: hosking@elego.de; m3devel@elegosoft.com<BR>> > > From: hosking@cs.purdue.edu<BR>> > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR>> > > Date: Fri, 1 Feb 2008 19:22:56 -0500<BR>> > > To: jayk123@hotmail.com<BR>> > ><BR>> > > Hmm. OK, yes, perhaps I am prepared to live with it. Hopefully,<BR>> > > that gnarly x86 backend will go away soon anyway -- it's probably<BR>> > > never going to survive in the x86_64 universe and beyond!<BR>> > ><BR>> > > On Feb 1, 2008, at 7:19 PM, Jay wrote:<BR>> > ><BR>> > > > Actually it's slightly more real than I said.<BR>> > > > One cm3.exe on Windows can do any of NT386/NT386GNU/NT386MINGNU.<BR>> > > > Sometimes it uses the "extra" code, sometimes not. These are in a<BR>> > > > sense a limited form of cross build. Granted, if it was only for<BR>> > > > those three psuedo platforms, you wouldn't mind.<BR>> > > ><BR>> > > > - Jay<BR>> > > ><BR>> > > > From: jayk123@hotmail.com<BR>> > > > To: hosking@cs.purdue.edu; hosking@elego.de<BR>> > > > Date: Sat, 2 Feb 2008 00:12:27 +0000<BR>> > > > CC: m3devel@elegosoft.com<BR>> > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR>> > > ><BR>> > > > This was deliberate. It enables some cross-build scenarios. That I<BR>> > > > admit I haven't used (yet?), but I really like the idea.<BR>> > > > If m3linker were completed, then "full" cross builds would be <BR>> > real.<BR>> > > ><BR>> > > > The "extra" packages are small and build fast (well, at least not<BR>> > > > using cm3cg...).<BR>> > > > Is it really so onerous? Really?<BR>> > > ><BR>> > > > Isn't it nice to have less filtering of packages as well?<BR>> > > > Like, when you are building on non-NT386, you can easily see that<BR>> > > > you didn't break building on NT386, at least partly.<BR>> > > > ?<BR>> > > ><BR>> > > > - Jay<BR>> > > ><BR>> > > ><BR>> > > > > From: hosking@cs.purdue.edu<BR>> > > > > Date: Fri, 1 Feb 2008 18:57:32 -0500<BR>> > > > > To: hosking@elego.de<BR>> > > > > CC: m3devel@elegosoft.com<BR>> > > > > Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR>> > > > ><BR>> > > > > I just checked in support for full declaration of paramters <BR>> > even on<BR>> > > > > imported procedures in the gcc-based backend. This is to support<BR>> > > > > proper generation of stdcall calling convention on Windows. <BR>> > In the<BR>> > > > > process of testing this I discovered that cm3 on non-Windows<BR>> > > > > platforms now needs to build and ship both of the Windows x86<BR>> > > > support<BR>> > > > > libraries m3back and m3objfile, even though non-Windows <BR>> > platforms<BR>> > > > > don't use or need them. This seems broken to me. It seems <BR>> > that cm3<BR>> > > > > has changed so that it now has these dependencies. Can we please<BR>> > > > > undo this? -- I see no need to have to build these for non-x86<BR>> > > > > platforms that will never use them.<BR>> > > > ><BR>> > > > > On Feb 2, 2008, at 12:43 AM, Antony Hosking wrote:<BR>> > > > ><BR>> > > > > > CVSROOT: /usr/cvs<BR>> > > > > > Changes by: hosking@birch. 08/02/02 00:43:53<BR>> > > > > ><BR>> > > > > > Modified files:<BR>> > > > > > cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c<BR>> > > > > ><BR>> > > > > > Log message:<BR>> > > > > > Add parameter decls even for imported procedures, as per Jay<BR>> > > > > > Krell's request<BR>> > > > > > to support stdcall parameter passing mode on Windows.<BR>> > > > ><BR>> > > ><BR>> > > ><BR>> > > > Connect and share in new ways with Windows Live. Get it now!<BR>> > > > Shed those extra pounds with MSN and The Biggest Loser! Learn <BR>> > more.<BR>> > ><BR>> ><BR>> ><BR>> > Shed those extra pounds with MSN and The Biggest Loser! Learn more.<BR>> <BR><BR><BR></DIV>
<DIV>
<HR>
</DIV>
<DIV>Connect and share in new ways with Windows Live. <A href="http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008" target=_blank>Get it now!</A> </DIV></BLOCKQUOTE><br /><hr />Helping your favorite cause is as easy as instant messaging. You IM, we give. <a href='http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join' target='_new'>Learn more.</a></body>
</html>