8 ms·

> They are simpler to decode and execute, which is nice if you're making a small, cheap core aiming at low power consumption. Yes and there is an interesting c

> They are simpler to decode and execute, which is nice if you're making a small, cheap core aiming at low power consumption. Yes and there is an interesting corollary that it makes a big.LITTLE type arrangement more effective.

kllrnohj 4y ago
Except none of the shipping big.LITTLE implementations are "RISC" under the framework of the article, though. ARM is very definitely post-RISC and has very CISC-y features. Apple's versions go even farther and include x86 compatibility modes, very CISC-Y. And if course Intel's x86 is never accused of being RISC, either. And really the entire reason big.LITTLE even exists at all is because the cores got too large and complex. Or, alternatively, they got too "CISC-y". So big.LITTLE is therefore about shipping a "CISC" and "RISC" core on the same piece of silicon really.
- zozbot234 4y ago
  These things have nothing to do with CISC vs. RISC. Apple's special x86 compatibility is about TSO model of concurrency, which though quite strong and straying far from more RISC-like approaches to concurrency (the Alpha memory model was even abandoned in more recent architectures as too weak) is not especially 'CISC' either.
- klelatti 4y ago
  > So big.LITTLE is therefore about shipping a "CISC" and "RISC" core on the same piece of silicon really. You're mixing up ISA and implementation. To the extent that RISC / CISC has any meaning at all any more it's a property of the instruction set. RISC-V which makes a big deal out of being RISC is after all just an ISA. And I take issue with the original article on this too.
Animats 4y ago
> They are simpler to decode One of the big headaches with x86 superscalar machines is that finding the instruction boundaries is hard. The decoders, looking ahead, may guess at alignment and decode bytes which represent a totally bogus instruction, which causes work that gets discarded further downstream. Intel and AMD did this very differently in the early days of superscalar. If you're going to have a variable length instruction set, it would be nice if it worked like UTF-8, where you can start anywhere in a stream and get aligned within a few bytes. x86 is not like that.

kllrnohj 4y ago

Except none of the shipping big.LITTLE implementations are "RISC" under the framework of the article, though. ARM is very definitely post-RISC and has very CISC-y features. Apple's versions go even farther and include x86 compatibility modes, very CISC-Y. And if course Intel's x86 is never accused of being RISC, either. And really the entire reason big.LITTLE even exists at all is because the cores got too large and complex. Or, alternatively, they got too "CISC-y". So big.LITTLE is therefore about shipping a "CISC" and "RISC" core on the same piece of silicon really.

zozbot234 4y ago
These things have nothing to do with CISC vs. RISC. Apple's special x86 compatibility is about TSO model of concurrency, which though quite strong and straying far from more RISC-like approaches to concurrency (the Alpha memory model was even abandoned in more recent architectures as too weak) is not especially 'CISC' either.
klelatti 4y ago
> So big.LITTLE is therefore about shipping a "CISC" and "RISC" core on the same piece of silicon really. You're mixing up ISA and implementation. To the extent that RISC / CISC has any meaning at all any more it's a property of the instruction set. RISC-V which makes a big deal out of being RISC is after all just an ISA. And I take issue with the original article on this too.

Animats 4y ago

> They are simpler to decode One of the big headaches with x86 superscalar machines is that finding the instruction boundaries is hard. The decoders, looking ahead, may guess at alignment and decode bytes which represent a totally bogus instruction, which causes work that gets discarded further downstream. Intel and AMD did this very differently in the early days of superscalar. If you're going to have a variable length instruction set, it would be nice if it worked like UTF-8, where you can start anywhere in a stream and get aligned within a few bytes. x86 is not like that.