OSDev.org

CISC wins (less contention & less power expended, plus you don't waste a physical register)

You're forgetting about the complexity of the decoder. Because CISC architectures have more addressing modes their encodings become more difficult to demangle. The increased complexity of the decoder increases power consumption.

The approach to designing a dream CPU needs to be based on practical requirements instead of theoretical ideas.

What should be done is to profile existing high performance simd code (SSE, Neon, Altivec) and determine what the most common opcodes are.
Then optimise the CPU for those opcodes.

In terms of other CPU design features (paging, memory coherency etc) just provide a simple but high performance implementation.

What should be done is to profile existing high performance simd code (SSE, Neon, Altivec) and determine what the most common opcodes are.
Then optimise the CPU for those opcodes.

We do this already It's the main step in designing an iteration on an ISA.

JamesM wrote:We do this already It's the main step in designing an iteration on an ISA.

Who exactly is "we" and which specific ISA are you referring to?

I think Intels new AVX instructions are 4 or 5 bytes per opcode - I wouldn't classify that as "optimised".

tom9876543 wrote:

JamesM wrote:We do this already It's the main step in designing an iteration on an ISA.

Who exactly is "we" and which specific ISA are you referring to?

I think Intels new AVX instructions are 4 or 5 bytes per opcode - I wouldn't classify that as "optimised".

"We" as in "everyone who has an ISA design of their own", pretty much...

As for the size of AVX... I'd like to see you find a way to cram them into the x86 opcode map that makes them smaller...

OK I didn't realise you had actually created your own ISA.
That is certainly an interesting idea but it would never be built unless you have a couple of million dollars spare.

AVX shows exactly why x86 is a bad design.

What should be done when designing a CPU ISA is to research AVX/SSE instructions and make the ISA as efficient as possible for the most common AVX/SSE instructions.

The cell CPU takes an interesting approach for this purpose. Instead of infesting the general ISA with SIMD instructions, they create separate cores with their own ISA that handles SIMD processing. Maybe this is the way to go. In practice you could add any type of core like DSP cores and such.

AVX, SSE and so on are all extensions and do not exactly integrate into the x86, so naturally they seem out of place. Cell on the other hand was specifically developed with multiple cores in mind.

tom9876543 wrote:

JamesM wrote:We do this already It's the main step in designing an iteration on an ISA.

Who exactly is "we" and which specific ISA are you referring to?

ARM, and ARMv8.

tom9876543 wrote:That is certainly an interesting idea but it would never be built unless you have a couple of million dollars spare.

Actually, it is possible to make working prototype with not very bad performance in FPGA for about $1-3k.
For proven and ready VHDL/Verilog description it is possible to make shuttle for 90-180nm ASIC on a good fab (TSMC for example) for a sum of about ~$20-80k.
If the ASIC prototype works OK, then you may order the set of production masks for a sum of about ~$100-300k and start production.
That won't be actually couple of milion dollars.

The cpu alone is not important,is the whole ecosystem .Arm is interesting but there is nothing like a standard pc with Arm,all these Arm devices are incompatible between them.I think that Arm will replace X86 in the near future ,but now is not for hobbyist.

Usefulness is defined by availability of devices, documentation, and the whole set of deployment tools. x86 may be an architectural mess, but it's still much more accessible since people would have to deliberately buy an OSDev capable ARM device. Until these raspies become common good, ARM < x86 and would even dare to claim that ARM < AVR.

Combuster wrote:Usefulness is defined by availability of devices, documentation, and the whole set of deployment tools. x86 may be an architectural mess, but it's still much more accessible since people would have to deliberately buy an OSDev capable ARM device. Until these raspies become common good, ARM < x86 and would even dare to claim that ARM < AVR.

With regret, I agree.

octavio wrote:The cpu alone is not important

That's why I think that before designing the CPU there should be performed a large and complicated work which includes at least the following steps:
- Detailed analysis of most important present architectures and ideas;
- Writing emulator of architecture;
- Writing (porting) macro-assembler;
- Writing (porting) a compiler;
- Porting a set of libraries and performance tests;
- Profiling the execution of tests;
- Making conclusions, changing concepts or details and starting next iteration from emulator to profiling;
- After a few iterations you may decide if the new ISA has a good potential and hasn't major design flaws.
Now you are ready to start Verilog/VHDL design.
Of course, HDL implementation may reveal that your ISA ideas are impossible to implement in hardware .
But if all be OK, youl get not just a bare piece of stone, but a good software bunch in addition.

berkus wrote:

octavio wrote:but now is not for hobbyist.

It's probably much more suited for hobbyist use than x86.

If I developed a hobby embedded-like computer from scratch by using standard electrical components (a tough task!), I would choose ARM. Not that I know much of the ARM, just a basic instruction set. At least in hardware point of view for the embedded systems, it is probably much more suited for hobbyist. Just like berkus said.

Now that I am just playing around with the PC software, the x86 feels a lot easier. With a very little knowledge, everyone can have a "Hello World OS" for their x86 PC. I don't currently even know where to get an ARM-based machine that is "open enough" to do that. I don't mean the "a-toy-computer-toolkit" but "real systems". Jailbreaking a closed proprietary system would be one way, maybe.