That's a terrible justification for creating an ISA that's hard to write a code generator for. [...]If you cannot provide an instruction set that compiler writers can easily use
The hardware designers shouldn't be dumbing-down the ISA for stupid compiler writers. Perhaps I should say "misguided" and not "stupid", since the problem seems more that they are not approaching the task of code generation in the right way.
You can't fork or mmap with only a segmentation unit. And please don't say those operations aren't suitable for RTOS use when the most common RTOSes all provide a POSIX layer that uses them.
POSIX is NOT a good specification for RTOS as much as they try to make it one. It's far too heavyweight. True realtime systems often do not even have the concept of a "process", it is closer to threads. (A router running Linux or whatever doesn't count. Embedded != realtime.)
>>62
CISC is about making the interface simpler than the implementation
No, it's about code density and getting more work done per instruction. The VAX often gets mentioned for being "very CISC" bt actually doesn't have that great of a code density compared to x86, with the exception of certain very powerful instructions (but x86 also has things like AES, CRC, etc.) x86 was designed with code density in mind, so that the most common instructions are also the shortest. With the VAX, the 1-byte opcode map contains many of the "very CISC" instructions, like queue insert; this causes the most common instructions to need to be longer. In contrast, x86 puts the more powerful instructions on the 2nd or 3rd page, where they can still provide a gain in code density while not affecting the common ones.
E.g. what if the 1-byte move and 3-byte AES were exchanged? AES isn't done often, so the result is decreased code density since every move is now 2 bytes longer. AES still provides a gain since the equivalent sequence to emulate it would require many more bytes. This is why MMX, SSE, and all the newer stuff reside on the 2nd page --- although their opcodes are a bit longer, they are also less commonly used, and the operations they perform would still require many more bytes to implement if they weren't present.