I wanna design a processor architecture.
Timeline
Post
Remote status
Replies
14
bonifartius πΌπ 
@cjd did design a very small cpu/computer at uni, that was fun :)
I totally have an idea in mind.
You know the belt from the MILL processor design?
It's that, except reversed.
So each instruction pulls K operands off position 0 of the belt, and there's 1 index in the instruction, and that's the location of the output that will be written to the belt.
Far out the belt is DRAM, close up is cache.
You know the belt from the MILL processor design?
It's that, except reversed.
So each instruction pulls K operands off position 0 of the belt, and there's 1 index in the instruction, and that's the location of the output that will be written to the belt.
Far out the belt is DRAM, close up is cache.
@cjd can you please just screw around with RISC-V extensions like everyone else? π
I guess you could technically do what I want with extensions, but it would just be an extension to add a whole other instruction set... So basically it's just a new processor anyway.
I want to make every instruction asynchronous using a belt where operands are always taken off the close end of the belt, and results are written to wherever on the belt the instruction indicates. In hardware, the close end is a cache and the far end is DRAM.
Then you can do like n way hyperthreading just by interleaving belts.
I want to make every instruction asynchronous using a belt where operands are always taken off the close end of the belt, and results are written to wherever on the belt the instruction indicates. In hardware, the close end is a cache and the far end is DRAM.
Then you can do like n way hyperthreading just by interleaving belts.
Unfortunately this does not solve branch prediction or instruction caching, but there's a reasonable chance that the same general method would be possible for those as well.
Branch instructions would just have to return a result which is thrown to the belt, and that is the branch predictor context which becomes the 2nd operand of the next branch.
Branch instructions would just have to return a result which is thrown to the belt, and that is the branch predictor context which becomes the 2nd operand of the next branch.
@cjd also, isn't that just a Turing machine .. with the principle of the single line of data, except now re-envisioned in stages of memory in a processor pipeline.
@cjd didn't know about mill design, looks interesting on a cursory read.
at uni we did this with programmable logic gates (iirc), very 80s :) but pretty good fun, certainly easy to build a small calculator like poc with those.
at uni we did this with programmable logic gates (iirc), very 80s :) but pretty good fun, certainly easy to build a small calculator like poc with those.
Well, a Turing machine IIRC is reading an instruction tape, and this is about managing operands in memory - whilst giving the compiler some say into how things should work.
But for it to really work, there needs to be a similar design for instructions, to get rid of the icache - this would be more Turing like indeed.
But for it to really work, there needs to be a similar design for instructions, to get rid of the icache - this would be more Turing like indeed.
@cjd i have no clue but from what i've read isn't the belt supposed to be read only save appending to the tail to prevent problems?
In MILL's design, your return value always writes to slot 0 and the belt shifts "away" from you. And instructions have 2 indexes which can select any 2 positions on the belt to grab operands from. And when something falls off the end of the belt, it's lost.
In my design, the belt moves "toward you", meaning the next instruction is going to pull 2 operands off the belt. And the return value is the one you get to decide where on the belt it will fall. So in my design, it's your job to setup the belt so that operands arrive at slot 0 at the same time as when the instruction that needs them gets executed.
In my design, the belt moves "toward you", meaning the next instruction is going to pull 2 operands off the belt. And the return value is the one you get to decide where on the belt it will fall. So in my design, it's your job to setup the belt so that operands arrive at slot 0 at the same time as when the instruction that needs them gets executed.
@cjd with Turing machine, everything's on one tape. The current position points to the next action, essentially. You can move to a different position. Most rudimemtary actions necessary to operate on the tape.
Okay yeah, so it has a jmp insn on the tape. Very classical von Neumann.
Like I said, I'm really not sure how to do instructions. Either you prepare the belt for both possible directions, and then use skip instructions to discard what you didn't need, or you basically spawn a new thread and exit so your belt is swept up in hardware.
Like I said, I'm really not sure how to do instructions. Either you prepare the belt for both possible directions, and then use skip instructions to discard what you didn't need, or you basically spawn a new thread and exit so your belt is swept up in hardware.
*how to do branches
@cjd if you're curious about this, can't you use something like vlsi and a simulator/emulator. You could model the hardware entirely, prly. For example, the picorv32 is fully modeled I think. You could essentially just design the whole thing.