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 // 4
1: 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"
printstr
instead of:
push 'a'
printchar
push 'b'
printchar
push 'c'
printchar
This 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 return
Yes, not only do i have a Forth CPU, but it's microcode is also programmed in Forth!
:-)
Bytecode
Last thing to explain in this list is the 'bytecode'. This is a subset or at least very similar to assembler opcodes, only that instead of the opcodes it uses enumerated codes for instructions. Bytecode is the code loaded from driver eeproms on the K1-bus extension cards and is translated to assembler opcodes by the microcoded boot loader after reset.
