Fan fact: Like 15 years ago, I implemted a "virtual" 16 bit - CPU in a logic simulator. To make it run larger programs, I needed an assembler. The quickest way, I could do it, was to use Excel to assemble the code. Later I improved it, by using an existing freeware assembler, that could produce machine code for different CPU architectures (6502, Z80 etc.). I don't remember the name of the assembler. I just had to add my selfmade config file, and then it produced code for my "virtual" CPU. The most difficult part was to switch it from 8-bit to 16-bit code output.
That's pretty neat! It's quite nice to have a retargetable assembler that can generate binaries for your new CPU architecture immediately. I do also enjoy the process of writing the assembler from scratch, though. 🙃
Anyone knows how important a three register subtract instruction is? For fast DCT? Operands do not commute. This already uses a lot of encoding space. All flavours need to use the destination as one source ( immediate, reverse immediate, with borrow).
Would you implement an optimizer? Something like removing NOOPs, replacing a chain of consecutive jumps with a single one, stuff like that... or maybe if it sees two writes to the same register in a row, it will only add the second one, since the first one would be overwritten anyways...
That's the compiler's job, not the assembler's. When you code in assembly, you're the boss and that goes all the way. Sometimes NOPs are used for padding you know, for instance to align the first instruction of a loop to the first byte of a cache line. If you wanna have it, you're gonna get it - no compromise. That's also why coding in assembly is considered difficutlt: You usually do it to get some performance but in most cases your C++ version would've run twice as fast because there are many optimizations you wouldn't dream of to know about.
It would be great to look at optimizations at some point. I agree that you generally want to keep an assembler free from optimizations, such that it is truly just a translation between a human-readable and machine-readable form of a program. However, modern compilers perform a lot of their optimizations on an intermediate program representation that looks a lot like assembly, but with a few magic tweaks (infinite number of registers, higher-level operations, each register only assigne once, etc). I'd love to look into that at a later point to see if we can build a simple optimizing compiler ontop of the assembler. One thing that gets old *really* fast in assembler programming is choosing registers to put your data into. The register allocation done by compilers is very useful in this regard, and it would be cool to have a lightweight form of register allocation ontop of the assembly text.
@@fabianschuiki I think a more practically useful way would be to hook your architecture into LLVM so that you can write C++ or whatever you like for your own CPU with your own ISA.
Did anyone ask for the register pair? Reminds me of the painful segments in DOS. Also it is probably bad for code density. Jumps usually use all the bits to encode the condition. Maybe just upgrade the registers to 16bit for larger programs.
Building 16 bit registers for mostly 8 bit data is a bit wasteful. It's only the addressing that really requires 16 bits. Maybe go check out James Sharmans build to get an idea of what's going on.
@@JaenEngineering addressing does not need 16 bit for any toy project ( code you would present in RU-vid). 16 bit instructions already use 512 bytes. Then 256 bytes for stack and zero page (heap). For graphics we have the concept of a cursor and coordinates ( turtle ) to hide large numbers from the CPU. Intel has io ports: another 256 addresses. 16 bit are no waste. In Java half of the variables are objects (addresses) . Just like 68k has 8 address registers and 8 data registers. If we make the base CPU just bad enough, any modifications will look like an improvement. The CPU in the video and Z80 had 16 byte register file. So a fab could produce a chip with 8 registers with 16 byte each. Superscalar 8 Bit was not manufacturable at the Time. I read that packing stuff into pages needs a very slow algorithm, while 16 bit malloc is okay. So you aim at large ROM game cartridges?
Yeah 16 bit registers and more prominently a 16 bit datapath is pretty annoying for a breadboard CPU as it creates a lot of busy work and wiring. I agree that ideally you'd want to have your registers be as wide as possible, and especially have your program counter be as wide as the data path of the CPU. However, 8 bit CPUs sit in this weird spot where you can only address 256 bytes, but any interesting program or operating system effort will require at lesat 16 bit program addresses. So you have to get creative to work around that to some degree. Most 8 bit CPUs still address 16 bit memory regions by playing some tricks with their registers; either having dedicated 16 bit registers (see James' architecture), or by making 8 bit registers fusable into 16 bit registers (my architecture, and x86 to some limited degree). That's less of an issue in 16 bit CPUs unless you want them for actual operating systems and workloads which need >64 kB of memory. And as soon as you are in the realm of 32 or 64 bit CPUs you're pretty much out of the woods. But for a simple breadboard CPU that wants to explore architecture and instruction issuing more than wide integer datapaths, having 8 bit regs fusable to 16 bit addresses seemed reasonable.
The breadboard part is a point I think some people may have missed. It's not quite an issue now but thinking ahead, once we get to sections like the ALU, even at the 8 bit level the hardware becomes complex even if we just stick to basic functions (add/subtract/shift/logic). If we decide to try hardware multiply and divide then even 4bits would require many breadboards each.
@@JaenEngineering then don’t have 16 bit addresses. Ben Eater presented the SAP-1 with 4 bit addresses. For a super scalar CPU we want to reduce dependencies. Register pair is one more dependency. We need the zero register of MIPS ( comes for free in encoding).
It's definitely worthwhile 😀! Especially nowadays in the age of LLVM and the proliferation of interesting programming languages that has brought. Python and other interpreted languages are pretty cool because you get going quickly, but they have an unexpected learning curve because they hide some of the complexity of memory management and by-reference/by-value passing in weird ways. C/C++ expose all of that low-level stuff, but they are very quirky and archaic in many ways. Rust or Zig are pretty good languages to pick up as first languages in 2023; they combine a lot of good lessons learned from C/C++ over the past 40 years. I do have a sweet spot for Rust for many reasons. Awesome community as well to get started.
@@fabianschuiki you've actually bought up an interesting question. Which language? Guess it depends on what you want to do. I'd heard of Python and the various flavours of C, but Rust and Zig are new to me. I'll have to take a look and see if I get along with them. All else fails I wonder if there's a way I can just output an Excel file as a program 😂
