+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Projects & Inventions (https://forum.openredstone.org/forum-19.html)
+---- Forum: In Progress (https://forum.openredstone.org/forum-20.html)
+---- Thread: another computer, binary IS question (/thread-5923.html)
another computer, binary IS question - fuirippu - 03-06-2015
I'm building a computer again - improved components, thankyou plot of logic (/warp pol). The architecture is still flexible: I want variable length instructions, some kind of pipelining, possibly a ring bus that routes dynamically with pistons (but that might turn into a contender for Minecraft's most elaborate clock).
I'm wondering if anybody has any advice about instruction set encoding. I'm looking to emulate the instruction set from the 6502.
Quick briefing: 8-bit opcodes, 1- to 3- byte variable length instructions. "Load to" and "store from" the accumulator (register) are examples of group I instructions and can have up to 16 addressing modes.
See how they've done that in the opcode table? LDA and STA have 2 possible values each for HI-NIBBLE (<A0, B0> and <80, 90>) and 4 possible shared values for LO_NIBBLE (<01, 05, 09, 0D>), giving 8 addressing modes.
Am I being arrogant in thinking of adapting this encoding? I'm thinking of what I'd call a simpler-to-understand encoding, like 1 HI-NIBBLE for LDA and 1 for STA. Is it a quirk of a particular physical 6502 implementation that led the designers to encode the way they did?
RE: another computer, binary IS question - Nickster258 - 03-06-2015
Ahh, 6502. Glorious to see you again
.Sounds fun, almost no way to loose going with 6502. About the encoding, I don't see any problems with it, but others may.
RE: another computer, binary IS question - LordDecapo - 03-10-2015
have you done variable length instructions before?
Also, I would suggest getting rid of the bloat inst. In there that you will almost never use. 8 bit opcode can be a bit much to decode each one then encode to the control lines.
5 bit opcode seems to be a good common ground (for MC) between lots of ops and size of system.
8bit opcode CPU in MC would end up being about 50%+ just inst decoding.
One more suggestion about variable length..
I have have used 2 different ideas for there decoding.
1. Have a queue that can variable read (can read from each slot based on the Inst).
Being such that you always have X (X being equal to the max byte size of ur longest inst) lines (bytes) of code stored at any given time.
Decode the oldest value in the queue and based on the op the decoding system chooses how many values to read.
The next clock pulse after that comes, blankly shift (disable read from all the bytes that you used for the prior inst) the queue so you don't double read part of a multi line op in the next cycle.
2. Kinda that way but figure out a way to incorporate that queue into you actual processing stages. For this I ended up moving around the byte layout for my Branch (my longest opcode in byte length) so the bytes would align with my pipeline as to be where they need to be on the stage they are needed.
Option 1 is MUCH MUCH easier... I had to tweak and tweak and tweak that way to work better and better, and in that process slowly went to the 2nd option, by removing 1 stage at a time..
went from a 3 stage queue being before all decoding, to prefetch (decode some before it goes into queue) some of the ops so I would have inst. Data where I needed it when I needed it.
then I removed a stage and incorporated that into my pipeline.
InfaCT I just got rid of the last part of the queue last night all together so my lengths are decoded just as a normal op code. so all ops process at the same rate that a standard ALU op does. (Grant it the multi line gives u x-1 extra cycles to work with since u only read 1 line at a time)
Sorry if that is a TL;DR... for those of you that did TLDR
-Suggest lowering the amount of op codes, 8bit is high IMO
-and look into a queue system thing for the variable length, and tweak that down to where the queue is unnecessary.
Just my little tips/suggestions. Don't have to go by them if u don't want.
good luck on the build! Ask if you would like my help with anything
RE: another computer, binary IS question - fuirippu - 03-10-2015
(03-10-2015, 07:46 PM)LordDecapo Wrote: have you done variable length instructions before?
You appear to see into my frightened soul !!! This is the aspect of my current build I am most fearful of (variable length instructions: 1 or 2 bytes, and variable execution time: up to 5ish cycles).LordDecapo Wrote:Also, I would suggest getting rid of the bloat inst. In there that you will almost never use. 8 bit opcode can be a bit much to decode each one then encode to the control lines.
5 bit opcode seems to be a good common ground (for MC) between lots of ops and size of system.
8bit opcode CPU in MC would end up being about 50%+ just inst decoding.
Excellent advice, thank you. This one I'm already on... I have stripped down the IS considerably. Thanks for the 5-bit suggestion; it's good to have a ballpark figure.
As for the two approaches to decoding variable length instructions, I think I'm looking at something more like the 1st idea, but I'm hoping I don't need a full "instruction queue": just an InstructionRegister (holds currently executing opcode) and a Data/AddressRegister that is only read into when executing a 2-byte instruction. (Yes, arguably this is a 2-slot queue.) I'll only increment the PC when a value is clocked into one of these two registers. Possibly, I can even re-use the InstructionRegister, so that I don't need the Data/AddressRegister.
The ugly/scary part is having some type of state-machine (inside the computer's execution control logic) that tells it what to do on each cycle for each instruction. It feels like I'm building a computer inside of my computer - but maybe that's necessary so that I can build up layers of abstraction.
Thanks again for taking the time to comment and provide guidance - it is very much appreciated, and probably I will have some questions to ask as I finalise the design.
RE: another computer, binary IS question - LordDecapo - 03-10-2015
glad to help.also state-machines arent something i have looked too far into, i know the concepts, but i havent looked over any system layout in depth so i may not be THAT much help on that aspect unless i do some more homework lol
that idea for variable length inst is a great idea! i briefly had an idea like that,, like the first stage decodes the ops and if its a 2 line, it loads the next one in a separate buffer (register) so it only adds that stage when needed.
i got as far with that idea as i said there, i got distracted at work and ended up just thinking of my current idea before i remembered that one again xD (Blame it on my ADHD hahah)
5 cycles is a great goal