Weird CPU Architectures, the Mov Only CPU (2020)

The Intel architecture is already Turing complete when you just use MOV instructions: https://github.com/xoreaxeaxeax/movfuscator. Of course, you don't even need instructions at all: https://news.ycombinator.com/item?id=5261598

Looks like an interesting read, thank you @v9v.

Just when my night was going through a meditative sleep about basing ontological models using change as fundamental block. Identity is such a brittle choice as foundation, even if it's a great tool in many situations otherwise.

If you were interested in co-designing a CPU with software the TTA is an attractive way to do it, particularly in that it is easy to design it so you can do more than one MOV at the same time and thus have explicit parallelism.

The tough part though is that memory is usually slow and you have to wait an undetermined number of cycles for data to get back from DRAM and while one operation is blocked all the other operations are blocked.

I guess you could have something like this with a fancy memory controller that could be programming explicitly to start fetching ahead of time so data is available when it is needed, at least most of the time.

I've always loved quirky CPU designs like this, and having one layed out in logic gates is amazing.

I'm having trouble running the file though, it's missing a chip, "74181.dig". Can you point me to where to download that or add it to the repo?

There was a CMOVE architecture around 1990 (Israel), I think. It was very similar. Could not find it on internet, sadly.

The MOVE architectures may work best with digital signal processors, because the data-flow is almost constant in such processors.

I invented my own version of the move only architecture (around 1992), but focused on speed. So here is my idea below.

1. The CPU only moves within the CPU, like from one register to the other. So all moves are extremely fast.

2. The CPU is separated in different units that can do work separately. Each unit has different input and output ports. The ports and registers are connected via a bus.

3. The CPU can have more buses and thus do more moves at the same time. If an output-data is not ready, the instruction will wait.

Example instruction: OUT1 -> IN1, OUT2 -> IN2 With 32 bits it would give give 8 units with 32 ports each.

Example of some set of units and ports. Control unit: (JUMP_to_address, CALL_to_address, RETURN_with_value, +conditionals) Memory unit: (STORE_Address, STORE_Value, READ_Address, READ_Value), Computation unit: (Start_Value, ADD_Value, SUB_Value, MUL_Value, DIV_Value, Result_Value) Value unit: (Value_from_next_instruction, ZERO, ONE) Register unit: (R0 ... R31)

It is extremely flexible. I also came up with a minimalist 8 bit version. One could even "plug-in" different units for different systems. Certain problems could be solved with adding special ports, which would work like a special instruction.

I did not continue the project due to people not understanding the bus architecture (like a PCI-bus). If you try to present it in a logical-gate architecture (like in the article), the units make the architecture more complicated than it actually is.

Seems to me this would entirely eliminate many classes of exploits.

This architecture is good for data path applications, but not really for control flow (eg, think how expensive a context switch would be)

That's actually useful as a minimal machine.

It's possible to have a one instruction machine where the one instruction does a subtract, store, and branch if negative. But it's not very useful. This register-oriented thing is something someone might put inside an FPGA.

This is the the device register mindset, where you do everything by storing into device registers, as a CPU architecture.

I'm surprised the article doesn't mention OpenASIP [0], which not only helps you define the architecture, but also provides RTL synthesis and a working (if not always useful) compiler.

[0] http://openasip.org/

I have been playing around with my own design, initially inspired by the gigatron, but it seems to have diverged somewhat. ALU is the same, address unit enhanced, but a lot of the rest, program counter and instruction decode ending up completely different. Shuffling the Harvard architecture to be more like a instruction cache, only 16 bytes of instruction memory with long jumps triggering a full instruction memory load from RAM.

Going for transport triggered architecture for additional features seems like a fairly easy win. I kind of started designing one before I realised that's what the design was. The Gigatron has to do some unreasonably hard work for a few operations, like shift right, which is an operation that can fundamentally be done with just wires once you have a mechanism to provide the input and fetch the output.

Definitely not knocking the Gigatron though. Every limitation it has is because it saved a chip, when it comes something minimal to build upon It's pretty cool.