As If We Needed Another ISA

[straight_stewie]

Just for fun and because I'm insanely bored all the time, I've decided to engage in my biggest project yet. Designing my own processor (again). But this time, a useful one. As a result, I've been reasoning about how things should work. I have come up with a few rules:
 

1. The processor should have four addressing modes: literal, direct, indirect, offset. Every combination of these (even stupid ones like comparing two literals) should be available to the user.
2. Each operand of an instruction should be able to have it's own addressing mode. See above^^
3. The processor will provide two modes: User and Kernel
4. All operands are a machine word in length, even when that is unnecessary
5. The processor will be a memory to memory architecture. The only registers available are special registers and are only used by instructions that interact with them (like Add With Carry uses the carry bit of the ALU status register)
6. The ISA will be extensible in a very similar fashion to RISC-V.

So far, I think that I have figured out all base implementation (the equivalent of RISC-V I instruction set) user mode instructions. Some of them may require some explanation, if so, please ask here, or comment on the Google Docs Sheet (comments are available to all, modification is turned off).

I am here because I would like to request a review of what I have done so far, to make sure that I am not just being stupid about this. So without further ado, here is the google sheet describing the instructions (without the overhead of defining the opcodes and layout of each instruction).

https://docs.google.com/spreadsheets/d/1YbXXdnwypTIhidhWjaN3ePKw8-3nCelIXGKGTNUbtZ4/edit?usp=sharing

So, am I headed down a good path or am I making stupid decisions? Why?

[Unimportant]

4 hours ago, straight_stewie said:

Every combination of these (even stupid ones like comparing two literals) should be available to the user.

Seems useless. Any literal on literal operation can and should be precomputed, saving both storage and execution time in applications, not having to store and execute useless instructions and reducing design complexity. Any problem that can be handled in software for free, or even to benefit in this case, should be. The compiler can handle such precomputing. Software is easier to copy and fix then hardware.

 

4 hours ago, straight_stewie said:

The processor will be a memory to memory architecture.

Consider that such an architecture requires memory access to all operands of a instruction at the same time. A simple instruction such as "A = B + C" would require 3 pairs of memory data and address busses, with the enormous complexity that implies (what if 2 operands happen to be in the same physical memory chip? Multiplexing so each memory chip can be switched trough to each possible bus, etc). Having less busses would require first reading in required operands and storing them in a temporary space before the instruction can be executed, aka a register.

 

On top of that, should your design turn into something serious, such a architecture would prevent implementing a caching system, your design forever tied to it's memory speed.

 

Haven't had time to read the google doc yet.

[straight_stewie]

7 hours ago, Unimportant said:

Seems useless. Any literal on literal operation can and should be precomputed, saving both storage and execution time in applications, not having to store and execute useless instructions and reducing design complexity. Any problem that can be handled in software for free, or even to benefit in this case, should be. The compiler can handle such precomputing. Software is easier to copy and fix then hardware.

There is the case where, in a Princeton Architecture, literal does not equal constant. For example (given that ADDlld adds two literals and stores it in the address, and assuming that the instruction layout is 16 bits of opcode and each operand is 32 bits):

 

ORG 0x00 // Tells the linker to start placing code at address 0

start:
ADDlld .1, .0, 0x64 // Adds the decimal numbers 1 and 1, stores the result in hex 64
ADDdld 0x11, .2, 0x11 // Increments the address 0x11 by two
GOTO start

The output of this program (address 0x64) will be the odd numbers in order, even though the first instruction is adding literals. However, you are correct that it is semantically stupid, I take it that this is enough to mean I should disinclude semantically stupid combinations?

 

7 hours ago, Unimportant said:

Consider that such an architecture requires memory access to all operands of a instruction at the same time. A simple instruction such as "A = B + C" would require 3 pairs of memory data and address busses, with the enormous complexity that implies (what if 2 operands happen to be in the same physical memory chip? Multiplexing so each memory chip can be switched trough to each possible bus, etc). Having less busses would require first reading in required operands and storing them in a temporary space before the instruction can be executed, aka a register.

This is not necessarily the case. The instruction "pipeline" (really just a queue) I implemented seems to stay ahead of the processor, atleast on my FPGA. this is an artifact of the on die memory controller in my FPGA being able to run at a much higher clock frequency than is generated by the Logic Block array clocks. Of course this means that any actual implementation wouldn't work this way. But there are plenty of (older) architectures which are memory to memory architectures. 

It is possible to build an intelligent pipeline/cache. It just requires giving it enough knowledge to know how many operands each opcode specifies and to go ahead and pick them up. It also requires knowing about conflicts (like the example that I showed above). The latter is enough of an issue to convince me that you are correct about allowing instructions that make decisions on or otherwise act on multiplicities of literal values.