Yet another instruction set update

Some time ago, when fiddling with my Monitor/OS program I decided to make a few changes to the instruction set. I guess that’s the real flexibility when you build your own CPU – if you don’t like the instruction set, and you suddenly come up with a need for an instruction that is missing, you simply add it, hardware permitting. I know this is not the right way to do CPU design, and instruction set architecture (ISA) should be a cornerstone to CPU design, not the other way around. On the other hand, what I am doing is not a real CPU design, but a cool hobby project, so I am free to do whatever I want, within reason.

I don’t have any spare opcodes anymore, so the change involved removing instructions with fancy indexed addressing modes with 16-bit offsets, which were (or seemed) not very useful as they have their more useful 8-bit versions. Instead I added four instructions to load and store bytes to code memory, and a couple of 8-bit arithmetic instruction that were missing, and lack of them was quite painful. Now it seems strange to me that I hadn’t added them to the instruction set in the first place (POP AH and POP AL really seem to be must-have instructions at the very first thought). All in all, here is what I removed:

And here’s what was added instead (note different opcodes used – apart of replacing instructions I also made an overall layout change):

Of course, any ISA update requires rebuilding the microcode so I am publishing today a complete instruction set description in excel spreadsheet, new revision of microcode source, and compatible assembler. All new files are downloadable from here. A complete instruction set reference has also been updated on instruction set page.

Although I am releasing this update today, I am sure now that it is not the last revision of the instruction set. Recently, I have started reading the LCC book (see this post) in a preparation for porting a C compiler. It is very probable that this process will reveal further flaws in my ISA and I will need to rework it to streamline code generation.

Another issue I have realized is a bit more serious and is related to how user mode programs call (or will call) OS routines (or software interrupts) by using SYSCALL instructions. Here is how I currently call software interrupts when in supervisor mode:

.text

  ld dp, msg_hello
  syscall KRN_UART_PSTRNL

.data

  msg_hello db 'Hello World!',0

This code snipped prints a string to a VT100 serial terminal with a newline character. As an input, the programmer must provide an address pointer to a zero-terminated string by using DP register (global data pointer). It works great within supervisor mode, because the SYSCALL does not have to switch CPU modes. However, when executed from user mode, SYSCALL switches context to supervisor mode in order to start executing OS routine KRN_UART_PSTRNL, effectively losing access to a string referenced by DP register (because data memory is already supervisor, not user data memory at that point). I may solve it by detecting in the OS service routine that it is being called by a user mode program (by looking at the MSW mode bit on the stack) and performing memory page switching to access the user mode data. Or I may add new instructions to the instruction set, allowing supervisor mode code to access user mode data segments without the necessity to swap supervisor mode memory banks. The latter seems more appealing to me now, but it will require not only ISA update, but also a small change to the hardware. I would need a new signal to override the machine mode flag of the MSW. This signal would only be asserted by the new instruction’s microcode and would force the memory system to access user mode banks and data, even though the CPU was in supervisor mode. I will set this aside for a while to see if I come up with a better solution.