Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

17273757778160

Comments

  • Rayman,
    I went through the same puzzle, have a read of it - http://forums.parallax.com/discussion/comment/1400122/#Comment_1400122

    I'm not sure replacing the descriptive "lower" made any diff. I'd grok'd it by that stage anyway.
  • I compared the documentation spreadsheet with the file called "instructions_v16.txt" inside the zip file.

    There is one less instruction (JEVENT) and four MNEMONIC differences between "instructions_v16.txt" and spreadsheet (XLS):
    TXT,    XLS
    ---     ---
    ANDF,   AND
    ORF,    OR
    XORF,   XOR
    NOTF,   NOT
    JEVENT  (missing)
    

    Are the scripts developed by Chip and Seairth still available for this task?
    Currently how opcode testing is being done?

  • cgraceycgracey Posts: 12,205
    edited 2017-02-28 - 10:19:16
    Ramon wrote: »
    I compared the documentation spreadsheet with the file called "instructions_v16.txt" inside the zip file.

    There is one less instruction (JEVENT) and four MNEMONIC differences between "instructions_v16.txt" and spreadsheet (XLS):
    TXT,    XLS
    ---     ---
    ANDF,   AND
    ORF,    OR
    XORF,   XOR
    NOTF,   NOT
    JEVENT  (missing)
    

    Are the scripts developed by Chip and Seairth still available for this task?
    Currently how opcode testing is being done?

    I realized the JEVENT instruction wasn't going to work because the hardware used the D-field instruction bits, not the D-value bits, so I took it out.

    Fortunately, PNut.exe uses AND/OR/XOR/NOT. It's just the instructions_v16.txt that is wrong. You can get rid of those four "F"s in that file. Sorry about this.
  • I just updated the top post in this thread with v16a, which added 'NOT D' to PNut.exe and fixed typos in instructions.txt, where ANDF/ORF/XORF/NOTF were wrongly listed for AND/OR/XOR/NOT.
  • RaymanRayman Posts: 10,068
    edited 2017-03-01 - 17:30:40
    Just updated garryj's minimal USB code to V16a by just changing:

    setb --> bith
    nob --> bitn
    clrb --> bitl

    Seems to work with just that change.
  • Here's the file...
  • jmgjmg Posts: 14,180
    cgracey wrote: »
    I just updated the top post in this thread with v16a...

    Can you add separate version numbers for FPGA image (v16, 25 Feb?), Assembler/Tools (v16a,28 Feb?) and Documents (v?) to #1.
    That way everyone can see what parts have been updated, and what remains stable.

  • RaymanRayman Posts: 10,068
    edited 2017-03-04 - 17:13:28
    One think left to be documented is the REP loop, I think...

    Would be nice to have a list of what is not allowed inside the REP loop.
    For example, I can't remember if jumps are allowed or not...
  • Wondering about the labelling of SETR and ALTR...

    Not sure what the "R" in SETR stands for.
    But, it looks like these are bits that define the instruction, right?

    The R in ALTR must be different as it stands for "result".
  • potatoheadpotatohead Posts: 9,957
    edited 2017-03-04 - 21:29:54
    Explicit jumps not allowed, nor are nested REP instructions.

    That's what I recall.

    Conditional execution is allowed, just not an explicit program flow change.

    On JMP, REP dies. Program continues.

    Pretty sure a JMP can be in there, ignored conditionally, and on condition met, exits REP circuit.





  • Within a REP block, a branch will cancel the REP. REPs cannot be nested.

    The "R" in "SETR" does stand for "result". It's bits [27:19] which get used for the result field in D, to be employed by ALTI.
  • Ok. Thanks.
    Any hint as to how this "result" thing works inside?
    Doesn't this overwrite the bits that define the instruction?
  • This must be some kind of pipeline trick, right?
    The instruction must already be in the pipeline when this write is made, right?
  • Rayman wrote: »
    This must be some kind of pipeline trick, right?
    The instruction must already be in the pipeline when this write is made, right?

    Right. It modifies the next instruction that is about to get decoded. It just mux's in alternate data for various bitfields from the instruction that is currently executing. It's "pulling a fast one".
  • cgraceycgracey Posts: 12,205
    edited 2017-03-04 - 23:01:55
    Rayman wrote: »
    Ok. Thanks.
    Any hint as to how this "result" thing works inside?
    Doesn't this overwrite the bits that define the instruction?

    For the purpose of the ALTI instruction redirecting the result register, the "R" field was just "made up". You're right, it uses what would be the instruction bitfield in an instruction long, but the D register serving this purpose is not also an instruction. It's just three 9-bit pointers: R, D, and S.
  • I guess I'm slow today... Feel like I almost get it, but not quite...
    In your doc examples there is this:
    ALTR    pointer        ‘set next write to pointer
    XOR     INA,INB        ‘write INA^INB to register[pointer]
    

    Does this actually overwrite the XOR instruction bitfield?
    Would it have to be restored before using it as XOR again?
  • evanhevanh Posts: 8,626
    edited 2017-03-05 - 00:03:38
    That's the difference between the SETx and ALTx instructions. SETx's read/modify/write the stored location (D is address) of the instruction in RAM. ALTx's modify (Both operands can be used) the subsequent prefetched instruction in the pipeline. RAM isn't touched.
  • I like to think of ALTx's as prefixes that just happen to produce an instruction variation rather than a different instruction.

    AUGx and SETQx I've been calling prefixes too but they are a little different again in that the instruction they affect doesn't have to be the subsequent one.

    Chip,
    There is an awful lot of differing SET instructions. I feel a level of clarity could be imposed here.
  • Rayman wrote: »
    I guess I'm slow today... Feel like I almost get it, but not quite...
    In your doc examples there is this:
    ALTR    pointer        ‘set next write to pointer
    XOR     INA,INB        ‘write INA^INB to register[pointer]
    

    Does this actually overwrite the XOR instruction bitfield?
    Would it have to be restored before using it as XOR again?

    Usually, the D field of an instruction sets the result register. At the time the instruction gets decoded, though, the result register begins to be tracked separately, allowing an alteration to occur.
  • I guess it's not so bad. SETQ is the only other four letter SETx mnemonic. It could be SETQ1 to match up with SETQ2 ... Or SETQR and SETQL ...?
  • evanhevanh Posts: 8,626
    edited 2017-03-05 - 00:39:03
    My attempt: - The D field of an instruction sets the result register address. Meaning the CogRAM address that the ALU result is deposited into.

    EDIT: Another wording: The D field of an instruction selects the register to deposit the result in.
  • Ok, thanks. I think I'm getting it.

    Still wondering about "SETR" though. Seems it won't really have anything to do with where the result goes unless it's used with ALTI.

    Is SETR intended to be used mainly on an ALTI instruction?
  • Rayman wrote: »
    Is SETR intended to be used mainly on an ALTI instruction?

    That's about all it's useful for. It initializes a field in a register that ALTI uses as its D operand.
  • RaymanRayman Posts: 10,068
    edited 2017-03-05 - 16:46:15
    Ok, I see now an example for SETR in the docs:
    SETR    inst,op        ‘set reg[27:19] to op[8:0]
    NOP                ‘first spacer instruction, could be anything
    NOP                ‘second spacer instruction, could be anything
    inst    MOV     x,y            ‘operate on x using y, MOV can become AND/OR/XOR/etc.
    

    This makes sense to me, it is changing the type of instruction.
    But, the terminology seems strange... I think I'd call this the "I" for Instruction field.
    These are mostly the bits called "INSTR" in P1 manual.

    Anyway, I think it's a different kind of "result" register from ALTR.
    Maybe it's the same under the hood somehow though...
  • I forget... were command-line options added to PNUT?
  • Seairth wrote: »
    I forget... were command-line options added to PNUT?

    No.
  • I like the P2 MIN and MAX instructions, very useful.

    But, just like the limit max in P1, I think they are backwards...

    Guess I'm used to C++ where if I do max(3,5), I'd get 5 back.
    In P2, if you do MAX with D=3 and S=5, D stays 3.

    If I'm seeing it right, anyway.
  • It seems right. Destination should be result value right?

    Source is value to be operated on.
  • The difference is that in PASM, MAX can be seen as follows:
    D = (S > D ? D : S)
    

    In C/C++, MAX can be seen as follows:
    D = (S > D ? S : D)
    
  • Rayman wrote: »
    I like the P2 MIN and MAX instructions, very useful.

    But, just like the limit max in P1, I think they are backwards...

    Guess I'm used to C++ where if I do max(3,5), I'd get 5 back.
    In P2, if you do MAX with D=3 and S=5, D stays 3.

    If I'm seeing it right, anyway.

    That "feels" backwards.
Sign In or Register to comment.