ES-64 Architecture (Open Hardware)

I’ve been looking into a native 64 bit architecture design of late ES-64 for the future of 64 as a default. The boot into 32 and 16 is history but frequently done. Trying to flip some design ideas on the head is one thing, but a central build repository is so easy these days. Easier than the VHDL. The aim is eventual code, but at the moment it’s a spreadsheet in PDF format, and an allocation space. Enjoy if you want to sell your hairdryer to the zero share landfill or paid recycling dedopter point.

The initial instruction set looks good for general coding and I decided to at the outset make a large number of opcodes be no operation, giving a certain way to expand to 32 and 48 bit opcodes. It’s inspired by the 68k but has a more RISCy feel. Most addressing modes were sacrificed to allow general operations on Word, Long and Quad as well as Float and Double. Bytes were not considered much apart from some Unicode helper instructions. The machine is word addressed.

A large part of the opcode space was opened up by sensible ideas about stability of certain operations on the PC. So a 20 register machine results with a lot of free opcode space, and a lot of reserved prefixes for things like vectors. A software model for simulation is likely before any VHDL.

The main focus on code density to open data cache bandwidth means some aspects of RISC have to be ignored. A memory to memory model is used instead of a load store model. This can be more dense for things like one off data loads, as the load and indirect are done in the same instruction without the extra bits in code. Quick literals are limited to 5 bits and come with a built in operation. This reduces register requirements and with general width operations 64 bit registers can easily split into 2 times 32 bit register halves or 4 times 16 bit register quarters. Most code will fit well, perhaps as 16 bit threaded code with a few virtual memory pages multimapped for common subroutines and a springboard for 32 and 64 bit subroutines.

The code generator might be more complex with bucket 64k assignment and routine factorization, but that is a task a machine can do well. There are reasonably efficient methods of code factoring to reduce binary size.

Author: Jacko

Technical. Well is mass information conservation the reason for dark energy via uncertain geometry and photon exchange? Is dark matter conservation of acceleration with a gradient field heavy graviton? Does the KODEK work yet?