Hennessy and Patterson

Ostensibly one of the most widely used books for studying computer architecture so I had a look, and... WTF? Possible future CPU designers are being fed with tripe like this?

http://i62.tinypic.com/xakqr.png

Despite all the focus on MIPS and performance, it is suspiciously missing any real benchmarks of MIPS processors.

They have an interesting definition of a "desktop computer":
http://i60.tinypic.com/4lq2j7.png

"Heineken and Pilsner" would be a better name for this book, as its authors appear to be as knowledgeable about real-world computer architecture as drunken fools.

>>37

stupid design decisions like defaulting to big-endian

You'd think that people who favor minimalist designs would realize how dumb this is.

It took ARM seven revisions to add an integer divide, and it's still considered "optional". Maybe this is OK for small embedded cores but it's absolutely idiotic for something intended to do more computation and be general-purpose.

The flip side of this is ARM was able to get away with doing absolutely nothing for seven generations and their embedded cores remain free from the requirement to retain a crappy divide unit that no one will use anyway. Meanwhile x86 had to keep same around for years and can never be rid of it, even in embedded use cases where they might really want to. Adding slow instructions because you think future generations will be able to do things faster is a bet Intel didn't always win (see: almost every instruction that was added for the 286).

>>37

And the multiple simple instructions take more space in cache and memory bandwidth to fetch.

1. modern caches are huge.
2. simple instructions have orders of magnitude faster execution.

>>42

3. simple instructions take less cache space and easier to cache

>>43

simple instructions take less cache space

False. Your typical RISC instruction set wastes cache space for most instructions because all instructions have the same length, even for common cases where a shorter encoding is possible. Many common x86 instructions occupy only 1-2 bytes; equivalent RISCs use 4 bytes for nearly everything.

>>44

Nothing stops you from using 16-bit RISC

>>44
You got a Thumb up your arse.

>>46
At least mine is not 4 bytes long.

>>39
It's the same one I've been repeating for over 20 years (albeit in slightly modified form) - back then it was mostly prediction, but I knew that raising the clock frequency would have its limits.

>>40
Backwards-endian, minimum length of 2 bytes per instruction, can't use GPRs for memory addressing, and an encoding that is one of the most random ones I've seen (e.g. compare http://goldencrystal.free.fr/M68kOpcodes.pdf , http://i.stack.imgur.com/07zKL.png , and http://www.z80.info/decoding.htm )... it's CISC done wrong, like the VAX.

>>41
The amount of software you can write without ever having to divide is tiny - probably an application better served by an 8-bit or even 4-bit MCU, and when you do have to divide, it's far better for the hardware to have a divide instruction than have to do it manually with individual instructions, because at best it'll be the same speed as a hardware divide instruction expanding to the same series of uops but using more memory, and at worst it'll be both slower and bigger. The funny thing is that although you seem to think embedded aplications don't need divide instructions, the only ARM cores that are guaranteed to have divide instructions are the embedded ones - ARMv7-{M,R}, and ARMv7-R only in Thumb mode.

>>42

modern caches are huge.

That's the sort of idiotic thinking that lead to the wasteful state of software today, and a similar attitude ("the Earth is huge, we can dump whatever into the oceans and atmosphere and it'll be OK") is why the environment is getting fucked up. If we don't realise that all resources are intrinsically limited and use them responsibly, everyone suffers because we're all sharing it. See also: programs that think they can use all the RAM and HDD they want, or that network bandwidth is free, etc.

simple instructions have orders of magnitude faster execution

When you need orders of magnitude more of them, no. Also see what I wrote above about recognising and combining simple instructions to be executed faster by dedicated hardware.

>>45,46
That doesn't solve the problem of every single instruction being the same length, which means that the simpler and more common operations aren't any shorter.

This is what an ARM memcpy looks like:
https://android.googlesource.com/platform/bionic/+/5b349fc/libc/arch-arm/bionic/memcpy.S
https://android.googlesource.com/platform/bionic/+/5b349fc/libc/arch-arm/bionic/memcpy.a15.S
Do we really need all that bloat in the cache? A disgustingly large amount of that code is just for handling different alignment cases, something that the hardware could easily figure out by itself (and ARM has thankfully realised this, later versions do handle alignment in hardware.) It's still no match for REP MOVS, however.

RISC: stupid processors by stupid hardware designers, for stupid compilers, stupid programmers, and stupid users.

>>48
Isn't it wasteful of die area to include loads of ucode for all the functions that aren't implemented in hardware, as opposed to just letting users use regular code to implement them? Users can recompile their damned software anyway when the functionality is implemented in hardware.

>>48
You don't need nor you should be using any other instruction than bit-and/or/xor, jif (jump if the condition is true), a instruction from loading to a register from memory & from the instructions, one to write a register to memory and a final one for communicating with hw

>>49
How wasteful. You only need one instruction (subleq).

>>49
"Wasteful" depends on what you are trying to accomplish. If you have a large installed base of software that can't be re-compiled, adding compatibility features to your hardware starts making more sense.

One thing you may notice is that vendors with complex instruction sets like Intel's don't like to sell small, low cost chips where instruction decode begins to occupy a significant share of the die. They'd much rather sell you an expensive, high transistor count design where the area used by decode is totally dominated by caches, etc.

>>52

software that can't be re-compiled

I don't care about closed-source software.

What do you think is the best designed processor(s)?

>>54
The Symbolics Genera Lisp Machine, of course.

>>55
Processor, not computer. Are you one of those fucks that refer to their computer as ``CPU''

>>55

Symbolics

Angered by this perceived infraction of his privacy, Stallman sent an email to Symbolics threatening to wrap himself in dynamite and blow up their building. Although this caused some panic at Symbolics, Stallman never made good on the threat (Newquist 194-196).

>>56
It's a list processer, twit.

>>58
Your low intelligence and low IQ test scores are evident. faggot

>>59
Stop posting.

>>60
The individual is stronger than the herd (you and your faggot friends).

>>60
Stop posting.

>>62
blah blah you're autistic blah blah