 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
