>>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.)
>>43
Because "Companies like HP and SGI have bet the farm on Itanium and they need to do everything they can to make sure it remains a viable alternative." And just like that, MIPS, ALPHA and PA-RISC were killed off.
>>43
Because of the Original Sin: The Abelson betrayed SICP. And masochism in the computer industry.
Name:
Anonymous2012-01-18 16:01
>>40-42
Implementing a Lisp-like on almost any modern architecture is trivial. Writing an OS in the aforementioned Lisp-like is also fairly trivial. Nay, that is not where the trouble resides. It is rather dealing with the not-really-part-of-the-architecture-but-related-to-it quirks is the troublesome part. You know, things like ACPI or PATA/IDE.
Name:
Anonymous2012-01-18 22:09
>>42
Hope u like buggy SoCs with no documentation. The best I've heard of was a MIPS64 implementation that failed to correctly implement the architecture-specified processor ID register, making it impossible for a kernel to automatically work around the rest of the bugs in that particular piece of shit.
>>49
The famous FDIV and F00F bugs. Everything in the Intel microcode update release notes and the other errata Intel secretly fixes for security through obscurity.
>>51
<question type="rhetorical">Then why does Intel still release microcode updates and errata notes?</question>
<question type="rhetorical">Are hardware bugs worked around in software or microcode no longer bugs?</question> http://download.intel.com/design/processor/specupdt/320836.pdf
Name:
Anonymous2012-01-18 23:50
>>52
I expect chips sold by Intel to be reliable but I don't expect them to be bug free. It is tolerable as long as the faults are not grievous mistakes and it'll cause minimal disruption on one's computing. Hardware bugs that are fixed in software (and microcode) are still bugs in the hardware but effectively a non-issue when you actually make use of the features.
>>53
Intel doesn't (can't) fix all of their serious bugs. This is from 2007, but these bugs have no software work-arounds. What are some of these MIPS SoC bugs for comparison? http://undeadly.org/cgi?action=article&sid=20070628134608 Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so.
Name:
Anonymous2012-01-19 1:51
check 'em
Name:
Anonymous2012-01-19 6:48
>>54
I remember just sighing and shaking my head when that post first appeared. It just confirmed my belief that Theo wasn't nearly as smart as he thinks he is, and that he really knows fuck all outside how to avoid simple buffer overflows in C.