 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can somebody find out the typical MIPS and FLOPS for the following:
- Commodore 64 (6510 @ ~1 MHz)
- ZX Spectrum (Z80 @ 3.5 MHz)
- Pentium I @ 66 MHz
- Pentium II @ 233 MHz
- Pentium III @ 500 MHz
- Pentium IV @ 4.0 GHz
- Intel Core 2 Quad @ 3.0 GHz
Surprisingly, Google fails to yield any useful data. I can find out the
*clock speed*, FSB speed, cache size, and numerous other details of
these CPUs, plus various benchmark results, but not MIPS and FLOPS counts...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Jul-08 10:52, Orchid XP v8 wrote:
> Can somebody find out the typical MIPS and FLOPS for the following:
>
> - Commodore 64 (6510 @ ~1 MHz)
> - ZX Spectrum (Z80 @ 3.5 MHz)
> - Pentium I @ 66 MHz
> - Pentium II @ 233 MHz
> - Pentium III @ 500 MHz
> - Pentium IV @ 4.0 GHz
> - Intel Core 2 Quad @ 3.0 GHz
>
> Surprisingly, Google fails to yield any useful data. I can find out the
> *clock speed*, FSB speed, cache size, and numerous other details of
> these CPUs, plus various benchmark results, but not MIPS and FLOPS
> counts...
>
Neither the 6510 nor the Z80 had a floating point processor. Floating
point was in software. FLOPS is not really defined because it depends on
what operation is performed.
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'd
say that although the MIPS rate is not very well defined, on average it
may be in the order of 1/3rd of the clock speed for 65xx and 1/5th-1/4th
for Z80. Some info at:
http://e-tradition.net/bytes/6502/6502_instruction_set.html
http://wikiti.denglend.net/index.php?title=Z80_Instruction_Set
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Neither the 6510 nor the Z80 had a floating point processor. Floating
> point was in software.
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?
> 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?
(Of course, unlike modern processors, cache effects are not present.)
> although the MIPS rate is not very well defined, on average it
> may be in the order of 1/3rd of the clock speed for 65xx and 1/5th-1/4th
> for Z80.
Sounds roughly right. (For the 65xx anyway - I have a manual somewhere
that lists all the opcodes and addressing modes...)
So that gives us, very approximately,
- C64 = 1.0 MHz / 3 = 0.333 MIPS.
- ZX Spectrum = 3.5 MHz / 4 = 0.875 MIPS.
So each is giving us probably a few hundred thousand complete opcodes
executed every second.
Now, anybody have any clue "how big" the numbers are for less ancient CPUs?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> andrel wrote:
> > Neither the 6510 nor the Z80 had a floating point processor. Floating
> > point was in software.
> 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.
As he said, I don't think the term FLOPS even applies if floating point
calculations are done in software instead of in hardware.
> > 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. (Ok, granted, practical RISC
processors do have some opcodes which take more than 1 clock cycle to
execute because it would simply be a physical impossibility to perform
the operation in 1, but the vast majority are executed in 1.)
> Now, anybody have any clue "how big" the numbers are for less ancient CPUs?
For Intel processors it depends a lot on the executed program and the
processor. With the 486 you might get something close if you divide the
clockrate with 1.5 (or something like that). With the Pentium and newer
it becomes very complicated (because the newer Pentiums have whacky things
like parallel pipelines and out-of-order execution).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Jul-08 11:33, Orchid XP v8 wrote:
> andrel wrote:
>
>> Neither the 6510 nor the Z80 had a floating point processor. Floating
>> point was in software.
>
> 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?
My estimate would be that adding 2 floating points would be around 50
and multiplication more 100-150, but I could be an order of magnitude wrong.
>
>> 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?
not for RISC and only partial for state of the art processors.
>
> (Of course, unlike modern processors, cache effects are not present.)
>
>> although the MIPS rate is not very well defined, on average it may be
>> in the order of 1/3rd of the clock speed for 65xx and 1/5th-1/4th for
>> Z80.
>
> Sounds roughly right. (For the 65xx anyway - I have a manual somewhere
> that lists all the opcodes and addressing modes...)
>
> So that gives us, very approximately,
>
> - C64 = 1.0 MHz / 3 = 0.333 MIPS.
> - ZX Spectrum = 3.5 MHz / 4 = 0.875 MIPS.
please don't use 3 significant digits.
>
> So each is giving us probably a few hundred thousand complete opcodes
> executed every second.
>
> Now, anybody have any clue "how big" the numbers are for less ancient CPUs?
>
http://en.wikipedia.org/wiki/Million_instructions_per_second
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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. ;-)
> 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.
>>> 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.
>> Now, anybody have any clue "how big" the numbers are for less ancient CPUs?
>
> For Intel processors it depends a lot on the executed program and the
> processor. With the 486 you might get something close if you divide the
> clockrate with 1.5 (or something like that). With the Pentium and newer
> it becomes very complicated (because the newer Pentiums have whacky things
> like parallel pipelines and out-of-order execution).
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??
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
>
> My estimate would be that adding 2 floating points would be around 50
> and multiplication more 100-150, but I could be an order of magnitude
> wrong.
Right. Suddenly integer-only algorithms seem like a Big Deal. ;-)
>> So that gives us, very approximately,
>>
>> - C64 = 1.0 MHz / 3 = 0.333 MIPS.
>> - ZX Spectrum = 3.5 MHz / 4 = 0.875 MIPS.
>
> please don't use 3 significant digits.
But my very next statement is
>> So each is giving us probably a few hundred thousand complete opcodes
>> executed every second.
;-)
> http://en.wikipedia.org/wiki/Million_instructions_per_second
Ah. Now this looks like the kind of data I'm after...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Jul-08 13:10, Orchid XP v8 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. ;-)
8 cycles to read, 8 to write and some more to fetch all the read and
write opcodes plus some overhead.
>
>> 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.
It does. Multiplication is much slower than addition. Some operation's
timing also depend on the specific bit patterns and overflows
encountered during the processing. Best case and worst case could easily
differ by a factor of 2 or more for one operation. So what time are you
going to use?
>
>>>> 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.
>
yes? The number of FLOPS are given by the producer for the optimal case
of completely filled pipelines so effectively 1 operation finished per
cycle per core (for an arbitrary value of core). In benchmarks they use
a more typical case yet still the pipelines will make a good contribution.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
OK. Well I was actually thinking more about the 6502. I don't know much
about the Z80...
>> 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.
Well OK. But you would have thought that various "best case" numbers
wouldn't differ by huge factors. (Now, if you wanted a *precise*
number... no, that would be rather arbitrary.)
>> 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.
This is true. I was just making a side-comment that I didn't think that
*any* processor could complete one entire instruction in just 1 clock
cycle...
>> 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.
Apparently, yes. (I'm damn *sure* I checked that article and didn't find
any numbers... But they're there now.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 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.
I'm pretty sure that's not correct. Granted, it's been decades since I
did Z80 assembler. It had a 16-bit ALU for the addressing, for the most
part, but the registers were definitely 8-bit registers. Some of the
opcodes would pair them up into an address or some such, but you'd be
taking two registers to do it. Not unlike the "AX = AH:AL" sort of thing
the x86 series does.
Actually, I take that back, didn't the Z80 add some IX and IY registers
the 8080 didn't have or something? The 8080 was 8 bit; the Z80 might
have had *some* 16-bit registers.
Almost everyone calls the processor the number of bits on the data bus,
fwiw, when talking about this stuff. The 8088 was an 8-bit processor
and the 8086 was a 16-bit processor even tho they were 100% software
compatible.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I'm pretty sure that's not correct. Granted, it's been decades since I
> did Z80 assembler. It had a 16-bit ALU for the addressing, for the most
> part, but the registers were definitely 8-bit registers. Some of the
> opcodes would pair them up into an address or some such, but you'd be
> taking two registers to do it. Not unlike the "AX = AH:AL" sort of thing
> the x86 series does.
It's exactly what the x86 does, and that's why the x86 series is a
16-bit processor (up to the 386).
With the z80 you can have 16-bit literals, perform 16-bit ALU operations
(such as additions, substractions, shifts, etc), you can address the entire
memory with one single 16-bit register, etc. I don't understand what's *not*
16-bit about the z80.
Just because the 16-bit operations are performed on pairs of 8-bit
registers that doesn't make it any less of a 16-bit operation. The
crucial thing is that you can perform a 16-bit operation with *one*
single opcode. You can also load a 16-bit value into such a pair with
one single opcode. This means the opcode is a 16-bit one.
If the z80 is not a 16-bit processor, then neither is the 80286.
> Almost everyone calls the processor the number of bits on the data bus,
> fwiw, when talking about this stuff.
How is that even useful? It might tell something about the speed at which
the processor can handle data, but it doesn't tell anything about the
processor itself.
I understand "8-bit" to mean "has 8-bit registers, and you can only
perform an 8-bit operation with a single opcode, because registers can
only hold 8 bits of data". Likewise for any other bitsize.
Btw, didn't the 386 usually have a 16-bit data bus? The 386 is still
a 32-bit processor, though.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Can somebody find out the typical MIPS and FLOPS for the following:
>
> - Commodore 64 (6510 @ ~1 MHz)
Most instructions took from 2 to 5 clock cycles, so I'd venture to say
that the 6510 ran between .2 and .5 MIPS. Floating point is implemented
in software, and since the processor didn't have a hardware multiply
(and shifts were one bit at a time), it probably took dozens of machine
cycles for addition/subtraction and hundreds for multiplication and
division. I doubt that it ever got much past ten kiloflops, and
probably averaged lower than that.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Right. Suddenly integer-only algorithms seem like a Big Deal. ;-)
There were games on the Apple (6502-based) which had seven versions of
any given sprite graphic so that they wouldn't have to be shifted in
order to display them on the screen. 8-bit game programmers learned
much about squeezing every last drop of performance out of limited speed
and memory.
One of the best C64 games was called Pinball Construction Set, which had
the pinball moving with apparently natural motion and reflecting off of
barriers of any angle. I should have looked at the code to see how they
pulled it off.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> http://e-tradition.net/bytes/6502/6502_instruction_set.html
I had the whole instruction set, and the opcodes, memorized at one point
in life. There were less than 160 of them to remember, so it wasn't hard.
During the 1985-87 time frame, I wrote a word processor, in assembler,
for my C64, I entered most of it as machine code as I went along. It
worked quite well (given that it only had to send Epson-compatible
formatting codes for things like italics, bold face, and so on); I wrote
a short novel using it.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle <evi### [at] hotmailcom> wrote:
> One of the best C64 games was called Pinball Construction Set, which had
> the pinball moving with apparently natural motion and reflecting off of
> barriers of any angle. I should have looked at the code to see how they
> pulled it off.
Well, have you seen the best C64 demos?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> There were games on the Apple (6502-based) which had seven versions of
> any given sprite graphic so that they wouldn't have to be shifted in
> order to display them on the screen. 8-bit game programmers learned
> much about squeezing every last drop of performance out of limited speed
> and memory.
Wouldn't having 7 copies of the same data eat more memory?
Did it actually store 7 copies, or just precompute them?
Also... Apple made a 6502-based product??
> One of the best C64 games was called Pinball Construction Set, which had
> the pinball moving with apparently natural motion and reflecting off of
> barriers of any angle. I should have looked at the code to see how they
> pulled it off.
The equations for simple 2D acceleration and reflection are fairly easy,
and probably implementable in fixed-point arithmetic. The *hard* part
about physical simulations is that they usually involve a huge number of
items; *one* marble isn't too big a deal.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle wrote:
> I had the whole instruction set, and the opcodes, memorized at one point
> in life. There were less than 160 of them to remember, so it wasn't hard.
>
> During the 1985-87 time frame, I wrote a word processor, in assembler,
> for my C64, I entered most of it as machine code as I went along. It
> worked quite well (given that it only had to send Epson-compatible
> formatting codes for things like italics, bold face, and so on); I wrote
> a short novel using it.
Jesus! o_O
I just wrote the assembly on a piece of paper, and when the program was
properly finished, it'd do the "assembling" part by hand. (I.e., open my
dad's book and leaf through the op-code table.)
Eventually I tired of this, and wrote by old assembler.
*cough*
Well OK - wrote my own program to look up op-codes anyway. I typed the
whole op-code table into the computer (remember DATA statements?) and
wrote a program that does a trivial linear search to find the op-code
for the mnumonic I typed in. It was astonishingly slow, actually... hmm...
I didn't know much about algorithms back then. Give me a break! I was
only 11...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> - Commodore 64 (6510 @ ~1 MHz)
>
> Most instructions took from 2 to 5 clock cycles, so I'd venture to say
> that the 6510 ran between .2 and .5 MIPS. Floating point is implemented
> in software, and since the processor didn't have a hardware multiply
> (and shifts were one bit at a time), it probably took dozens of machine
> cycles for addition/subtraction and hundreds for multiplication and
> division. I doubt that it ever got much past ten kiloflops, and
> probably averaged lower than that.
I recall there was no multiplication or division (in fact, I have the
listing somewhere for a program that does repeated addition to achieve
multiplication), but I'd forgotten about the lack of arbitrary bit
shifts. (Not that it would matter for integer multiplication...)
Yes, definitely hundreds of instructions for floating-point arithmetic!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote
> Just because the 16-bit operations are performed on pairs of 8-bit
> registers that doesn't make it any less of a 16-bit operation. The
> crucial thing is that you can perform a 16-bit operation with *one*
> single opcode.
It doesn't work like that. Otherwise, we should call x86 architecture 64
bits, 128 bits or even higher.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Jul-08 20:53, Orchid XP v8 wrote:
> John VanSickle wrote:
>
>> There were games on the Apple (6502-based) which had seven versions of
>> any given sprite graphic so that they wouldn't have to be shifted in
>> order to display them on the screen. 8-bit game programmers learned
>> much about squeezing every last drop of performance out of limited
>> speed and memory.
>
> Wouldn't having 7 copies of the same data eat more memory?
>
> Did it actually store 7 copies, or just precompute them?
>
> Also... Apple made a 6502-based product??
Hmm?? Ah, good old Andy at his best.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Also... Apple made a 6502-based product??
>
> Hmm?? Ah, good old Andy at his best.
Remember: I've never actually *seen* an Apple, except on TV. So I'm not
extremely knowledgable about them.
But anyway, I was under the impression they used to be M68k-based, and
then PPC, and then recently went to Intel Core 2.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Jul-08 21:47, Orchid XP v8 wrote:
>>> Also... Apple made a 6502-based product??
>>
>> Hmm?? Ah, good old Andy at his best.
>
> Remember: I've never actually *seen* an Apple, except on TV. So I'm not
> extremely knowledgable about them.
>
> But anyway, I was under the impression they used to be M68k-based, and
> then PPC, and then recently went to Intel Core 2.
Most people here might have consulted wikipedia or similar before
posting. Then again you wouldn't be our mascot if you did. You are
really good at mascotting you know. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Most people here might have consulted wikipedia or similar before
> posting. Then again you wouldn't be our mascot if you did. You are
> really good at mascotting you know. ;)
Well if somebody says there was one, I guess there probably was one. I
was more interjecting with surprise than actually denying the fact. ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> With the z80 you can have 16-bit literals, perform 16-bit ALU operations
> (such as additions, substractions, shifts, etc), you can address the entire
> memory with one single 16-bit register, etc. I don't understand what's *not*
> 16-bit about the z80.
OK. I must be confusing the Z80 with the 8080, perhaps. I know the 8080
had no 16-bit registers except PC and SP. HL was two registers, for
example.
> Just because the 16-bit operations are performed on pairs of 8-bit
> registers that doesn't make it any less of a 16-bit operation.
OK. I guess we're just disagreeing about whether that ability makes a
CPU an "8-bit CPU" or a "16-bit CPU".
I mean, I've used mainframes with "string" type opcodes that would
operate on 1KBytes at a time. That wouldn't really make them a KByte
CPU. :-)
>> Almost everyone calls the processor the number of bits on the data bus,
>> fwiw, when talking about this stuff.
>
> How is that even useful?
Very useful for hardware type people. Also unambiguous. Plus, I didn't
claim it was useful. I merely said it's what I noticed when I read all
the literature.
Maybe because the "definitive" literature written by places like Intel
are generally addressing people who build motherboards for their chips
and such.
> I understand "8-bit" to mean "has 8-bit registers, and you can only
> perform an 8-bit operation with a single opcode, because registers can
> only hold 8 bits of data". Likewise for any other bitsize.
Well, the 6502 had 16-bit absolute jumps, IIRC. I wouldn't call it a
16-bit CPU.
> Btw, didn't the 386 usually have a 16-bit data bus? The 386 is still
> a 32-bit processor, though.
I don't remember the bus size. But at this point, I think we're more
arguing what you call the CPU than anything real about the CPU.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
somebody <x### [at] ycom> wrote:
> "Warp" <war### [at] tagpovrayorg> wrote
> > Just because the 16-bit operations are performed on pairs of 8-bit
> > registers that doesn't make it any less of a 16-bit operation. The
> > crucial thing is that you can perform a 16-bit operation with *one*
> > single opcode.
> It doesn't work like that. Otherwise, we should call x86 architecture 64
> bits, 128 bits or even higher.
I was talking about *all* the ALU operations, such as addition,
substraction, etc. In some processors there might be a few special
opcodes that perform an operation with larger numbers by using several
registers (such as the shifting of two registers as if they were one
in x86), but these are rare.
If it was about data bus width, then some 32-bit processors would
in reality be 128-bit or 256-bit because they have really wide data
buses. Heck, if I remember correctly, even the Pentium4 has a 64-bit
data bus, yet it's still a 32-bit processor.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmailcom> wrote:
> Most people here might have consulted wikipedia or similar before
> posting.
When I write like this, I get accused of bullying.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Jul-08 22:17, Orchid XP v8 wrote:
> andrel wrote:
>
>> Most people here might have consulted wikipedia or similar before
>> posting. Then again you wouldn't be our mascot if you did. You are
>> really good at mascotting you know. ;)
>
> Well if somebody says there was one, I guess there probably was one. I
> was more interjecting with surprise than actually denying the fact. ;-)
>
FYI we are talking about the Apple II without which the whole concept of
a personal computer that anyone could buy would not have existed. OK
another computer would have done it a few years later, but that is not
the point.
It feels a bit like someone working with genetic material everyday and
then say: 'Mendel, never heard of that guy, or was it a girl?'. Anyway,
if we compiled a list of entertaining books about the history of
computers and surrounding science is there any change you'd read them?
When is your birthday?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > Just because the 16-bit operations are performed on pairs of 8-bit
> > registers that doesn't make it any less of a 16-bit operation.
> OK. I guess we're just disagreeing about whether that ability makes a
> CPU an "8-bit CPU" or a "16-bit CPU".
IMO "16-bit CPU" means "can perform most calculations on 16-bit values
with single opcodes". There are examples of true 8-bit processors where
you really are limited to 8-bit operations (and if you want to calculate
on larger numbers you have to use at least two opcodes, the second one
using the possible flag set by the previous one).
> I mean, I've used mainframes with "string" type opcodes that would
> operate on 1KBytes at a time. That wouldn't really make them a KByte
> CPU. :-)
The question is whether its registers were 1kB in size or not.
Just because you can fill 1MB of memory with zeros using a single opcode
doesn't tell anything about the bitsize of the registers and how the CPU
uses them.
> > I understand "8-bit" to mean "has 8-bit registers, and you can only
> > perform an 8-bit operation with a single opcode, because registers can
> > only hold 8 bits of data". Likewise for any other bitsize.
> Well, the 6502 had 16-bit absolute jumps, IIRC. I wouldn't call it a
> 16-bit CPU.
Could you calculate eg. additions and substractions using 16-bit values
with single opcodes?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> FYI we are talking about the Apple II without which the whole concept of
> a personal computer that anyone could buy would not have existed. OK
> another computer would have done it a few years later, but that is not
> the point.
OOC, when did this happen? I have a sneaking suspicion it might have
been before I was born...
> It feels a bit like someone working with genetic material everyday and
> then say: 'Mendel, never heard of that guy, or was it a girl?'.
Still not seeing why it's important for such a person to have heard of
Mendel...
I mean, hell, I use electricity every single day. I have *no clue* who
figured out that it exists though... why is that a problem?
> Anyway,
> if we compiled a list of entertaining books about the history of
> computers and surrounding science is there any change you'd read them?
Um... I'm going to walk round the Science Museum tomorrow? Does that count?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> Just because the 16-bit operations are performed on pairs of 8-bit
>>> registers that doesn't make it any less of a 16-bit operation.
>
>> OK. I guess we're just disagreeing about whether that ability makes a
>> CPU an "8-bit CPU" or a "16-bit CPU".
>
> IMO "16-bit CPU" means "can perform most calculations on 16-bit values
> with single opcodes".
I'm pretty sure the 8080 at least was not like that.
Hmmm... A quick google shows opcodes like "add hl,bc" and such, as well
as some subtracts, but many more opcodes for 8-bit than 16-bit ops. (And
some extra prefix codes for IX and IY, yes.) The accumulator, for
example, was 8 bits, and (IIRC) you couldn't load a 2-byte address into
a two-byte pointer register unless it was an absolute address.
The 8080 had no such opcodes at all, from what I can see (and what I
remember). I probably stopped programming in assembler before the Z80
was widespread enough you could just rely on it being there instead of
an 8080. :-)
> Could you calculate eg. additions and substractions using 16-bit values
> with single opcodes?
Nope.
OK, so you're saying a 16-bit CPU has a 16-bit ALU? I'm not sure how
wide the Z80's ALU was. I wouldn't be surprised if "sub bc,hl" was
calculated with two runs thru the ALU.
Anyway, as I said, I think at this point we're just discussing what one
wants to call the CPU, without adding any additional information to it.
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Most people here might have consulted wikipedia or similar before
>> posting.
>
> When I write like this, I get accused of bullying.
I think it's because you write that way more often then most do. Doing
anything once isn't bullying. :-)
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> I mean, hell, I use electricity every single day. I have *no clue* who
> figured out that it exists though... why is that a problem?
How did the world survive before computers, cellphones and frozen pizza?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:487a65de@news.povray.org...
> somebody <x### [at] ycom> wrote:
> > "Warp" <war### [at] tagpovrayorg> wrote
> > > Just because the 16-bit operations are performed on pairs of 8-bit
> > > registers that doesn't make it any less of a 16-bit operation. The
> > > crucial thing is that you can perform a 16-bit operation with *one*
> > > single opcode.
> > It doesn't work like that. Otherwise, we should call x86 architecture 64
> > bits, 128 bits or even higher.
> I was talking about *all* the ALU operations, such as addition,
> substraction, etc.
Then, if there are *some* OpCodes that operate with 8 bits, does that make
it an 8bit CPU?
I think your (unconventional) definition is arbitrary and unworkable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
somebody <x### [at] ycom> wrote:
> I think your (unconventional) definition is arbitrary and unworkable.
So is the "traditional" definition because it says absolutely nothing
about the processor nor the computer architecture. It's inconsistent too
(eg. it calls z80 an "8-bit processor" because of having an 8-bit data
bus, but a pentium4 is called a "32-bit processor" even though, AFAIK,
it has a 64-bit data bus; there are also 32-bit processors with even
wider data buses, and they are still called "32-bit").
At least "the natural word size of the processor" (which is really what
I'm talking about) is a much better definition. It's more descriptive and
useful (because it tells what kind of integer arithmetic you can perform
with the processor most efficiently).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13-Jul-08 23:21, Darren New wrote:
> Warp wrote:
>> andrel <a_l### [at] hotmailcom> wrote:
>>> Most people here might have consulted wikipedia or similar before
>>> posting.
>>
>> When I write like this, I get accused of bullying.
>
> I think it's because you write that way more often then most do. Doing
> anything once isn't bullying. :-)
>
But I did it before. ;)
Explanation for Warp: I knew this was on the edge or might be perceived
by people as such. I though it was on the right side of that edge for a
number of reasons (although this feels a bit like explaining a joke,
generally not something I like to do often.) If you look at what I wrote
(including the part that you so carelessly snipped whitout using
ellipses) I did not say he should, I said others would have done
differently and that I applauded him for it. You could read that as
sarcasm or irony or whatever (and you'd be right), but it was followed
by a reference to another post that I knew he'd read this morning. So,
taken out of context and especially in your abbreviated version, one
could perceive it as bullying, but I knew Andrew would not see it that
way. (assuming he would be able to remember who I was over this short
timespan). BTW I think the 21:46 post was much worse, but I think I got
away with that too. Anyway, I know from experience that it is quite hard
to insult Andrew (at least for me) and I don't think I ever managed
that. Though sometimes onlookers may have had to hold their breath. Of
course my record with you is not so good, but that is mutual. ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> So is the "traditional" definition because it says absolutely nothing
> about the processor nor the computer architecture.
I think the real problem is that CPUs have gotten complex enough that
there's no long a single dimension along which you measure "size." It's
like arguing over whether something is "CISC" or "RISC".
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I think the real problem is that CPUs have gotten complex enough that
> there's no long a single dimension along which you measure "size." It's
> like arguing over whether something is "CISC" or "RISC".
I don't think there's any confusion about that. In a typical RISC
processor each opcode has exactly the same size, and a fixed amount of
bits in the opcode are allocated for specified things. (This really
limits the total number of commands (disregarding its parameters inside
the opcode), making it a truely reduced instruction set.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I don't think there's any confusion about that. In a typical RISC
> processor each opcode has exactly the same size, and a fixed amount of
> bits in the opcode are allocated for specified things.
I don't think that's sufficient to make it a RISC processor. That would
mean both the PDP-11 and the X-560 were RISC processors. The X-560 had
built-in instructions for COBOL data types, string manipulation (aka
block moves/compares/character set and case conversions/etc),
instructions that would do things like push a word on a stack whose
pointer was in a particular register and set the condition bits to stack
full/empty/almost full/almost empty, etc. Yet it had 7 bits of opcode,
one "indirect" bit, four bits of register ID, then either three bits of
index register and 17 bits of address, or 20 bits of absolute
(immediate) data. Very straightforward enough that I can still remember
how the opcodes were laid out after 20 years not using it. Pretty much
all the microcoded CISC machines were like that, especially those
expected to be programmed in assembler.
You'd have to talk about addressing modes, pipelines, generalness of
registers, etc. Sure, the original RISC processors had a very simple
model so they could fit more registers, but I think we've gone past that
now. What you describe might be true of *typical* RISC processors and
untrue of *typical* CISC processors, but I think everything's complex
enough now that you need to measure things on multiple dimensions in
order for it to make any sense.
This one's actually pretty interesting:
http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html
(Which has an interesting statistic that might explain why people don't
code languages for memory efficiency any more: """To help you wrap your
mind around the situation, consider the fact that in 1977, 1MB of DRAM
cost about $5,000. By 1994, that price had dropped to under $6 (in 1977
dollars.""")
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Almost everyone calls the processor the number of bits on the data bus,
> fwiw, when talking about this stuff. The 8088 was an 8-bit processor
> and the 8086 was a 16-bit processor even tho they were 100% software
> compatible.
I thought they called it the native register size?
Most registers in modern x86 chips are 32 bit or 64 bits, so they're 32
or 64 bit CPUs.
I first heard about the 8088/8086 duo reading something in Intel's
literature, and I'm pretty sure they stated that both were 16 bit chips,
even though the 8088 had the castrated data bus.
Et cetera.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> But anyway, I was under the impression they used to be M68k-based, and
> then PPC, and then recently went to Intel Core 2.
From Wikipedia*: "Throughout the 1980s and much of the 1990s, the Apple
II was the de facto standard computer in American education; some of
them are still operational in classrooms today.
...
The first Apple II computers went on sale on June 6, 1977[2] with a MOS
Technology 6502 microprocessor running at 1 MHz, 4 kB of RAM, an audio
cassette interface for loading programs and storing data, and the
Integer BASIC programming language built into the ROMs."
Heh... while I never used the original model, most of the schools where
I lived used IIe's or later. As the article says, there are *still*
schools around that have labs full of them.
...Chambers
*http://en.wikipedia.org/wiki/Apple_II
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> How did the world survive before computers, cellphones and frozen pizza?
Quite well, from what I've heard... ;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> Heh... while I never used the original model, most of the schools where
> I lived used IIe's or later. As the article says, there are *still*
> schools around that have labs full of them.
Must be a regional thing... When I was at school, it was the BBC Micro -
and nothing else!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I thought this was true for *all* processors?
No, as already said, RISC gets close to 1 instruction per clock cycle on
average, but new CISC processors can do instructions in parallel inside the
same core, so you can get more than 1 instruction per clock cycle on
average. Actually it seems like the latest Intel processors can do getting
on for 20 instructions per clock cycle on average.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I don't think that's sufficient to make it a RISC processor. That would
> mean both the PDP-11 and the X-560 were RISC processors.
Who says they weren't?
> The X-560 had
> built-in instructions for COBOL data types, string manipulation (aka
> block moves/compares/character set and case conversions/etc),
> instructions that would do things like push a word on a stack whose
> pointer was in a particular register and set the condition bits to stack
> full/empty/almost full/almost empty, etc. Yet it had 7 bits of opcode,
> one "indirect" bit, four bits of register ID, then either three bits of
> index register and 17 bits of address, or 20 bits of absolute
> (immediate) data. Very straightforward enough that I can still remember
> how the opcodes were laid out after 20 years not using it. Pretty much
> all the microcoded CISC machines were like that, especially those
> expected to be programmed in assembler.
I don't think RISC has been ever defined to mean "you can only perform
very simple operations with a single opcode". RISC stands for *reduced*
instruction set computer, not *simplified* instruction set computer.
Just because the total amount of different instructions may be small
(eg. because only 7 bits of the opcode have been reserved for the
instruction, and thus the number of different instructions is limited
to 128), that doesn't mean that an instruction couldn't perform very
complicated things.
I don't really understand where the concept of a RISC opcode being
*simple* has come from.
What makes RISC processors simpler is that their fetching and decoding
steps, pipelines and code caches are simpler because all the opcodes have
exactly the same size and the meaning of the bits in each opcode has
been fixed. CISC processors are more complicated because of variable-sized
opcodes which can contain almost anything.
> You'd have to talk about addressing modes, pipelines, generalness of
> registers, etc. Sure, the original RISC processors had a very simple
> model so they could fit more registers, but I think we've gone past that
> now. What you describe might be true of *typical* RISC processors and
> untrue of *typical* CISC processors, but I think everything's complex
> enough now that you need to measure things on multiple dimensions in
> order for it to make any sense.
It's not a question of simple or complicated.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> Orchid XP v8 wrote:
> > But anyway, I was under the impression they used to be M68k-based, and
> > then PPC, and then recently went to Intel Core 2.
> From Wikipedia*: "Throughout the 1980s and much of the 1990s, the Apple
> II was the de facto standard computer in American education; some of
> them are still operational in classrooms today.
There's no use in trying to convince him that Apple computers are or have
ever been popular anywhere. He will never believe it, no matter how much
evidence you pour to him.
Let him live in his illusion in peace.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> John VanSickle wrote:
>
>> There were games on the Apple (6502-based) which had seven versions of
>> any given sprite graphic so that they wouldn't have to be shifted in
>> order to display them on the screen. 8-bit game programmers learned
>> much about squeezing every last drop of performance out of limited
>> speed and memory.
>
> Wouldn't having 7 copies of the same data eat more memory?
This is what programmers call a trade-off; the only way to get
acceptable speed was to use up seven times as much memory (not eight,
because only the lower seven bits of each video byte represented screen
pixels; the MSB selected the colors).
> Did it actually store 7 copies, or just precompute them?
The computer did not precompute them; the programmer did.
> Also... Apple made a 6502-based product??
Yes, it was called the Apple ][.
> The equations for simple 2D acceleration and reflection are fairly easy,
> and probably implementable in fixed-point arithmetic.
I suspect that they actually used angles, probably 256ths of a circle,
which on a screen with 320 x 200 pixels was all the precision anyone
needed. When a ball moving at angle X hits a wall set at angle Y, the
ricochet angle is calculated with addition and subtraction, and no
multiplication is needed at all. To move the ball, the angle was used
to index a lookup table of sine and cosine values, and they probably
used one table for both (add 0x40 to the 8-bit index to get cosine values).
> The *hard* part about physical simulations is that they usually involve
> a huge number of items; *one* marble isn't too big a deal.
Yeah; gravity sims are an O(n^2) problem.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> I just wrote the assembly on a piece of paper, and when the program was
> properly finished, it'd do the "assembling" part by hand. (I.e., open my
> dad's book and leaf through the op-code table.)
Hand assembly was actually a common practice until 16-bit processors
made this too troublesome; with at most 256 opcodes to remember
(although the 6809[1] had prefix opcodes that made the following opcode
take on a different meaning), many 8-bit assembly programmers were
perfectly capable of reading and writing the opcodes directly from/to a
memory listing.
> Eventually I tired of this, and wrote my old assembler.
The C64 had a cartridge port on the back end, and one fine company put
out a cartridge called HESMon, which provided a mini-assembler, memory
dump and editing, and so on. I could have used the mini-assembler, but
opcodes were two keystrokes while mnemonics were three, so for the sake
of speed I usually typed the opcodes. The monitor would disassemble
them for me so I caught any errors quickly.
Regards,
John
[1] The 6809 was the nicest, IMHO, of the 8-bit processors. It had
hardware multiply and sixteen-bit index registers (with preincrement and
postdecrement). Code for that processor was usually smaller than the
6502 equivalent.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I don't think that's sufficient to make it a RISC processor. That would
>> mean both the PDP-11 and the X-560 were RISC processors.
>
> Who says they weren't?
Maybe because both were obsolete before the term RISC was invented?
Because neither had lots of variables? Because they both had complex
addressing modes beyond LOAD and STORE? Because they both had
instructions that took variable numbers of cycles?
*I* say they weren't. They might meet your definition of RISC, but I'm
pretty sure your definition doesn't align with the definitions of most
others when talking about it.
> I don't think RISC has been ever defined to mean "you can only perform
> very simple operations with a single opcode". RISC stands for *reduced*
> instruction set computer, not *simplified* instruction set computer.
No, but it also means the ALU only talks to the registers, and there
aren't any complex addressing modes. Neither of those are true of the
two CPUs I named here.
> I don't really understand where the concept of a RISC opcode being
> *simple* has come from.
Well, because that made it fast. Read the link I pointed you to. The
point of reducing the instruction set and addressing modes was to make
it faster and to make more room for registers, by eliminating the
microcode.
> What makes RISC processors simpler is that their fetching and decoding
> steps, pipelines and code caches are simpler because all the opcodes have
> exactly the same size and the meaning of the bits in each opcode has
> been fixed. CISC processors are more complicated because of variable-sized
> opcodes which can contain almost anything.
Again, I think you're oversimplifying. You're using a definition for
RISC at odds with the definition created by the people who created the
term. By leaving off significant portions of the original "meaning" of
the term, you're turning it into a binary situation. However, the
original meaning of RISC has several components (addressing modes,
increased number of registers, simplified decoding), and processors
nowadays combine these things to different degrees.
I think if you asked a modern CPU designer whether he'd consider a
hardware operation equivalent to sprintf() to be "RISC", you'd almost
invariably get the answer "no".
--
Darren New / San Diego, CA, USA (PST)
Helpful housekeeping hints:
Check your feather pillows for holes
before putting them in the washing machine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14-Jul-08 9:13, Orchid XP v8 wrote:
> Warp wrote:
>
>> How did the world survive before computers, cellphones and frozen
>> pizza?
>
> Quite well, from what I've heard... ;-)
>
I heard it doesn't exist anymore. So I don't think it did so well after all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
