[HN Gopher] RISC vs. CISC by John R. Mashey (1995)
___________________________________________________________________
RISC vs. CISC by John R. Mashey (1995)
Author : caned
Score : 62 points
Date : 2024-05-19 05:20 UTC (17 hours ago)
(HTM) web link (yarchive.net)
(TXT) w3m dump (yarchive.net)
| 082349872349872 wrote:
| Lynn Wheeler is another oft-informative usenet personality.
| brucehoult wrote:
| On IBM 360/370 etc stuff, at least.
| klelatti wrote:
| Six hours and only two comments. Perhaps the RISC vs CISC debate
| is over :)
| DeathArrow wrote:
| I doubt there are many pure CISC architectures anymore. Most
| use micro instructions.
| klelatti wrote:
| They always did didn't they?
| drpossum wrote:
| Not "always" but it has been around since at least the 70s,
| including the original 8086 which I don't think anyone
| would classify in good faith as RISC
| Pet_Ant wrote:
| Was there _ever_ a CPU that didn 't breakdown CISC
| instructions into uops, but instead had dedicated hardware
| for each operation? My understanding is that CISC assembly is
| really more like a bytecode for a hardware virtual machine.
| drpossum wrote:
| The venerable 6502. And if someone wants to argue that, it
| doesn't fit under the RISC definition in the post (which I
| like because it sets some good delineation) as it has
| features like indirect addressing and variable-length
| instruction sizes
| monocasa wrote:
| The 6502 has T states at least breaking instructions on
| memory access boundaries.
| chuckadams wrote:
| IBM mainframes used to be sold in tiers where the cheaper
| machines would implement more of the instruction set in
| microcode than the higher-end ones. I imagine even the top
| end had some amount of microcode kicking around though.
|
| > a hardware virtual machine
|
| Otherwise known as "a machine" :)
| netbioserror wrote:
| As I understand it, Intel apparently experimented with
| drastically lowering power consumption. They found that x86 chips
| can absolutely be made to sip power like ARM chips can. The
| conclusion was that fetch, decode, and interconnect were the most
| important power consumers, and CISC vs RISC didn't quite matter
| as much as the physical architecture and layout.
|
| Am I remembering that correctly? Does anyone have a link?
| Pet_Ant wrote:
| > The conclusion was that fetch, decode, and interconnect were
| the most important power consumers and CISC vs RISC didn't
| quite matter as much
|
| Wouldn't that mean that x86 and other CISCs would cost more as
| they often have variable length instructions and thus the most
| complexity and consume the most power?
|
| Now, if you told me that scheduling uops and reordering uops
| etc consumed the most power, then I'd understand why RISC vs
| CISC wouldn't matter as at uop level are high performance chips
| are similar VLIW computers (AFAICT, IANACD).
|
| Though, for my money, I'm betting on a future dominated by
| gigantic core counts of really simple cores that may even be
| in-order. The extra transistors to speed up the processing are
| probably better spent on another core that can just handle the
| next request instead. Clock speeds brought down to some integer
| multiple of RAM speeds, and power costs brought down. At cloud
| scale this just seems economically inevitable. After that, the
| economies of scale mean it'll trickle down to everyone else
| except for specialised use cases.
|
| I believe we already seeing this happening with Zen C cores and
| Intel e cores, and that a simplified instruction set lie RISC-V
| will eventually win out for savings alone.
| gumby wrote:
| > on a future dominated by gigantic core counts of really
| simple cores that may even be in-order. The extra transistors
| to speed up the processing are probably better spent on
| another core that can just handle the next request instead.
|
| I like how you think, but not sure we can get there.
|
| Part of the RISC dream is that you shouldn't need reordering
| as the ops should be similar in timing, so you could
| partially get there on that (although...look at divide, which
| IIRC the 801 didn't even have). So they aren't really uniform
| in length even before you consider memory issues.
|
| Then there is memory -- not all references can be handled
| before instruction decode because a computed indirect
| reference requires computation from the ALU and register
| state to perform. You can't just send the following
| instruction to another unit as its computation may depend on
| the instruction you're waiting for.
|
| That's why the instruction decode-and-perform has been
| smashed into lots of duplicated bits: to do what you say but
| on the individual steps.
|
| At a different level of granularity, big.LITTLE is an
| approach that's along your line of thinking. We tend to have
| a lot more computation than we need, even at the embedded
| level, these days and we may end up with some tiny power-
| sipping coprocessors that dominate most of the runtime of a
| device while doing almost nothing.
| zimpenfish wrote:
| > a future dominated by gigantic core counts of really simple
| cores that may even be in-order
|
| Chuck Moore (of Forth fame) has been advocating something
| like this for a while, although he's more "multi-computer"
| than "multi-core".
|
| https://www.greenarraychips.com/index.html
| Symmetry wrote:
| The end result seems to be that the two entries from that old
| post that have seen the most success, x86 and ARM, are
| essentially the RISCiest of the CISCs and the CISCiest of the
| RISCs. A happy medium.
| fanf2 wrote:
| The runner-up CISC, IBM z / 370, is also fairly RISCy.
| pclmulqdq wrote:
| The runner-up RISC, IBM's POWER, is arguably more CISC-y than
| ARM.
| hmry wrote:
| Intel's new x86 extension (APX) is adding 16 more registers and
| three-register instructions. RISCification is still in
| progress.
| sapiogram wrote:
| What's RISC about adding more registers?
| ajross wrote:
| The simple answer is that a big symmetric register set has
| always been a hallmark of RISC ISAs, because having lots of
| symmetric registers increases throughput by reducing
| compiler-generated spill/fill overhead and permits more
| permissive ABIs for leaf functions that need the extra
| space.
|
| The complicated answer is that, no, it's not especially
| "reduced" and you could implement all those other RISCy
| ideas in a much smaller set of GPRs without otherwise
| effecting the "RISCiness" of the design. But that answer is
| a little specious, since it's true of all the other RISCy
| traits too. Most of them stand alone, which is why the
| whole debate tends to be a little silly.
| drivebycomment wrote:
| Whoa. Comp.arch. I learned so much from that during 90s. There's
| nothing like debates with anecdotes thrown between experienced
| folks to learn from, and comp.arch back then had such a high
| signal-noise ratio that it was amazing.
| trentnelson wrote:
| Yeah I was thinking how different those days seemed. And how
| hard it would be to run into this sort of content these days if
| you're a generally curious youngster.
___________________________________________________________________
(page generated 2024-05-19 23:01 UTC)