todo.txt

// THERE IS A BUG IN n_overflow calculation in all three simulators. Need to re-check real hardware, probably
// it is designed wrong. No wonder I couldn't get greater than to work! (right?)



// RUST Idea Graveyard

// RUSTFIX Actually, why not just require that you be explicit?
//
//         If we enable `ConstWordCoercedToByte`, ensure that a) we are only inserting a resolved placeholder with b) a value
//         which fits in a byte and c) is not over-qualified in its number of digits. We check this last thing by passing-in
//         X, the maximum value which the constant C could be if a) all its digits were made maximum and b) Y, if its highest digit was
//         made zero and all other digits were made maximum. The formatted number is acceptable only if:
//
//              1. X still fits in a byte, so the number of digits used is clearly byte-size, or
//              2. C > Y, so that we need the last digit to express the number (this is still assuming that C fits in a byte as required above).
//
//         Of course a specific (h) or (l) suffix overrides this.











  Where do we use floating levels?:
    * In the implementation of TST
    * In the implementation of the byte-store-with-zero instructions
    * During IO instructions which take a few cycles to complete

    - So, if we want we can remove, but I think this is a really bad idea if the design is to have all of these CMOS components passively connected and acting on clocks.



  REMAINING HARDWARE TO SIMULATE:


    * Is there any reason at all that we would want to be able to trigger an interrupt on the CPU using something like an INT instruction? No, right, because
      we can always just write to the PIC to command this! Ok that's cool.



      (We could make the BIOS write enable jumper a bit in this io register as well if we want. (and add a test for being able to write to bios memory))






    * A type-checked language to record the microcode would prevent silly mistakes like using a GCTRL_ALT_xxx and GCTRL_NRM_xxx
      operation at the same time, whereas right now you just get bit soup.
    * Perhaps at the same time, consider modelling the hardware ucode decoder----can we change around some existing modules to make
      this work directly?---I think ALU is unchanged, but MEM has changed. We could even simuluate the REG IU->CHIP translation
      by emulating the in/out signal lines to each chip

      The rest of the bits (the CTRL/GCTRL ones) can be split into two further categories; 1) directly relating to operation of the
      RIP management stuff and control register management stuff---i.e. conditional jump decoder, IHPR/FG register loading/control, etc,
      and 2) the ad-hoc mutually exclusive stuff which have their tendrils making minor tweaks in many of the previous described submodules.





  Instruction/ucode design:

    * Compress ucode! (should we really do this anymore at this point?)

    * MOAR TESTS





  Assembler improvements:

    * Allow a const in either argument in e.g. a STW (but not e.g. LDW)

    *  Remove direct access to %rid in the assembler; at the moment the only legitimate usage is saving/restoring in an interrupt handler,
    and in this case we can just roll a custom version of PUSHFG/POPFG to also push/pop it? (actually, there might be
    some problem with decrementing RSP a second time during the push? I think the ALU will be able to do the math
    simultaneously instead?)




  VM UI:
    * Write a post-processor for the disassembler to try to collapse aliases.---this isn't super hard, just search
      for aliases which begin with the first actual opcode, and then continue checking ahead for matches.
            ---> It would probably be best to do this after loading and before executing the binary, so that
                 we don't get confused when we are in the middle of a few instructions all part of the same alias.

    * Of course then we can do the same for families.


  In the VM:

    * (For below, really, how is the physical hardware implementation going to work compared to what we have now implementated?)
       In particular, there is no IO controller buffer at all right now, which works great for directly exposing registers,
       so investigate if this direct-method could work when we want to talk to something like a serial chip.

    * Also, for the IO bus use bus hold devices to decouple them, instead of having a silly intermediate IO controller register
  (but remember we want the IO modules to be able to asynchronously call in their results and move on with their lives)












HARDWARE:

  USE 74HC193 for COUNTERS!!!!

  Remember for designs:
    * Remember, BUS_A and BUS_B should both be pulled low.
    * WE ADDED HARDWARE INC AND DEC COMMANDS TO RSP. AND THE RSP INC/DEC MECHANISM IS COMPLEX, OCCURING A HALF CYCLE BEFORE (check the timings work out).
    * We are hardware latching the ucode in mod_ctl

    * PROHIBIT MOV %rx %rx in hardware (it would be undefined)
            -> I think what I had here was way too complex---just have an output signal to each register inhbit an input signal? Yeah, there are only 8.




  Bugs in current revisions:
  * ALU: the high bits of the switch connecting BUS_B
        to the ALU flags register float!!!!
    ALU: It also has two floating gates!!!

  Improvements for future revisions:
  * remove the zero registers from the REG module? (or, can we change the VM code so that we never use a pull-down behaviour?)
  * mod_alu: OR and AND are swapped physically on the board vs the mode signal numbers




  Need to think more:
  * Originally improvement thought, but then I remembered:
    mod_mem: allow 1-clock word reads and writes. -> If you have this, you can't write into RA using the address in RA---so forget it?