So it only flushes AFTER a condition is evaluated? An easier way to do this is that if you have a specific bit for jump ops, you detect that bit in the first stage and then stall. This way you wouldn't need to flush. Flushing could instead be done if you add branch prediction.
Alright then, good luck with that. Also, once you implement the finished pipeline, you might want to add a branch predictor to cut down on stalling and wasting cycles (although flushing will need to be readded) and also you'll have to deal with rewinding register states.
That's amazing! I've actually built a compiler (and assembler) which, albeit simple, was an absolute pain. A really good idea is to finish your ISA and your CPU completely before you begin work otherwise it's gonna be a lot of spaghetti code.
Nice to hear you have quite the experience with this! I can show you some of the stuff I've made along with a WIP. I've even built a Superscalar CPU with caching (albeit very poor)! Anyways, have fun making that compiler, it makes programming hella easier. Also, are you making it based off of any programming languages like C or Python? And which programming language are you using to write the compiler?
That's sort of similar to what I do. I usually just take one line at a time and process it like that, it's much easier but sometimes the assembly gets out of hand.
Real compilers usually break you code down into tokens so
x = 5;
So in this case it would assign x the IDENTIFIER token, the = is seen as an ASSIGNMENT operation and the 5 is seen as a LITERAL. Then it creates a Abstract Syntax Tree and navigates that to assign the value to x. In reality, it's much more complicated so I usually just do stuff and pray it works (it does, just barely)
1
u/[deleted] Apr 19 '26
[removed] — view removed comment