>>1
First of all, Yentl x86 is an insult to the word CISC. Many of the most influential computer architectures of all time: System/360, PDP-11, VAX, PDP-10, and others are very well-designed CISCs that are much nicer to program for than the disgusting Yentl Architecture. Most of these have such regular instruction sets that each hex/octal opcode corresponds exactly to the same operation, register, or addressing mode, no matter what the instruction is. Second of all, Jews cannot innovate like Goyim can. Even Yentl's original 8008 was a copy of the Datapoint 2200 terminal CPU designed by the (Goyish) Computer Terminal Corporation. >>2
That's what Yentl wants you to think. In fact, all of the prefix bytes and extended opcodes make any instruction that wasn't designed for compatibility with 8-bit processors much longer than it needs to be. SSE instructions are at least four bytes and are two-address. All AltiVec instructions are only four bytes and are three-address. What may require three instructions (at least twelve bytes) of SSE could be done with one instruction (four bytes) of AltiVec.
>>7
The VAX ISA was terrible, which is why DEC threw it away instead of trying to make it go fast (worst case 9 memory accesses per instruction, encoding that places the first needed part last etc).
In the high performance bracket, instruction decoding is such a small part that CISC/RISC doesn't matter. Caches dominate the transistor count no matter what.
In the microcontroller end the game is completely different, and you're competing with 40-year old architectures that are going to be simpler than whatever you come up with now. ARM made big news when their Cortex-M0 core became competitive with 8051 chip area-wise.
Name:
Anonymous2012-01-16 1:47
The success of x86 is the ultimate triumph of solid engineering over ivory-tower academia.
The success of x86 is the triumph of ultimate solid enterprise-quality xml-ready scalable synergetic get-the-shit-done worse-is-better ivory-tower computer engineering over academia.
Most of these have such regular instruction sets that each hex/octal opcode corresponds exactly to the same operation, register, or addressing mode, no matter what the instruction is.
Have you looked at the x86 opcodes in octal?
>>2
Also don't forget a processor that saturates the databus with instruction fetches will leave very little bandwidth for everything else that wants to use it.
>>19 Have you looked at the x86 opcodes in octal? The authors of 8080 and 8086 references (including Intel's own references) are apparently not aware of the octal nature of their own machines, and the result is an almost grotesque complication and bungling up in the presentation of something that is actually fairly simple. Thus, people claim that it's almost impossible to know 8086 binary by heart, whereas in fact I know most of it by memory. I'll straighten out the mess for you here. http://www.lpjjl.net/pgm/fichiers/docasm/OPCODE.txt
Why does Intel present the opcodes in hex which makes it look ugly and haphazard instead of in octal as it was designed to be?
Name:
Anonymous2012-01-16 14:21
>>24
People aren't very familiar with octal. The Intel engineers might've never noticed that themselves when they were designing, even though they figured 3 bits = enough for all GP regs they didn't think it would be octal digits.
>>24
I memorized most opcodes the same way, but in hex. I feel pretty stupid for not realizing I should've been using octal in the first place, now.
Name:
Anonymous2012-01-16 14:35
>>25 People aren't very familiar with octal.
When the 8086 came out in 1978 there were more computers that used octal in their descriptions than there are today. People familiar with programming would have known octal, and there's no reason why learning octal would be any harder than learning hexadecimal. Unix escape codes typically used octal instead of hexadecimal. The PDP-10 and PDP-11 manuals wrote everything related to instruction formats in octal, and they had 8 registers too.
Most of the problems with x86 are because Microsoft decides to only half-ass use Intel's features so Intel has to reinvent the feature that works with Microsoft Windows but still has to keep the old features in future versions of the chip. The rest of the problems are because although short-sighted designs like x87 and MMX get replaced by superior versions like SSE, Intel never removes the old features so the opcodes get longer and longer in a reverse-Huffman encoding where the shit nobody uses is one byte long and the optimized instructions Intel wants you to use are five or six bytes long. Intel or AMD could have replaced all x87 and slow 8-bit decimal opcodes with shorter forms of SSE in 64-bit mode, but they didn't.
>>29
Your compiler is awful or your code is unusual if it isn't generating mostly 1 and 2-byte opcodes (with the occasional 5 or 6-byte instructions that have 4 byte immediates.)