Orchid XP v8 <voi### [at] devnull> wrote:
> >> That's true. But assuming we want, say, a normal "double precision" 
> >> floating point number, how many clock cycles would you estimate it takes 
> >> to operation on? A dozen? A hundred?
> > 
> >   A lot. I don't believe *any* existing program for those processors
> > does double precision floating point calculations.

> You're probably right about that. (Just moving 8 bytes around has to 
> take a minimum of 8 instructions, before you *do* anything to those 
> bytes.) Just wanted to make it a like-for-like comparison. ;-)

  Actually the Z80 has 16-bit registers, 16-bit memory addressing and
a 16-bit ALU (don't believe wikipedia's lies about calling the Z80 an
"8-bit processor"). But anyways.

> >   As he said, I don't think the term FLOPS even applies if floating point
> > calculations are done in software instead of in hardware.

> Floating-point operations per second. Does it matter *how* it does them? 
> Surely the important point is how many of 'em it can do.

  I think it becomes a bit fuzzy if it's done in software, because then
it becomes a question of how optimized that software is. One software
might calculate floating point operations twice as fast as another because
of better optimizations, but that doesn't tell anything about the FLOPS
of the *processor architecture*. Calculating the theoretical and practical
maximum software FLOPS for a given non-FPU processor could be next to
impossible.

> >>> Both had a variable instruction set that took a variable amount of 
> >>> cycles to execute and therefor the number of instruction processed 
> >>> depended on the program and especially on the addressing modes used.
> > 
> >> I thought this was true for *all* processors?
> > 
> >   No. The idea with RISC processors is that each opcode has the same size
> > and takes exactly 1 clock cycle to execute.

> Interesting. I was under the impression that processors such as the 
> Pentium can execute multiple instructions in parallel, and therefore 
> several instructions can reach the "completed" stage in a single given 
> clock cycle, but that each individual instruction still takes multiple 
> cycles from start to finish.

  When calculating MIPS it doesn't matter how many clock cycles it takes
for one opcode to be fetched and passed through the entire pipeline and
executed. What matters is the throughput. In other words, as the very
acronym says, how many instructions the processor can execute per second
(not how long it takes for one single instruction to be completely processed).

  The throughput of most RISC processors is, at least theoretically, 1 clock
cycle per instruction (except for the few instructions which require more).

> I'm only trying to figure out "how many zeros" are in the number, if you 
> see what I mean...

> Is it 10 MIPS? 100? 1,000? 1,000,000??

  The wikipedia article about the subject has some numbers.

-- 
                                                          - Warp

Post a reply to this message