Designing an 8-bit CPU - 6 - program counter
Вставка
- Опубліковано 18 тра 2024
- This time, I've got my program counter working.
Again, my camera was keen to focus on wires and not the board. I filmed it late and didn't notice until later :( - Наука та технологія
No worries when real life gets in the way of hobby projects. I'm enjoying watching your progress.
Awesome. Thank you 😄
Very interesting project. Thanks for taking the effort to document what you are up to.
Was surprised to see PC relative addressing, as that’s generally considered a luxury on small systems like this is shaping up to be.
Curious whether this will be microcoded or sequenced in a GAL or CPLD, but I suspect it’ll end up needing a fairly wide ROM?
The ALU is also gonna be interesting to see as, again, there’s a fair few approaches.
Anyway, glad I found your project! Looking forward to the next instalment. 😊
Thank you for your comment!
I've already used some GALs because the alternative logic with "pure" 74-series would be cumbersome. (Also, I bought too few of some chips on my last order, so had to use a GAL to compensate.)
I've not played with CPLDs. I think Xilinx is stopping manufacture of the common CPLDs, I guess with the reason being that FPGAs have been a thing for long enough now. I remember seeing a FPGA run the game of life at university, supposedly faster than the contemporaneous Pentiums.
I'm struggling to get time to play with the project, sadly. My work has hit a crunch point and my energy has been zapped.
I will have some significant changes in my next video. I think I'm getting somewhere with the decoding / pipeline design.
Anyway, thank you again and hope you enjoy!
@@phodopus42 just reading about AMD knocking the head on the CPLD. The distinction is certainly blurry now with FPGAs available with nonvolatile storage, which was one of the key differences. But historically CPLDs and arguably even today they have different uses; small amounts of logic that doesn’t justify a FPGA or ASIC. Hopefully Atmel erm microchip will keep manufacturing their Altera MAX7000 clones. I made good use of MAX7000s in my 6809 and later 68000 boards. You can even get them in 44 pin PLCC so you can jam one in a breadboard. One would work in your projects, but the software can be a pain to find these days.
Project burnout is a thing, which is why I try to have two on the go. Hobbies are about having fun, so don’t feel bad having break.
Anyway, take it easy! If you want a look at my crappy channel... You might find something interesting. :)
it's so exiting at all. thanks
Thanks!
You might keep in mind you also want to output the program counter to the data bus so it can be pushed onto the stack before a jump to a subroutine and later read back of course.
This is a very good point! I had forgotten about JSR instructions.
I was going to use a register pair r7:6 for the link address (like ARM uses r14). I'd need a way to get the address back to the register file. It sounds like I have some more rewiring to do
😆
6502 uses the ALU for relative addressing. RISCV uses the ALU for compare. Your branch seems to not use the ALU at all.
Who ever uses PC relative addressing? Is it for switch case? So you have low integers, or a good hash, and then some addresses around your current instruction are filled with function pointers? Why not roughly match the size of case branches and shift left the integer to convert it into an address? Or use the hash? Or just a tree of branches? Hybrid. Ah, optimising compiler.
So it is for switch(enum) only.
In RISCV and MIPS there is only one addressing mode: register+immediate . Register 0 is always 0 . Program pointer cannot be read. All other 31 names are for GPR .
Thank you, interesting thoughts!
ARM uses PC-relative a lot because there's no absolute addressing. It works well as long as you can keep your data close to your code. I remember tricks like putting constants at the end of a function so that they are within the accessible range.
So I was going for PC-relative instead of absolute addressing. It also makes it easier to write relocatable code, which is a real pain on the 6502, not that it matters with no MMU and a 16-bit address space 😮
@@phodopus42 a quick search tells me that this addressing is only used to load Immediates which don’t fit into the instruction. RISCV can load 24bit immediates, enough for the whole address range of a 68000. JRISC just lets immediates follow in the instruction stream like 6502 does it. With 32 registers in RISCV you load each all constants at the smallest block scope. I can see how 16 register Arm wanted to save registers and memory.
@@ArneChristianRosenfeldtI think you might be right. If I have 8-bit registers, then a "load immediate" will suffice for loading constants.
I do need something for code in ROM to access scratch RAM. The 6502 did this by adding zero-page addressing. That's maybe what I will go with.
Thanks again for interesting ideas.
@@phodopus42 high level languages for some reason don’t use a scratchpad, but a stack and a heap. With a base pointer and this pointer (BX in x86?) . 6800 has 16 bit pointers. I may repeat myself here, but RCA showed that 16 * 16 bit did fit on a die, even in somewhat larger CMOS logic.
@@ArneChristianRosenfeldtThere is actually a number of processors that can use the PC as the base register for relative mode addressing. On most cases the instructions to do so are provided just as a matter of encoding orthogonality, not that they are used very often. However there's a critical difference between PC relative and GPR relative modes when talking about Harvard's architecture processors, because the first mode will access program memory while the second one will access data memory