Bugs

There are a few issues that need the Dauug|36 maintainer’s (um, my) attention.

Hazardous timing in control decoder hijack logic

22 April 2024. In May 2023, I had a setup/hold violation going into hijackflop0.d, and I kludged around it by inserting a buffer there. (It works out by adding adding one CPU cycle latency to timer interrupts.) I haven’t considered how many problems this may create that aren’t being tested in simulation. This needs unsnarled before anyone builds a machine.

All byte-write signals are grounded

26 April 2024. This is not a bug, but it’s an urgent change. I suggest allocating four decoder lines to the four byte-write signals (four wires to each chip) for the left and right register file and both data RAMs. Have all opcodes drive these low.

This is a trivial modification (15 minutes?) at this time, but it can’t be changed after boards are manufactured. The change can support future opcodes that modify only (nine-bit) bytes. There are two use scenarios. One is more efficient string manipulation (with nine-bit symbols). The other is a limited set of ALU opcodes with three operands, not now possible because there are only two register files.

This change may not be the last word in (nine-bit) byte handling because under this proposal, the byte position(s) to modify are hardcoded into the opcode. This precludes addressing bytes through a register. More thought could be given to this later.

Flag handling was never considered for numeric constants

14 June 2023. Firmware issue. I haven’t seen this issue show up in existing regression tests, but I am not persuaded that the CPU flags are always correct when immediate values are used. This is a firmware design problem, not merely an assembler or implementation problem.

There are two sub-cases:

immediate values with permanently allocated registers
directly-assigned immediate values that don’t require a register

It is probably necessary to stratify instructions like IMN by signage, because IMN generates the same code for the following two instructions:

signed s
unsigned u

s = ~2                  ; ~ is the assembler's minus sign for constants
u = 68_719_476_734

It’s not typical to check the sign of a constant, but this oversight could show up in a loop condition that is checked before each time the body of the loop is entered.

14 July 2023. This now shows up in the t_speed.a / t_speed.ns regression test. I have commented this test out of the makefile so no one is discouraged if a make netsim-regress fails. The exposed defect is that I overlooked the need to stratify the IMB, IMH, and IMN opcodes by signedness. This won’t hinder most programs, but a program like the following may give unexpected results:

    unsigned x
    x = -1
    j >= positive
    ; ...
positive:
    ; ...

Disclaimer: I haven’t tried the above example. I would rather fix the problem.

Reverse subtraction instructions do not work in the cross assembler

5 July 2023. Assembler issue. In the aslex.c bytecode where numeric constants are considered, a ~ prefix (indicating a negative constant) is checked for. But in the event there is no number present, the ~ is silently swallowed, meaning that the source text ~- and ~-- output the tokens - and --. This is wrong.

Multitasking timer may be uninitialized

11 July 2023. Simulator issue. See NPRIV in the Identity-modifying instructions.

Multiply-defined labels do not halt assembly

20 July 2023. Assembler issue. Looks like the assembler issues a message, but does not exit with a nonzero status?

Label/scope ambiguity

5 August 2023. Assembler issue. Although scopes and labels are afforded their own namespaces by the assembler, resolution now uses them interchangeably due to LCALL and RETURN VIA. Jumps are probably defaulting to scopes, which sooner or later will bite someone.

`YIELD` latency appears to be wrong in docs and `t_coop.a`

8 August 2023. Documentation issue. Looks like three instructions execute past YIELD. I wonder if this changed? I was so confident it was two instructions. t_coop.a works fine if a second NOP is inserted in user program 2, so that the zero check actually straddles the yield. Although I wonder about the coverage of this test... should the forever: loop force the zero flag just to be sure?

`safe.to.write::` may be off by one

22 December 2023. Osmin kernel. According to Memory structures, the protective NOP in safe.to.write:: might be in the wrong location. For nearly all kernel versions a mistake here would not lead to an impermissible overwrite, but the question should be addressed.