Author: Eugene Nalimov
Date: 10:53:33 02/16/00
Go up one level in this thread
On February 16, 2000 at 13:41:33, Robert Hyatt wrote: >On February 16, 2000 at 10:06:37, Eugene Nalimov wrote: > >>On February 16, 2000 at 09:30:24, Robert Hyatt wrote: >> >>>On February 16, 2000 at 02:12:21, Eugene Nalimov wrote: >>> >>>>On February 16, 2000 at 00:26:19, Christophe Theron wrote: >>>> >>>>>On February 15, 2000 at 22:45:28, Tom Kerrigan wrote: >>>>> >>>>>>On February 15, 2000 at 20:42:43, Ricardo Gibert wrote: >>>>>> >>>>>>>MIPS VR4121 is a 64 bit CPU according to NEC. Look at >>>>>>>http://www.nec.com/Semiconductors/categories/679/981008.html >>>>>> >>>>>>You're right... Hmmm... I wonder what the "64 bit" measures. Maybe memory >>>>>>interface? Because it seems pretty silly to have a full-blown 64-bit embedded >>>>>>processor, when your desktop machine is still 32-bit... >>>>>> >>>>>>-Tom >>>>> >>>>> >>>>>Wait a minute. The VR4121 processor claims pin-to-pin compatibility with the >>>>>VR4111. And the VR4111 is a "false 64 bits" processor. Operations can be done on >>>>>64 bits internally, but the data bus size is 16 or 32 bits. That is, there is a >>>>>serious bottleneck between the processor and the memory when it comes to 64 bits >>>>>values. >>>>> >>>>>I'm not even sure that this processor really supports clean 64 bits operations. >>>>>All the docs I have mention 16 and 32 bits long instructions. How do you perform >>>>>a move immediate with a 64 bits value if your instruction length is limited to >>>>>32 bits? >>>> >>>>IBM/360, as well as IBM/370, also have no instruction "move immediate 32-bit >>>>value"; if you want to load literal that is longer than 12 bits, you have to >>>>load it from memory. Nevertheless it is true 32-bit processor. >>> >>> >>>I don't know of _any_ processor that can load a 64 bit immediate value. On >>>the sun ultrasparc, (and sparc for that matter) you can't even load a 32 bit >>>immediate value. You have to do it in two pieces with two instructions. Even >>>the Cray is the same. Because they didn't want to support an instruction that >>>would be at least 96 bits long. >> >>IA-64 have instruction 'movl' that loads immediate 64-bit value. It occupies 2 >>instruction slots. >> >>Eugene >> > >Ugh. variable-length instructions make wide superscalar very complicated. >A 64 bit machine needs 128 bits to do that? Ugh. Actually makes more sense >to load from memory, because the "immediate" value comes from memory anyway >since it is just part of a huge instruction. No gain by the 'immediate' value >since it doesn't fit into a standard instruction. IA-64 has very unusual instruction encoding: it packs 3 instructions in 128 bits. Each such 'bundle' includes a prefix, that specifies which types of instructions are encoded in this bundle, e.g. "Memory op, FP op, Integer op", or "Memory op, [instruction group ends - next begins], Memory op, Integer op" (of course not all combinations are possible, that makes scheduler task in the compiler at least very interesting, and increases number of nops in the program). So to find out that it's necessary to interpret 2 instructions as one, processor has to look only at that bundle prefix - and it has to do it anyway. Eugene >>> >>>> >>>>At that MIPS processor, loading/storing 64-bit values can be slower than 32-bit >>>>values - but total impact on performance would be small enough. Small size of >>>>cache is much more important, but I believe Crafty would perform as it's running >>>>on P90-120. >>>> >>>>Eugene >>>> >>>>>And don't count on the 8Kb internal L1 data cache to store all the data needed >>>>>by Crafty... >>>>> >>>>>A bitboard program looks like a poor choice for this architecture. >>>>> >>>>> >>>>> >>>>> Christophe
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.