Fixed up the commit logic a bit. Branch instructions were updating the branch logic with taken/not taken status and address even if they were stomped on instructions. A test was added to ensure stomped on instructions do not update the branch logic.

Also, commit was modified to allow stomped on instructions to be committed. Previously a commit was allowed only for valid instructions. This caused the commit logic to stall during boot.

Milestone: the CPU does the jump instruction at the reset vector in simulation. The JMP instruction executes in the front end avoiding most of the execution pipeline.

Milestone: instructions are making it to the instruction dispatcher now. This can be seen as the dispatcher causes an unimplemented instruction fault.

Bug Fixes:
Got an unimplemented instruction exception on the first instruction executed after the jump. This turned out to be an issue in the decode of the execution pipeline available to the instruction. The function returning the execution pipeline was returning only a single bit and it should have been a bit vector.

Found a bug in micro-op queueing. A buffer was only half the size it needed to be causing ‘X’s to be returned for the buffer value. The buffer is accessed as upper and lower halves. While the lower half is being processed, the upper half is being loaded and vice versa.

It took some doing but I think I have got the ‘hwi’ pipeline signal fixed. It was showing up as an ‘X’ but now is a constant zero. I had to un-beautify some of the code. Signals were being generated in multiple “always” blocks, something done to compartmentalize code, but simulation seems not to follow the order of the always blocks in the translation unit when processing. Some signals depended on signals in other always blocks. I moved everything into the same always block in the desired order and that seemed to fix things.

ISA Mods
Added conditional set instructions back into the design in a limited fashion. The unconditional set instructions are named beginning with an ‘S’ followed by the condition. They set a true/false value in the destination register. These instructions are called ‘zero-and-set’ (ZSxxx) by the MMIX processor which distinguishes them from set instructions that set the register only if the condition is true. Conditional set instruction in Q+ begin with a ‘CS’ followed by the condition and set the register true only if the condition is true.

True is often -1 rather 1 in many older languages. Can you handle that case?

No, not currently. A NEG operation would be required after the SET to get -1 or 0.
It may be possible to add the capability to set the value to any value for true, and zero if false. There is some opcode room free yet.

Micro-ops are not making it through the extract stage properly. Some of the decodes are zeroed out for some reason.

Improved the way IRQ’s work, reducing the IRQ latency. Program flow changes to the IRQ routine in the extract stage when an IRQ is detected, IRQs are treated like branches. Previously the program flow did not change until the IRQ reached the commit stage. However, there is an issue of what to do if an instruction just before the IRQ disables interrupts. In that case the IRQ is treated like a branch miss. A second issue is if the kernel IRQ vector was changed. That case is also treated like a miss.

Vectoring is very simple. There are only two vectors: a hardware interrupt vector and a system call vector. Once the IRQ routine is reached software must decide how to handle the interrupt. Likely the interrupt controller would be read to determine the cause and then a jump table used.

Are fast IRQ's really need in a modern cpu?
It was needed to emulate a virtual machine, that gave the illusion of many threads at once.
Now that one has space on the the FPGA, might it be better to have more hardware like I/O processing
and message passing in the O/S? I/O Hardware could be designed also message pass. I am thinking
of MINIX here. It had two main treads, Software and memory/io blocks. Fast service on things like serial
I/O would have ample FIFO for a slow irq service.
PS. Can one even find how to information on a generic USB device handler?

I wonder the same thing. At a GHz instruction rate does it really matter if the IRQ takes 100 clocks, instead of 10? It would still likely be serviced fast enough, especially if things are FIFO’d. Maybe it matters for a hard real-time system, but that is not the target application of this core.
Need a good book on USB for USB device handlers. I would use USB to serial (or parallel) translators. Much easier to work with RS232 style signals.

It looks like the decode zero out is due to the pipeline advancing improperly causing the next instruction to overwrite the current one. The Rs1 field was supposed to be zero, but for the next instruction. I think a signal (rd_more) needed to be latched and combined with an enable. So, a latch has been put in. If it worked won’t be known until tomorrow sometime.