New FPGA files for next silicon version - 5th/final release - contains new ROM!!

124»

Comments

  • Just posted 5th/final release at top of thread for what will be built in Prop2 silicon, v2.
  • Flashed v33k images into all 4 boards Ok.
    Will run some boot tests ASAP.
    Melbourne, Australia
  • ozpropdev wrote: »
    Flashed v33k images into all 4 boards Ok.
    Will run some boot tests ASAP.

    Thanks, Ozpropdev.
  • Dave HeinDave Hein Posts: 5,918
    edited 2019-02-21 - 16:16:41
    cgracey wrote: »
    ersmith wrote: »
    cgracey wrote: »
    It's critical, of course, that this latest version of PNut be used to assemble your programs, so that PTRx expression are assembled correctly.

    Wasn't the last proposal for the PTRx encoding backward compatible? It'd be really nice if we didn't have to have separate sets of tools for the P2ES and the next chip :(.

    I implemented what was simplest in logic, because the PTRx computation circuitry was near critical-path and I didn't want to possibly slow things down.

    I need to document what the new scheme is, though you can run PNut and see the output for different expressions. There's not a whole lot to it, and I don't know exactly where it breaks compatibility. Need to look at it.
    So how was the encoding for PTRx changed? Is this how it turned out?
    1S1PNNNNN -16..-1, +1..+15, for NNNNN != 00000
    1S1P00000 +16
    1S0NNNNNN -32..+31
    

  • Dave Hein wrote: »
    cgracey wrote: »
    ersmith wrote: »
    cgracey wrote: »
    It's critical, of course, that this latest version of PNut be used to assemble your programs, so that PTRx expression are assembled correctly.

    Wasn't the last proposal for the PTRx encoding backward compatible? It'd be really nice if we didn't have to have separate sets of tools for the P2ES and the next chip :(.

    I implemented what was simplest in logic, because the PTRx computation circuitry was near critical-path and I didn't want to possibly slow things down.

    I need to document what the new scheme is, though you can run PNut and see the output for different expressions. There's not a whole lot to it, and I don't know exactly where it breaks compatibility. Need to look at it.
    So how was the encoding for PTRx changed? Is this how it turned out?
    1S1PNNNNN -16..-1, +1..+15, for NNNNN != 00000
    1S1P00000 +16
    1S0NNNNNN -32..+31
    

    I don't remember and I'm not at home right now where my computer is.

    If you run the latest PNut that comes with the new'silicon FPGA files, you can look at the encodings.

    Pointer-modifying offsets of -16 to +16 are allowed, while random non-modifying offsets can range from -32 to +31.
  • Dave HeinDave Hein Posts: 5,918
    edited 2019-02-21 - 21:32:07
    I assembled some code with various PTRx indexes, and the results match the description in my previous post. So the v32 encoding is a subset of the v33 if the P bit is set to the index sign bit when the U bit is zero. Currently, the P2 assemblers set the P bit to zero.

    My test code is as follows:
                        dat
                                org
    000  00 00 00 00    r0      long    0
    001  00 01 04 FB            rdlong  r0, ptra
    002  80 01 04 FB            rdlong  r0, ptrb
    003  00 01 04 FB            rdlong  r0, ptra[0]
    004  01 01 04 FB            rdlong  r0, ptra[1]
    005  0F 01 04 FB            rdlong  r0, ptra[15]
    006  10 01 04 FB            rdlong  r0, ptra[16]
    007  11 01 04 FB            rdlong  r0, ptra[17]
    008  1E 01 04 FB            rdlong  r0, ptra[30]
    009  1F 01 04 FB            rdlong  r0, ptra[31]
    00a  00 01 04 FB            rdlong  r0, ptra
    00b  80 01 04 FB            rdlong  r0, ptrb
    00c  00 01 04 FB            rdlong  r0, ptra[0]
    00d  3F 01 04 FB            rdlong  r0, ptra[-1]
    00e  31 01 04 FB            rdlong  r0, ptra[-15]
    00f  30 01 04 FB            rdlong  r0, ptra[-16]
    010  2F 01 04 FB            rdlong  r0, ptra[-17]
    011  22 01 04 FB            rdlong  r0, ptra[-30]
    012  21 01 04 FB            rdlong  r0, ptra[-31]
    013  20 01 04 FB            rdlong  r0, ptra[-32]
    014  41 01 04 FB            rdlong  r0, ++ptra
    015  C1 01 04 FB            rdlong  r0, ++ptrb
    016  41 01 04 FB            rdlong  r0, ++ptra[1]
    017  4F 01 04 FB            rdlong  r0, ++ptra[15]
    018  40 01 04 FB            rdlong  r0, ++ptra[16]
    019  5F 01 04 FB            rdlong  r0, --ptra
    01a  DF 01 04 FB            rdlong  r0, --ptrb
    01b  5F 01 04 FB            rdlong  r0, --ptra[1]
    01c  51 01 04 FB            rdlong  r0, --ptra[15]
    01d  50 01 04 FB            rdlong  r0, --ptra[16]
    01e  7F 01 04 FB            rdlong  r0, ptra--
    01f  FF 01 04 FB            rdlong  r0, ptrb--
    020  7F 01 04 FB            rdlong  r0, ptra--[1]
    021  71 01 04 FB            rdlong  r0, ptra--[15]
    022  70 01 04 FB            rdlong  r0, ptra--[16]
    023  61 01 04 FB            rdlong  r0, ptra++
    024  E1 01 04 FB            rdlong  r0, ptrb++
    025  61 01 04 FB            rdlong  r0, ptra++[1]
    026  6F 01 04 FB            rdlong  r0, ptra++[15]
    027  60 01 04 FB            rdlong  r0, ptra++[16]
    
  • jmgjmg Posts: 13,609
    Dave Hein wrote: »
    I assembled some code with various PTRx indexes, and the results match the description in my previous post. So the v32 encoding is a subset of the v33 if the P bit is set to the index sign bit when the U bit is zero. Currently, the P2 assemblers set the P bit to zero.

    I think you are saying this can be made binary compatible, if the older version assembler is modified slightly, in how it handles unused bits ?
    It would be great if binary compatible of P2 & P2+ is possible.

  • evanhevanh Posts: 7,271
    edited 2019-07-11 - 13:22:00
    Chip,
    Something has niggled at me every time I look at it - The mnemonic naming of SETR vs ALTR. They have entirely different meanings of "R". This doesn't happen with S and D naming. I'd like to see R be reserved for only meaning the Result Register as per ALTR instruction.

    Also note ALTI uses SETR's interpretation rather than ALTR's.

    I'd like to choose a different letter for bitfield [27:19] uses. Conveniently, SETR is the only mnemonic name that would change in assemblers. The rest is all documentation.

    EDIT: How about "O" for opcode?

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • cgraceycgracey Posts: 11,266
    edited 2019-07-11 - 18:39:06
    evanh wrote: »
    Chip,
    Something has niggled at me every time I look at it - The mnemonic naming of SETR vs ALTR. They have entirely different meanings of "R". This doesn't happen with S and D naming. I'd like to see R be reserved for only meaning the Result Register as per ALTR instruction.

    Also note ALTI uses SETR's interpretation rather than ALTR's.

    I'd like to choose a different letter for bitfield [27:19] uses. Conveniently, SETR is the only mnemonic name that would change in assemblers. The rest is all documentation.

    EDIT: How about "O" for opcode?

    I hear what you are saying, but I think there is more to this. I'm not at my computer now, so I can't look.
  • You'll be filling a whole notebook of things to do. :D Good weather I hope.

    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
Sign In or Register to comment.