Author: Robert Hyatt
Date: 07:00:57 03/01/03
Go up one level in this thread
On March 01, 2003 at 09:37:32, Vincent Diepeveen wrote: >On March 01, 2003 at 00:32:48, Robert Hyatt wrote: > >don't wine Bob. K7 has a lot more registers than the sparc processor. From head >i remember 44 rename registers then another 8 general registers and some other >stuff probably as well. Then added to that at least another 8 MMX registers. > Do you understand how the sparc works? It has 500 or so registers, 32 of which are visible at any instant. The K7 is _nothing_ compared to that. And I'm not counting floating point at all, just "general purpose" registers of which there are R0 through R31. Rename registers have nothing to do with a compiler, either. It can't "see" them any more than the programmer can... >The ultrasparc is completely outdated of course and before 2005 that won't >change soon. Sun announced in fact that it would use in future AMD-opteron >systems. A wise decision. Wouldn't disagree. Sparcs have been bad since they were introduced. > >>On February 28, 2003 at 23:41:57, Jeremiah Penery wrote: >> >>>On February 28, 2003 at 23:24:28, Robert Hyatt wrote: >>> >>>>On February 28, 2003 at 18:00:06, Jeremiah Penery wrote: >>>> >>>>>http://ccc.it.ro/search/ccc.php?art_id=189071 >>>>> >>>>>In case the link doesn't work, here's what it says: >>>> >>>>I'm not sure why this is related. >>> >>>It's not just related, it's practically identical. That post came from a >>>discussion that happened here once before, with Vincent claiming that GCC does >>>bad optimizations on architectures with lots of registers, and you saying >>>Vincent's claims were BS. >> >>And I still do. The sparc has lots of registers, 32 to be exact, and gcc >>produces good code there, as good as Sun's own commercial compiler. QED >>large numbers of registers do not confuse GCC. >> >>IA64 is a completely different issue. >> >> >>> >>>> IA64 is non-trivial to optimize >>>>for. But not because it has a boatload of registers. For example, >>>>use gcc on a sparc and look at the code. With 32 registers, it does >>>>quite well and can use 'em all with no problems. I'd be happy to post >>>>some sparc .s files if you want to see that this isn't a problem... >>>> >>>>Now, as for IA64, I have looked at some prelim docs very _lightly_ and it >>>>reminds me of other attempts at VLIW computers, with the same bundling >>>>difficulties they all had. But this wasn't about IA64 as I was reading it, >>> >>>You're right, this has nothing to do with IA-64 specifically. It was just used >>>as an example. >>> >>>>it was about "large numbers of registers are bad for gcc" and I don't believe >>>>that is true in general. >>> >>>Umm, did you just not read Eugene's post or something? That's exactly what he >>>was talking about. >> >> >>However, if you read _carefully_ the machines he talked about each had 16 >>registers. And it was supposedly designed with _those_ in mind. Somehow I >>find it hard to fathom that it does badly with 32 reg machines, when it does >>fine on the few sparcs we have left. When I went to bitmaps, I first ran on a >>64 bit sparc and I spent a lot of time looking at the asm output of gcc to see >>if I could help the compiler improve the code it produced. It really did pretty >>well, the major flaw being that it didn't quite understand the sparc's super- >>scalar instruction "pairing" issues very well. But then again, Sun's compiler >>did poorly there too so it was a "wash". >> >>But at least it works well for 16 and 32. I've never tried gcc on a Cray, if >>it even has a cray port. That machine has more registers than any machine I >>know of so it would be revealing if there is Cray support in it.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.