Shop OBEX P1 Docs P2 Docs Learn Events
Problems with latest FPGA release — Parallax Forums

Problems with latest FPGA release

ozpropdevozpropdev Posts: 2,792
edited 2014-03-27 19:08 in Propeller 2
Sorry Chip, :(
I'm still having issues with LOCBASE in the new release (24 March 2014)
Expected return result should be $E20 and returns $20.
TYPE: 57   VALUE: 04000E20   NAME: TEST_DATA

bug1			locbase	test_index,@@test_data
LOCBASE converts a 16-bit hub instruction address into a normal 18-bit hub address for use
with RDxxxx/WRxxxx instructions:

        LOCBASE D,@relative9        'get 18-bit hub address from 9-bit relative address into D
        LOCBASE D,@@relative16      'get 18-bit hub address from 16-bit relative address into D
        LOCBASE D,S                 'get 18-bit hub address from S[15:0] into D
Cheers
Brian

Comments

  • cgraceycgracey Posts: 14,134
    edited 2014-03-25 04:07
    ozpropdev wrote: »
    Sorry Chip, :(
    I'm still having issues with LOCBASE in the new release (24 March 2014)
    Expected return result should be $E20 and returns $20.
    TYPE: 57   VALUE: 04000E20   NAME: TEST_DATA
    
    bug1			locbase	test_index,@@test_data
    
    LOCBASE converts a 16-bit hub instruction address into a normal 18-bit hub address for use
    with RDxxxx/WRxxxx instructions:
    
            LOCBASE D,@relative9        'get 18-bit hub address from 9-bit relative address into D
            LOCBASE D,@@relative16      'get 18-bit hub address from 16-bit relative address into D
            LOCBASE D,S                 'get 18-bit hub address from S[15:0] into D
    
    Cheers
    Brian


    Brian, I'll look at this right away when I get into the shop this morning. Maybe I didn't solve the whole problem. I actually didn't even test it, myself, because it seemed so obvious to me what the problem had been. That was a mistake! I'm sorry. We'll have this working in the next several hours.

    I also want to see if I can get COGNEW to fail like potatohead experienced.
  • cgraceycgracey Posts: 14,134
    edited 2014-03-25 14:08
    It looks like this is an assembler issue!

    I re-ran the LOCLONG tests from yesterday and they DO PASS now, so that hardware fix was good.

    What we are left with is an assembler issue handling @@ properly. I'm working on this now...
  • cgraceycgracey Posts: 14,134
    edited 2014-03-25 14:50
    Brian,

    The assembler seems to be fine, after all.

    If, in your example, 'test_data' was declared under an ORG (instead of an ORGH), it would be a cog address, and not a hub address. That would explain what's going on. You'd need to declare it under an ORGH to make it work right.
  • SapiehaSapieha Posts: 2,964
    edited 2014-03-25 16:08
    Hi Chip.

    BUT how about if I write in ORG declare but will address HUB @@SD_Table

    cgracey wrote: »
    Brian,

    The assembler seems to be fine, after all.

    If, in your example, 'test_data' was declared under an ORG (instead of an ORGH), it would be a cog address, and not a hub address. That would explain what's going on. You'd need to declare it under an ORGH to make it work right.
  • cgraceycgracey Posts: 14,134
    edited 2014-03-25 17:03
    Sapieha wrote: »
    Hi Chip.

    BUT how about if I write in ORG declare but will address HUB @@SD_Table


    The only thing that has to be under an ORGH is the data that will be accessed via RDxxxx/WRxxxx instructions, since you can't use RDxxxx/WRxxxx to access cog RAM - only hub RAM.
  • cgraceycgracey Posts: 14,134
    edited 2014-03-25 17:42
    At this point, after figuring out potatohead's COGNEW problem, I don't know of any unresolved bugs. There are likely some lurking, though.
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-03-25 17:48
    cgracey wrote: »
    Brian,

    The assembler seems to be fine, after all.

    If, in your example, 'test_data' was declared under an ORG (instead of an ORGH), it would be a cog address, and not a hub address. That would explain what's going on. You'd need to declare it under an ORGH to make it work right.
    Thanks Chip,
    That was it. I assumed that all addresses would be "treated" as HUB addresses.

    So the lesson here is for data in "COG" mode use the conventional way of reference
        mov myreg,_mydata
    
    
    _mydata    long    @mydaya
    

    and for "HUB" mode use the new
        locbase myreg,@mydata
    
    Got it. :)
    Cheers
    Brian

    Post Edit:
    LOCBASE converts a 16-bit [color=red][b][I]hub instruction address[/I][/b][/color] into a normal 18-bit hub address for use
    with RDxxxx/WRxxxx instructions:
    
    Cheers
    [/code]
  • Bill HenningBill Henning Posts: 6,445
    edited 2014-03-25 17:56
    Chip,

    There should be a way - a prefix of some sort - of obtaining the hub address corresponding to where the long was loaded from in the hub.

    Given that '##' is already used for large constants/addresses for other instructions, how about having PNut understand that

    LOCBASE myreg,##mydata means use the hub address corresponding to mydata's cog location, and perhaps even
    LOCBASE myreg,@@mydata for the relative equivalent?

    I can see wanting to use longs "underlying" a cog in the hub.
  • SapiehaSapieha Posts: 2,964
    edited 2014-03-25 17:56
    Hi Brian.

    COG and HUB mode that is OK.

    BUT how I address that in MIXED mode?

    ozpropdev wrote: »
    Thanks Chip,
    That was it. I assumed that all addresses would be "treated" as HUB addresses.

    So the lesson here is for data in "COG" mode use the conventional way of reference
        mov myreg,_mydata
    
    
    _mydata    long    @mydaya
    

    and for "HUB" mode use the new
        locbase myreg,@mydata
    
    Got it. :)
    Cheers
    Brian
  • cgraceycgracey Posts: 14,134
    edited 2014-03-25 18:20
    Chip,

    There should be a way - a prefix of some sort - of obtaining the hub address corresponding to where the long was loaded from in the hub.

    Given that '##' is already used for large constants/addresses for other instructions, how about having PNut understand that

    LOCBASE myreg,##mydata means use the hub address corresponding to mydata's cog location, and perhaps even
    LOCBASE myreg,@@mydata for the relative equivalent?

    I can see wanting to use longs "underlying" a cog in the hub.


    I agree. I need to make a flag for the constant resolver in the assembler, so that when one of these LOCxxxx instructions is looking for data, it always uses the hub address, and never the cog address.
  • ozpropdevozpropdev Posts: 2,792
    edited 2014-03-25 19:56
    Chip
    Is it possible in future FPGA releases to have a release date or version id readable by Pnut to verify current loaded version.
    Jumping back and forth from different releases to cross check tests can sometime get confusing.
    This also applies to Pnut as well to match the loaded FPGA release. This would help greatly. :)
    Cheers
    Brian
  • potatoheadpotatohead Posts: 10,261
    edited 2014-03-25 21:19
    Seconded. I got caught on the wrong Pnut already. Had put it where the code for it was, and when porting to new image got snagged.
  • cgraceycgracey Posts: 14,134
    edited 2014-03-25 21:52
    ozpropdev wrote: »
    Chip
    Is it possible in future FPGA releases to have a release date or version id readable by Pnut to verify current loaded version.
    Jumping back and forth from different releases to cross check tests can sometime get confusing.
    This also applies to Pnut as well to match the loaded FPGA release. This would help greatly. :)
    Cheers
    Brian


    I'll start using the ROM Monitor intro message for that, and match it with the associated PNut.
  • Bob Lawrence (VE1RLL)Bob Lawrence (VE1RLL) Posts: 1,720
    edited 2014-03-26 07:31
    I got caught on the wrong Pnut

    I did that a few times so I re-named all of my pnut.exe files to include the version numbers.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-03-26 12:22
    Just found the LOCPTRA #font problem (in my Nokia 5110 driver) where I didn't have the font table in a separate ORGH section. Fortunately I found it by removing the orgh after I had the code working ;)
  • msrobotsmsrobots Posts: 3,709
    edited 2014-03-27 15:39
    I just added syntax highlighting for P2 PASM to the online editor.

    Tested with ozpropdev's toobox. found him using a PUSHB opcode not in the last list of opcodes.

    Is PUSHB still valid?

    Enjoy!

    Mike
  • cgraceycgracey Posts: 14,134
    edited 2014-03-27 15:54
    msrobots wrote: »
    I just added syntax highlighting for P2 PASM to the online editor.

    Tested with ozpropdev's toobox. found him using a PUSHB opcode not in the last list of opcodes.

    Is PUSHB still valid?

    Enjoy!

    Mike


    All those pushes and pops are still there.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-03-27 16:08
    msrobots wrote: »
    I just added syntax highlighting for P2 PASM to the online editor.

    Tested with ozpropdev's toobox. found him using a PUSHB opcode not in the last list of opcodes.

    Is PUSHB still valid?

    Enjoy!

    Mike
    PUSHA is possibly WRLONG D/#,PTRA++
    PUSHB is possibly WRLONG D/#,PTRB-- because B works in reverse
    PUSHX is possibly WRAUX D/#,PTRX++
    PUSHY is possibly WRAUX D/#,PTRY--
    POPA is possibly RDLONG D,PTRA--
    etc

    You might like to start a new thread and give us the details of the online editor. I have only partly followed your progress on the P1 thread.
  • msrobotsmsrobots Posts: 3,709
    edited 2014-03-27 16:13
    Thanks.

    Looks like I lost it while extracting the opcodes from the post.

    will update the editor soon.

    Enjoy!

    Mike
  • msrobotsmsrobots Posts: 3,709
    edited 2014-03-27 16:20
    you might like to start a new thread and give us the details of the online editor. I have only partly followed your progress on the P1 thread

    Yes. It is on the P1 thread since it uses OpenSpin converted to JavaScript by @Heater. And OpenSpin does not yet compile P2 code. But hopefully it will at some point.

    Funny times ahead.

    Enjoy!

    Mike
  • cgraceycgracey Posts: 14,134
    edited 2014-03-27 17:02
    Cluso99 wrote: »
    PUSHA is possibly WRLONG D/#,PTRA++
    PUSHB is possibly WRLONG D/#,PTRB-- because B works in reverse
    PUSHX is possibly WRAUX D/#,PTRX++
    PUSHY is possibly WRAUX D/#,PTRY--
    POPA is possibly RDLONG D,PTRA--
    etc

    You might like to start a new thread and give us the details of the online editor. I have only partly followed your progress on the P1 thread.



    Only PTRY was made to have any reverse behavior (via CALLY/RETY), so the PTRA/PTRB pushes and pops are all normal:

    PUSHA D/# is WRLONG D/#,PTRA++
    PUSHB D/# is WRLONG D/#,PTRB++
    PUSHX D/# is WRAUX D/#,PTRX++
    PUSHY D/# is WRAUX D/#,--PTRY

    POPA D is RDLONG D,--PTRA
    POPB D is RDLONG D,--PTRB
    POPX D is RDAUX D,--PTRX
    POPY D is RDAUX D,PTRY++
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-03-27 17:18
    cgracey wrote: »
    Only PTRY was made to have any reverse behavior (via CALLY/RETY), so the PTRA/PTRB pushes and pops are all normal:

    PUSHA D/# is WRLONG D/#,PTRA++
    PUSHB D/# is WRLONG D/#,PTRB++
    PUSHX D/# is WRAUX D/#,PTRX++
    PUSHY D/# is WRAUX D/#,--PTRY

    POPA D is RDLONG D,--PTRA
    POPB D is RDLONG D,--PTRB
    POPX D is RDAUX D,--PTRX
    POPY D is RDAUX D,PTRY++

    Thanks Chip.

    When the cog starts, all PTR A/B/X/Y are reset to 0, so we can use PTRX/Y immediately without the need to reset the values???
    ie So a PUSHX will put into AUX at $00 and a PUSHY will put into $FF ???
  • cgraceycgracey Posts: 14,134
    edited 2014-03-27 17:28
    Cluso99 wrote: »
    Thanks Chip.

    When the cog starts, all PTR A/B/X/Y are reset to 0, so we can use PTRX/Y immediately without the need to reset the values???
    ie So a PUSHX will put into AUX at $00 and a PUSHY will put into $FF ???

    That's all correct about PTRX/PTRY, but you probably just forgot about PTRA being the parameter and PTRB pointing to where the program was loaded or execution began.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-03-27 17:56
    cgracey wrote: »
    That's all correct about PTRX/PTRY, but you probably just forgot about PTRA being the parameter and PTRB pointing to where the program was loaded or execution began.
    I had when thinking about the stacks.

    A different question... when starting a new cog with COGNEW/COGNEWX it returns the cog# in the D operand if the start was successful. If the COGNEWx was preceeded with a TARG instruction would this work...
    ...
      TARG    <cog>
      COGNEW <startaddr>,<paramadr> WC
      TARGOFF 
    
    I presume the TARGOFF will be required if the cog was not started (no cogs available) because in that case, D would not have been written ???
  • cgraceycgracey Posts: 14,134
    edited 2014-03-27 18:05
    Cluso99 wrote: »
    I had when thinking about the stacks.

    A different question... when starting a new cog with COGNEW/COGNEWX it returns the cog# in the D operand if the start was successful. If the COGNEWx was preceeded with a TARG instruction would this work...
    ...
      TARG    <cog>
      COGNEW <startaddr>,<paramadr> WC
      TARGOFF 
    
    I presume the TARGOFF will be required if the cog was not started (no cogs available) because in that case, D would not have been written ???


    As long as COGNEW D/# uses D and not #, a value will be written, regardless of success or not. So, TARG could be used to redirect the result.
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-03-27 19:08
    cgracey wrote: »
    As long as COGNEW D/# uses D and not #, a value will be written, regardless of success or not. So, TARG could be used to redirect the result.
    Nice! Thanks Chip.
Sign In or Register to comment.