Shop Learn
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 16 — Parallax Forums

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

11314161819160

Comments

  • ElectrodudeElectrodude Posts: 1,440
    edited 2015-10-13 18:29
    Seairth wrote: »
    cgracey wrote: »
    Seairth wrote: »
    Chip,

    Can you answer this question:
    Seairth wrote: »
    So what is the difference between @ and #@ and ##@?

    "@" means the-address-of-in-hub.

    "#@" means the-address-of-in-hub, in an immediate 9-bit constant. It had better fit!

    "##@" means the-address-of-in-hub, in an immediate 32-bit constant (20-bit, really). It will always fit!

    I think someone accurately answered this earlier.

    Possibly, but with the latest changes, I've lost track. Taking this a bit further, what is the difference between:

    # and #@
    ## and ##@

    edit: And where would you use @ instead of #@ or ##@?

    #, ##, and @ are all completely separate operators. # means the same as it does on the P1. @ is the same as P1 @@@ (like @ but add object offset). ## is like # but uses AUGS to make values > 9 bits fit.

    Try "##(0+(@x))". It should do the same thing as "##@x".
  • RaymanRayman Posts: 12,172
    edited 2015-10-13 18:55
    Couldn't one still manually do a ">>2" on the address and a "SHL 2" on PTRA if one wanted to expand to $3FF?

    Or, you could just use it to pass some generic parameter...
    cgracey wrote: »
    Those nine bits would only reach to $1FF. Remember that we are not forcing long alignment for instructions, like some would prefer, so that we could reduce the PC's by two bits. Those 9 bits count bytes, not longs.

  • RaymanRayman Posts: 12,172
    edited 2015-10-13 18:58
    Sorry, my post got stuck somehow...
    Was about to say that I was starting to like the new forum but now can't delete my duplicate message...
  • Clear descriptive mnemonics are a lot easier to learn (and read) when working with code that a single one with a bunch of non descriptive conditional symbol characters attached.

    Example A___ = Absolute mode, R___ = Relative mode, I___ indirect mode, etc.

    They can be grouped together in the documentation with the differences identified. With some standard labeling this is clear across multiple instructions (common theme).

    Since a major target here is educational use making things as easy as possible for beginners would seem to be a priority. Gurus already know this stuff like the back of their hands and sometimes forget how something so easy for them can be very hard for a new programmer.




  • cgraceycgracey Posts: 13,611
    edited 2015-10-13 19:47
    It looks like the DE0-Nano might fit three cogs, but no CORDIC.

    I should have this ready soon.

    Does anyone have a DEO-Nano, no add-on board, but still have a PropPlug? Without a PropPlug, the DE0-Nano won't work.
  • cgracey wrote: »
    It looks like the DE0-Nano might fit three cogs, but no CORDIC.

    I should have this ready soon.

    Does anyone have a DEO-Nano, no add-on board, AND a PropPlug? Without a PropPlug, the DE0-Nanos won't work. You need a PropPlug to make it work.
    I have two DE0-Nanos and several PropPlugs. On the other hand, don't make a build that doesn't require the add-on board just for me. I have a DE2-115 board as well as a 1-2-3 A7 board that I can use if I can't use the Nano.

  • jmgjmg Posts: 14,812
    edited 2015-10-13 20:14
    cgracey wrote: »
    ...The assembler takes care of the absolute/relative decision now. It uses absolute addresses for cog <--> hub branches and relative addresses for cog <--> cog and hub <--> hub branches.
    That sounds a good convention.

    Just curious, is a relative opcode silicon-valid to go COG->HUB and HUB-> COG ?
    ie does that work, even though Assembler convention will not usually do that ?

    I also presume
    JMPREL Reg
    can go to/from any code space ?
  • cgraceycgracey Posts: 13,611
    jmg wrote: »
    cgracey wrote: »
    ...The assembler takes care of the absolute/relative decision now. It uses absolute addresses for cog <--> hub branches and relative addresses for cog <--> cog and hub <--> hub branches.
    That sounds a good convention.

    Just curious, is a relative opcode silicon-valid to go COG->HUB and HUB-> COG ?
    ie does that work, even though Assembler convention will not usually do that ?

    I also presume
    JMPREL Reg
    can go to/from any code space ?

    It does work! It just seems reckless if anyone made movable code.
  • What does jmprel #reg mean?
  • cgraceycgracey Posts: 13,611
    Seairth wrote: »
    What does jmprel #reg mean?

    That would jump forward by the number of instructions that is the register address. Probably useless. Only the "JMPREL D" has any run-time value. "JMPREL #constant" could be used to set up some compile-time functionality, though.
  • jmgjmg Posts: 14,812
    edited 2015-10-13 21:36
    cgracey wrote: »
    jmg wrote: »

    I also presume
    JMPREL Reg
    can go to/from any code space ?

    It does work! It just seems reckless if anyone made movable code.

    I can see a use case for boundary crossing JMPREL Reg for 'fast case' into COG and error/rare case into HUB.
    I'll admit not common, but good to know it works.
    Seairth wrote: »
    What does jmprel #reg mean?

    IIRC JMPREL Reg is a PC relative jump for things like fast table-case statements.
    could also be written
    JMP PC+[Reg]
  • Cluso99Cluso99 Posts: 17,948
    Agreed, seems to me that JMP or CALL relative to cross hub/cog boundaries is reckless and asking for trouble. I might go so far as saying it should result in an error/warning.
    Actually the same goes for wrapping hub/cog spaces too. It's most likely an error and likely to corrupt cog or worse still hub.
  • cgracey wrote: »
    Seairth wrote: »
    What does jmprel #reg mean?

    That would jump forward by the number of instructions that is the register address. Probably useless. Only the "JMPREL D" has any run-time value. "JMPREL #constant" could be used to set up some compile-time functionality, though.

    To avoid mistakes, maybe you should use the L bit to implement a true JMP D (instead of an alias for CALLD).

  • cgraceycgracey Posts: 13,611
    Seairth wrote: »
    cgracey wrote: »
    Seairth wrote: »
    What does jmprel #reg mean?

    That would jump forward by the number of instructions that is the register address. Probably useless. Only the "JMPREL D" has any run-time value. "JMPREL #constant" could be used to set up some compile-time functionality, though.

    To avoid mistakes, maybe you should use the L bit to implement a true JMP D (instead of an alias for CALLD).

    Good idea.

  • cgraceycgracey Posts: 13,611
    Support for the DE0-Nano bare board with PropPlug has just been added at the top of this thread.
  • TorTor Posts: 2,010
    edited 2015-10-14 02:04
    cgracey wrote: »
    Does anyone have a DEO-Nano, no add-on board, but still have a PropPlug? Without a PropPlug, the DE0-Nano won't work.
    I have a nano, but no add-on board. But I have a PropPlug.
    Although I won't be able to play with this until after Nov. 11 (location change), but if possible it would be great if I could, even without the add-on board which I don't have.
    Edit: Ah I see an image has already been created while I was still reading and answering older posts. Thanks Chip.

    -Tor

  • Chip
    Confirm both DE0_Nano configurations working OK .
    Thanks for the new images. :)
    Cheers
    Brian
  • cgraceycgracey Posts: 13,611
    edited 2015-10-14 02:52
    ozpropdev wrote: »
    Chip
    Confirm both DE0_Nano configurations working OK .
    Thanks for the new images. :)
    Cheers
    Brian

    Brian, thank you for testing those.
  • Cluso99Cluso99 Posts: 17,948
    Thanks Chip. Hoping to try it tomorrow :)
  • Seairth wrote: »
    To avoid mistakes, maybe you should use the L bit to implement a true JMP D (instead of an alias for CALLD).
    I think that's a good idea. I like it better than using "CALLD INA, D".

  • What if you call RDFAST and then WFLONG or WRFAST and then RFLONG, or call WFLONG while in hubexec, or otherwise abuse the FIFO?

    Can you insert an instruction into the hubexec stream by calling WFLONG? Will this mess up the PC?
  • cgraceycgracey Posts: 13,611
    It
    What if you call RDFAST and then WFLONG or WRFAST and then RFLONG, or call WFLONG while in hubexec, or otherwise abuse the FIFO?

    Can you insert an instruction into the hubexec stream by calling WFLONG? Will this mess up the PC?

    WFLONG might insert an instruction. RFLONG might skip one. Try it and find out.
  • cgracey wrote: »
    It
    What if you call RDFAST and then WFLONG or WRFAST and then RFLONG, or call WFLONG while in hubexec, or otherwise abuse the FIFO?

    Can you insert an instruction into the hubexec stream by calling WFLONG? Will this mess up the PC?

    WFLONG might insert an instruction. RFLONG might skip one. Try it and find out.

    Testers: These are great types of things to try and find out. Better to have this know up front and either correctable or noted in the documentation than something people puzzle over when the silicon does it!!

  • An idea for testers and those that have serious questions but no hardware.

    If you think of something that would be interesting to try or might be a really good thing to test, put it into a "TRY ME" thread in the P2 section (with some idea of the code if you can) and one of us with hardware could pick it up and work with you in testing it.

    I'm not the greatest coder but I'm learning P2 and would be happy to collaborate* with anyone on testing interesting things.

    I'm sure we need help from everybody before we can think of everything to test.

    *I get point if I use this word at work!!! :)
  • Chip,

    quick question: are PTRA and PTRB regular cog registers, or are they shadow registers?
  • cgraceycgracey Posts: 13,611
    Seairth wrote: »
    Chip,

    quick question: are PTRA and PTRB regular cog registers, or are they shadow registers?

    They are discrete hardware registers on read and write. Their shadow registers are never used.
  • jac_goudsmitjac_goudsmit Posts: 417
    edited 2015-10-14 21:04
    (deleted)
  • How does ISOB affect C and Z? I seemed to get the same result (C=1, Z=0) whether the isolated bit was set or not.
  • ozpropdevozpropdev Posts: 2,773
    edited 2015-10-15 05:33
    Seairth wrote: »
    How does ISOB affect C and Z? I seemed to get the same result (C=1, Z=0) whether the isolated bit was set or not.
    IIRC
    Z = bit state
    C = not bit state

    Edit: Correction
  • ozpropdev wrote: »
    Seairth wrote: »
    How does ISOB affect C and Z? I seemed to get the same result (C=1, Z=0) whether the isolated bit was set or not.
    IIRC
    Z = bit state
    C = not bit state

    This is what I'm seeing:
    mov     val, ##$FFFFFFFF        'val = $FFFFFFFF
    isob    val, #0 wc, wz          'val = $00000001
    mov     val, #0                 'val = $00000000
    setbc   val, #1                 'val = $00000002
    setbz   val, #0                 'val = $00000002
    
    mov     val, ##$FFFFFFFE        'val = $FFFFFFFE
    isob    val, #0 wc, wz          'val = $00000000
    mov     val, #0                 'val = $00000000
    setbc   val, #1                 'val = $00000002
    setbz   val, #0                 'val = $00000002
    
Sign In or Register to comment.