<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Hey, I'd <EM>kind</EM> of like that backend to stay actually. It's quite fast and generates better code than unoptimized gcc and competitive code with optimized gcc. There's no AMD64 support anywhere yet in Modula-3 that I know of. <EM>Maybe </EM>it will appear here first? :)<BR>
<BR>
I don't think it is all <EM>that </EM>gnarly either. But somewhat. It's a bit like code I've see that is so often handling one case after another case after yet another case, yet who knows what all the cases are and which order (if any particular) they should be handled in? That is, it's actually kind of easier to read it and understand what it does do, and realize that is "correct" in the "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 substantially better code.<BR>
It doesn't remember much, doesn't make multiple passes, doesn't have a high level representation, etc.<BR>
<BR>
In the unlikely event that I succeed, presumably PPC would be next...:)<BR>
<BR>
(But yeah yeah, LLVM is probably easier and much more fruitful, both in terms of platform each and optimization..and hopefully build speed.)<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<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 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 even on<BR>> > > imported procedures in the gcc-based backend. This is to support<BR>> > > proper generation of stdcall calling convention on Windows. 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 platforms<BR>> > > don't use or need them. This seems broken to me. It seems 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 more.<BR>> <BR><BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>