<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<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=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=_new>Get it now!</A> </DIV></BODY></HTML>