I have now reorganised the simulation so that I have two competing implementations of the control logic.
- The original one with complicated decoder logic and minimal ROMs and consequently multiple instruction types,
- and also a new (or rather old) approach with a horizontal instruction encoding scheme rather similar to the original design except with many more control lines and with a minimal amount of trivial decoder (74139/74139) logic.
There is a large net saving in control logic chips as expected, at the expense of spreading the instruction over 48 bits of rom. Of course CPU's like the MIPS use narrower instructions but my approach means no tricky decode logic; I can live with that.
A side effect of this redesign is
- there is now only one instruction really "DEVA=DEVB (ALUOP) DEVC" , where devices A/B/C can be any of the devices on onboard and direct vs. register addressing of the RAM or ROM is orthogonal. BTW Right from the opriginal design the jumps are just special devices that conditionally accept the update from the ALU or not depending on status flags.
- it enables direct addressing of the RAM or ROM simulataneously with use of an immediate in the instruction
- "RAM[DIRECT ADDRESS]= DEVICE (+) IMMEDCONST"
- DEVICEA = RAM[DIRECT ADDRESS] (+) DEVICEB
- and so on
This approach doesn't use all the bits in the ROM's. There are few unused bits in the middle and I'm considering whether these might be used to implement conditional instructions like the early ARM chips. Possibly as an alternative to the more common jump approach I'm using already. So room for experimentaiton too.
So I think it's worth it and I'll stash the old more complex control logic approach.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.