The microcode software is under development. I'm juggling with 5 or 6 types oft software:
- microcode- millicode (yes, that's new!)
- bytecode (new too)
- assembler opcodes in ram
- the microcode assembler
- the microcode emulator (new)
- vipsi script interpreter (found the second bug in it after 5 years) B-)
So, slowly, what are they all about?
Vipsi Script Interpreter
The thing of software which also delivers this web site. The microcode assembler and the microcode emulator are written in this script language too.Microcode
That's obvious, hopefully. The codes actually executed by the control unit. All living starts here. After reset it also is obligued to setup the machine and load drivers and program. There are no other roms in the CPU: the microcode also contains the BIOS.Assembler Opcodes
That's what the microcode is going to implement: Opcodes for a program running in ram. All opcodes are actually addresses of tiny programs in the microcode rom which load the next opcode when they are done::ADD ( a b -- c ) add (hp--) jp (ip++)
Microcode Assembler
The piece of software which reads the microcode sources and creates the hex files for downloading into the microcode roms. It eases my live with flow control instructions, compound instructions, checking, postponing and fitting the code into the roms. That's all not trivial and all very error prone. See what it creates from the above code example::ADD ( a b -- c ) tst_add (hp) // 1 add (hp--) // 2 ld cmd,(ip++) // 3 nop :bit15 // 41: add is too slow, because the carry can ripple through 16 bits until the result has settled. Therefore 'add' and similar opcodes must add a wait cycle, where the inputs are applied but the result is not yet latched.
3: This is, basically, what 'jp' in microcode does: it loads a new address into the microcode address counter, instead of incrementing it.
4: But this is what is required too:
- The next opcode is already fetched by the control unit and will be executed before the jump takes effect
- The feedback line (aka 'flag') 'bit15' is selected to determine in which code plane the jump will actually jump to. In a simple case this would be flag '0' (unconditional plane 0) or flag '1' (unconditional plane 1). But here i use flag 'bit15', which forwards bit 15 from the data bus, so that the jump destination will be in plane 0 (1) if bit 15 of the jump address is cleared (set).
Microcode Emulator
This is the newest piece of software. I'm currently no longer downloading the microcode to the real CPU but to an emulator written in vipsi. The emulator code has ~ 100 lines netto. Debugging stuff and comments increase it to ~ 400 lines currently. The simulator mcsim.vs is located in Software/Microcode/ aside the microcode source.Millicode
One of the best things which are possible in the K1 CPU's microcode is to jump to microcode addresses via table. Huh great! Great?At first it seems impossible to do this. You cannot read microcode cells at arbitrary locations. There is no other source for addressing than the microcode address counter. It is hard to put a string of text into microcode. But, pretty soon, i felt it would be simpler to write something like
pushstr "abc" printstrinstead of:
push 'a' printchar push 'b' printchar push 'c' printcharThis could be solved similar to this:
jsr pushstr dw 'a','b','c',0 jp p3 ... pushstr: jsr allocstr pop a0 // get return address p1: ld cmd,a0++ // jump ld d0,ival :bit15 // already loaded microcode // --- p3: tst d0 jp !z,p2 jsr storechar jp p1 p2: ...I tried to keep the example as short as possible. Microcode execution starts with a subroutine call to pushstr. pushstr pops the return address from the return stack which points to the 'a'. Now it loads the microcode address counter with this address (line p1:) but the next microcode is already loaded and is executed next: This loads register D0 with an immediate value which follows in the next microcode. This next microcode is the 'a' where A0 pointed to. Then the microcode runs through the other data bytes which just consume time but do nothing. Finally it reaches the 'jp p3' which jumps back to the string reading loop. Next time the jump hits the next char, because a0 is incremented each time.
Though this example has lots of room for improvement it shows how 'the impossible' thing works. With a little tweaking microcode can read constant data from the microcode rom.
The next step was to realize, that this works even better if the constant data is not 'data' but code:
ld alu,jptab1 add alu,d0 add alu,d0 jp alu jptab1: jp proc1 jp proc2 jp ...Step 3 was to realize, that not the whole 'jp' instruction must be in the table, but only the address:
ld alu,jptab1 add alu,d0 ld cmd,alu ld cmd,ival :bit15 jptab1: dw proc1 :bit15 dw proc2 :bit15 dw ...The trick are the two 'ld cmd' instructions in succession. It's a combination of the ideas in 'step 1' and 'step 2'.
Ok, and if, now, we use the address register 'ip' (instruction pointer, sic!) to point to the 'table' of addresses and if the addresses only point to routines which, after having done their job, jump to the next address in this list, we have in microcode exactly what assembler opcodes in ram do, and i called this millicode. It is much easier to write programs in millicode than in microcode assembler. :-) Though a little bit slower, due to the linking jumps and because i use a forth-style approach of argument passing on a data stack, like i do for assembler opcodes in ram.
After adding some glue to the microcode assembler, millicode programs look like this:
:DictShrinkToFit ( dict -- ) Millicoded // switch from microcode to millicode mc Dup,DictWordsGet mc Addq dict_word0 mc Resize,Drop mc Next // kind of returnYes, not only do i have a Forth CPU, but it's microcode is also programmed in Forth! :-)
