Put some work into the compiler today. Worked on support for coroutines and altering output to be compatible with the standard vasm syntax. Added support for a couple more instructions (LEA, CSRRW) to the assembler. Documented the string instructions.

Reading about LISP, I came across the term Cactus saguaro Stack. A data structure not found in
C or C++. This seems to be more a coroutine or a strange languge feature, that may require a linked list
style stack, thus another subroutine call / exit instruction. Ben.

Saguaro Stack, that is a new term for me. I understand it as creating multiple parallel stack branches from a single stack frame. It would require allocating stack memory from the heap for each branch.
When setting up the compiler to support co-routines I took the easy way out and have the stack pointer value for the co-routine passed as an argument to the coroutine() keyword. That way the compiler does not need to deal with stack allocations and it is pushed back onto the programmer to decide how a stack gets assigned for the coroutine. I also took the simple approach of storing state data as global variables created by the compiler. I had thought that the stack and state could be stored in heap allocated memory but that puts more emphasis on the compiler controlling things. There could be performance issues with calls to heap allocation for simple coroutines. Moving the language further away from the hardware.
To support Saguaro stacks perhaps the keyword could be used with any routine to indicate it is using a Saguaro stack approach. I wonder that routines using parallel stacks could be executed at the same time by multiple cores. A parallel stack would localize data allowing parallel execution of code. I am reminded of fork().
For coroutines one approach I considered was having two entry points to a coroutine. A setup entry point and a run entry point. To reach the setup entry point the coroutine would be called via a normal function call. Setup would allow the stack and initial state to be established. To reach the run entry point the yield statement would be used. This creates an issue with startups. If the setup entry point later calls yield for another coroutine before that coroutine was setup, then the program would crash. So I thought it best to stick to a single entry point.
To get coroutines into the compiler was looking a bit like C++ classes to support coroutines. With a coroutine constructor, coroutine run methods and finalizers, etc.
It is a lot of fun to work out and I should probably research it some more.

The core makes use of a modified version of the bus interface unit (BIU) of ANY1, so I was able to get instruction fetch up and running quickly.
Moved the EXI41 opcode up a row in the opcode map to 0x6C from 0x7C to keep row 0x7x empty, but I forgot to change this in the assembler. SIM then ran into a snag when it hit the wrong opcode.
Forgot to implement the TLB instruction, which is one of the first instructions executed by the core. Only a subset of Thor’s instructions is being implemented. Just enough to get the boot going in SIM and perhaps light the LEDs. More and more will be added to Thor as time progresses.

I found the mention of this reference kind of interesting. A "Saguaro Stack" has been a part of the Burroughs B5x00/B6x00 line of mainframe computers since their introduction circa 1962. I've never had the pleasure of working on one of these machines, but these stack machines, along with the Inmos Transputer, have inspired several of my FPGA-based ALU projects in the past few years.

My initial internet search of the definition lead to the NIST Dictionary of Algorithms and Data Structures. Unfortunately its definition of the term did not provide any link to the Burroughs machines for context. A reference on the data structures inherent to the Burroughs computers, including the stack, is provided in the monograph: "Computer System Organization: The B5700/B6700 Series", Elliot I. Organick, Academic Press, 1973.

Excellent reference, Michael! A search for "block-structured processes and the b6700 job" turned up results for me.
Edit: in fact see here on textfiles in a mirror of bitsavers.

Got several small fixes in place, mostly having to do with the loop counter. Running SIM out just until the code to light LEDS. No LEDS yet but close.

Evil Laugh That is because I have them ALL
I am building a front panel at the moment and using 5 mm clear white leds
at 5 ma each. Warm white leds are what I really wanted, now that I think about it.
Being fluorescent, I am hopeing they will give more a incandecant bulb feel to
the lights display, when displaying cpu information compared a regular led display.
Ben.

One of the immediate prefix instructions was not decoded properly leading to invalid constants and resulting in a TLB miss.
Put a delay in the TLB miss signal to suppress the miss until after the TLB ram has had time to read. False TLB misses were being generated when the input address changed due to the ram’s latency.
Changed the TLB from managing 16kB pages to 4kB pages.
Implemented shift operations.
Finally got ‘AA’ to appear on the LED output in SIM. And got ‘AA’ to appear on LEDS when running in the FPGA.
Text controller output is busted.

Another day of fixes.

Managed to get text output from the text controller now. The output mux was little messed up due to the addition of multi-color text mode.
Now that ‘AA’ appears on the LEDS a more sophisticated test program is needed. I am re-using the test program from rfPower (nPower), which is supposed to move sprites around on-screen. The test program is written in cc64. Currently there is an issue linking the file due to the incorrect address being used.

The core hung in a bus state from which there was no exit under the given conditions. Conditional logic was modified to allow an exit. Loading a segment descriptor did not need to run two bus cycles because the entire 256 bits could be read from the cache in one cycle.
Added the LEA, LEAX instructions to the core.
The MOV instruction was not encoding correctly.
The BFEXTU instruction was not implemented. This led to zero being loaded into registers during a move instruction since move is a special case of the bitfield instruction.
Bitfield instructions were not enabling the register write signal.

Added a triple prefix fault. If there are more than two prefix instructions in a row a fault is generated. Added some support for vector instructions. It should be possible now to execute simple vector instructions like ADD or OR, but it has not been tested yet.
Branch instructions were branching relative to the fetch stage IP instead of the execute stage IP.
After fixing the branch instructions, flashy LEDs appear, a three second down-count is displayed, then things hang again.

The CSR instruction was not writing to the register file. This led to an infinite loop on a return instruction as the link register was not restored properly.
Simple call and return from subroutine work.
Branch instructions were encoding all operands as if they could be relocated. This has been fixed so that only the branch target is treated as a relocatable operand. The operand number is tracked to determine the branch target operand.
The Tb field in instructions with a ‘B’ operand was not being decoded in all cases.
Included branch prediction in the core, but then forgot to have it branch on the prediction. This caused some branches to fail at the execute stage.

Long immediate forms of the SET instructions were not writing to the register file.
Had to disable some constant optimizations done by the compiler. An index register was being optimized away in an indexed store operation and it should not have been. The fix does not look simple at this point.
The text screen location was moved to 0xFF800000 but the debug console routines were not updated resulting in screen updates failing.

One of the constants for the CSR register selections was wrong. This caused the link registers to be inaccessible. This led to an infinite loop trying to return using an invalid link register value.
Constants for bitfield operations were incorrect. This led to MOV instruction failing.
Put a couple of stall cycles in for CSR updates which do not have register bypassing. The stall cycles allow time for the CSR registers to be updated before any potentially following reads.
The read-only CSR instruction was not implemented in the assembler.
Pipeline stalls needed to be inserted for when the load target was used in the next instruction.

The SUB instruction was not encoded correctly. This led to issues with values stored on the stack.
Added the code for the STSET, STMOV instructions. STSET and STMOV re-fetches the same instruction until the loop counter is zero. Each time STSET is executed it increments the store address and stores data to memory. STMOV is similar. STMOV can be used to move a block of memory.