Im sure this will be fun as there is quite a heated debate on ACC and 3ops with noticable contributers being Eithanz and ACC users. i hope the conclusion can be found in this post lmao.
1op ACC sucks (IMO) 3op CLEARS
Im LordLithium btw
problem is that we generally use register based accumulator arch, and not memory based accumulator arch (memory addressing modes etc). accumulator is more native to memory, where as 3 op is more native to general purpose registers.
hmm what is the reason for using Reg based ACC instead of Memory based ACC in minecraft?
Is it just for easy implementing or maybe just works better in MC or smth.
Any arguments supporting this position? Like imo both arg good, only 2 op is bad because longer instruction, but still need acc load!
2op does not need any sort of acc if one operand is also the store location
generally at least in my exp 2 op is rare coz it hardly fits in 8 bit instruction set length, so then in mc u go to 16 and u can fit 3 op here just as well.
@commodore: yea reg based acc is easiert to implement then mem based but that doesnt directly mean itll be faster
slugdude had this rly cool blazing fast mem-map based thing years ago
speaking of which how to do you fit an instruction within 8bits as from my experience you need 8bits for imm and have only another byte for other stuff?
for 8 bit acc you put the imm on the second byte and have the preceding instruction disable the next word execution and arrange it to be loaded somewhere as a value instead. modifying follow-up instructions is quite easy in a pipeline
and there is nothing stopping you from applying this to, maybe, the next two instructions, and this also works with a 16 bit isa.
maybe one could even do some extra fancy stuff and load a 16 bit isa from an 8 bit bus by clocking the pmem every 4 ticks on an 8 tick cycle. might get away with the second byte being fine with a very short decode time if it only contains info relevant in later stages.
Whether or not is 3op better than 1op with acc depends on the design choice.
First, the accumulator can be designed as separate from General Purpose Registers (GPRs). You can have 8 GPRs addressed with 3 bits and a single ACC independent of GPRs. You can have separate instructions to write to Registers or ACC.
Let’s take the ADD instruction for instance.
With 1op/ACC, you could implement it as:
- the operand acting as the register index to write to (R+=Acc)
- the operand acting as the register index to add with (Acc+=R)
With 3op, it becomes
Ra=Rb+Rc
So you’ll probably need 3 register indices, all occupying 3 or more bits, which would very well take more than a byte for a single instruction encoding.
In general though, if you’re aiming for simplicity, go with 1op/ACC. 3op can be quite hard to implement and can result in a lot of spaghetti wiring. If you’re aiming for a minimal CPU that’s still programmable, 1op/ACC could go long way.
But if you’re aiming for flexibility, performance and features, go with 3op since it means lesser instructions are required to control the data in the accumulator, given that you can utilize multiple registers directly (e.g. store the result in R0, input 1 in R1 and input 2 in R2), which would be a lot more comfortable to write for the programmer compared to 1op.
true true but i heard 3op is best for beginners?
For beginners, 1op/ACC is definitely the answer imo
i find 3ops better for coding i dare say but hardware wise ACC is better
3 op is just more convenient for the programmer to write and is more flexible. I would recommend utilizing 3op if you’re building a feature rich and beefy CPU. For beginners, 1op is good because there’s not too much logic to implement
No need to select two input registers into a buffer then select a register to write to. With acc, your accumulator’s output wires directly as input to the ALU (input 2), and registers as input to the ALU (input 1), with output writing back to either registers or ACC depending on your design choice.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.