Shop Learn
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 87 — Parallax Forums

flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

18384858789

Comments

  • RaymanRayman Posts: 12,099

    Regarding gets() being slow... Did some testing and it seems specific to one of my custom boards with a P2 Edge module on it... Something strange must be going on there... Maybe the FTDI chip needs different programming settings or something...

  • TonyB_TonyB_ Posts: 1,752

    @ersmith said:

    @TonyB_ said:
    deleted

    Sounds like there's a missing "ORG 0" at the beginning of the COG code.

    Solved now, thanks, too many late nights recently.

  • TonyB_TonyB_ Posts: 1,752

    Can't TJNS D,#S branch from cog to LUT RAM, e.g. a short forward jump from $1DE to $200? FlexSpin gives an error for this and similarly for CALLPB.

  • ersmithersmith Posts: 4,968

    @TonyB_ said:
    Can't TJNS D,#S branch from cog to LUT RAM, e.g. a short forward jump from $1DE to $200? FlexSpin gives an error for this and similarly for CALLPB.

    Is that legal? I thought relative branches have to stay inside the same RAM. Does PNut let you try this? And if so, does it actually work?

  • TonyB_TonyB_ Posts: 1,752
    edited 2021-07-07 11:31

    @ersmith said:

    @TonyB_ said:
    Can't TJNS D,#S branch from cog to LUT RAM, e.g. a short forward jump from $1DE to $200? FlexSpin gives an error for this and similarly for CALLPB.

    Is that legal? I thought relative branches have to stay inside the same RAM. Does PNut let you try this? And if so, does it actually work?

    I think it is legal, but I can't use PNut to confirm.

    The BRANCH ADDRESSING section of the doc discusses DJxx, IJxx, TJxx, CALLPx and a few others. It states that "their immediate range is -256 to +255 instructions, relative to the instruction after the branch."

    I guess that a forward jump from the top of LUT RAM wraps around to the bottom of cog RAM for these call or jump to S** instructions.

  • evanhevanh Posts: 11,291
    edited 2021-07-06 22:21

    I tested the hardware ages back but can't quite remember the details. I think COGRAM<->LUTRAM worked fine but I'm not certain now. LUTRAM to HUBRAM was a bit screwy but did work with an offset calculation. Going back to LUTRAM was different but I've forgotten in what way. HUBRAM wrapping back to COGRAM at the zero boundary was super screwy in that it would fetch from COGRAM but the PC was above 1 MB. Which caused some predictably weird behaviour.

  • evanhevanh Posts: 11,291

    Oh, it only works if branching. You can't walk from LUTRAM to HUBRAM with sequential fetches. Don't remember for COGRAM to LUTRAM but likely the same.

  • msrobotsmsrobots Posts: 3,419

    I remember that boundary crossing needs to be absolute addressed not relative.

    Not sure from where I got that.

    Mike

  • TonyB_TonyB_ Posts: 1,752

    Jumping to and from hub RAM is not relevant to the suspected FlexSpin problem with the S** group of instructions.

  • evanhevanh Posts: 11,291

    I wasn't testing the assemblers. I was testing the hardware. But my memory is not clear on which test was what any longer ...

  • TonyB_TonyB_ Posts: 1,752
    edited 2021-07-07 11:33

    deleted

  • evanhevanh Posts: 11,291
    edited 2021-07-07 00:00

    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    PS: I had to hand code the machine code in Flexspin. The assembler gave me invalid offset ... as well as the error message.

  • evanhevanh Posts: 11,291
    edited 2021-07-07 01:49

    Tidied it up. Requires flexspin, the attached wrapper, and open terminal (I use loadp2) for reporting:

    CON
        XTALFREQ    = 20_000_000                'PLL stage 0: crystal frequency
        XDIV        = 2                 'PLL stage 1: crystal divider (1..64)
        XMUL        = 10                    'PLL stage 2: crystal / div * mul (1..1024)
        XDIVP       = 4                 'PLL stage 3: crystal / div * mul / divp (1,2,4,6..30)
    
        LUT_reserved    = 8
    
    
    
    DAT                     'not Spin code
    ORG  0
    
    '******************************************************************************
    msec        jmp     #_diaginit
    xtalmul     long    XMUL
    
    
    hw_rev      long    0           'hubRAM addr $010 - unused reserved parameter - using to hold revA/B
    clk_freq    long    25_000_000      'hubRAM addr $014 - sysclock frequency, integer frequency in hertz
    clk_mode    long    0           'hubRAM addr $018 - clock mode config word, used directly in HUBSET
    asyn_baud   long    230_400         'hubRAM addr $01c - comport baud rate, integer baud in hertz
    '--------------------------------------------------------
    
    _main
            mov bcdlen, #8
    
            setq2   #(lut4 - lut1 - 1)
            rdlong  0, ##@lut1          'copy into lutRAM at $200
    
            setq    #(cog5 - cog3 - 1)
            rdlong  cog3, ##@cog3           'copy into cogRAM at $180
    
            setq    #(cog2 - cog1 - 1)
            rdlong  0, ##@cog1          'copy into cogRAM at $0
    
            jmp #cog4
    
    
    report
            pop pa
            call    #itoh
    
            mov pa, ptra
            call    #puts
            jmp #$
    
    
    
    ORG  0
    cog1
            loc ptra, #msg_fail
            call    #\report            'has to be absolute encoded branch address
    cog2
    
    
    
    ORG  $180
    cog3
            loc ptra, #msg_fail
            call    #\report            'has to be absolute encoded branch address
    
    cog4
            loc pa, #msg_start
            call    #puts
    
            mov pa, #100
    '       djnf    pa, #lut3           '7c Ec 7F FB
            long    $fb7fec7c
    
            loc ptra, #msg_fail
            call    #\report            'has to be absolute encoded branch address
    cog5
    
    
    
    ORG  $200
    lut1
            loc ptra, #msg_fail
            call    #\report            'has to be absolute encoded branch address
    
    lut3
            loc ptra, #msg_lut
            call    #\report            'has to be absolute encoded branch address
    lut4
    
    
    
    ORGH $400
            loc ptra, #msg_fail
            call    #\report            'has to be absolute encoded branch address
    
    msg_start   byte    "Start ... ",0
    msg_hub     byte    " in hubRAM",13,10,0
    msg_lut     byte    " in lutRAM",13,10,0
    msg_cog     byte    " in cogRAM",13,10,0
    msg_fail    byte    " fail :-(",13,10,0
    
    '******************************************************************************
    ' Subroutines
    '******************************************************************************
    #include    "init-diag.spin2"
    
    

    EDIT: Typos

  • evanhevanh Posts: 11,291
    edited 2021-07-07 03:36

    A regression - Binary inversion operator gets following error:
    spin-compile-test.spin2:6: error: assignment to constantTEST_CONSTANT'`

    con
        TEST_CONSTANT = 10
    
    
    PUB begin()
        waitms( ~TEST_CONSTANT )
    
  • TonyB_TonyB_ Posts: 1,752

    @evanh said:
    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    PS: I had to hand code the machine code in Flexspin. The assembler gave me invalid offset ... as well as the error message.

    Thanks, Evan. FlexSpin seems to get encoding right currently apart from incorrect S field = $1FF. Branch from ~$180 to $202 works. Next logical test would be ~$380 to $002.

  • evanhevanh Posts: 11,291
    edited 2021-07-07 10:41

    @TonyB_ said:
    Next logical test would be ~$380 to $002.

    Relative positive branch from $380 will land in hubRAM. Triggering hubexec and the FIFO.

  • evanhevanh Posts: 11,291

    Testing that it seems to be precisely scaled as longwords below $400 and bytes from $400 up. Which makes sense given that is the documented addressing. So a relative branch of $100 from $380 in lutRAM will land at $480 in hubRAM.

  • evanhevanh Posts: 11,291

    On the other hand, if there is no branch and you execute off the end of lutRAM it will wrap back to cogRAM, albeit with the program counter ticking along above $400, because hubexec will only trigger on a branch.

  • evanhevanh Posts: 11,291

    And you can't walk off the end of cogRAM because the special purpose registers at the end of cogRAM will crash your code.

  • TonyB_TonyB_ Posts: 1,752

    @evanh said:
    Testing that it seems to be precisely scaled as longwords below $400 and bytes from $400 up. Which makes sense given that is the documented addressing. So a relative branch of $100 from $380 in lutRAM will land at $480 in hubRAM.

    @evanh said:
    On the other hand, if there is no branch and you execute off the end of lutRAM it will wrap back to cogRAM, albeit with the program counter ticking along above $400, because hubexec will only trigger on a branch.

    Thanks for the extra testing, Evan.

    I think there might be something else apart from PC that wraps around from end of LUT RAM to start of cog RAM, from a discussion a few months ago.

  • ersmithersmith Posts: 4,968

    @evanh said:
    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    Thanks for checking this. I'll disable the error in flexspin then.

  • ersmithersmith Posts: 4,968

    @evanh said:
    A regression - Binary inversion operator gets following error:
    spin-compile-test.spin2:6: error: assignment to constantTEST_CONSTANT'`

    con
      TEST_CONSTANT = 10
    
    
    PUB begin()
      waitms( ~TEST_CONSTANT )
    

    No, the previous behavior was the incorrect one (unfortunately). "~" is documented to modify its operand, so it cannot be applied to a constant. I've verified this with openspin.

    Incidentally, ~x is not the binary inversion operator: it sign extends x from bit 7. Binary inversion would be !x

  • evanhevanh Posts: 11,291
    edited 2021-07-07 12:25

    Huh, okay, I admit I assumed it's function. I don't really know Spin all the well. I struck the error when compiling Roger's video driver. I guess it's time to clarify with Roger what his intent is.

    EDIT: Duh! Of course Roger has already fixed it, and is now using the ! operator, with the newest release. Didn't think to check until I went hunting for the driver topic. O_o

  • evanhevanh Posts: 11,291

    @ersmith said:

    @evanh said:
    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    Thanks for checking this. I'll disable the error in flexspin then.

    You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.

  • ersmithersmith Posts: 4,968

    @evanh said:

    @ersmith said:

    @evanh said:
    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    Thanks for checking this. I'll disable the error in flexspin then.

    You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.

    No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).

  • evanhevanh Posts: 11,291

    Oh, thanks for the info.

  • TonyB_TonyB_ Posts: 1,752

    @ersmith said:

    @evanh said:

    @ersmith said:

    @evanh said:
    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    Thanks for checking this. I'll disable the error in flexspin then.

    You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.

    No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).

    Where exactly is the new flexspin.exe?
    flexprop5.5.1.zip is the same as before with bad code.

  • TonyB_TonyB_ Posts: 1,752

    @ersmith said:

    @evanh said:

    @ersmith said:

    @evanh said:
    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    Thanks for checking this. I'll disable the error in flexspin then.

    You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.

    No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).

    Where exactly is the new flexspin.exe?
    flexprop5.5.1.zip is the same as before with bad code.

  • ersmithersmith Posts: 4,968

    @TonyB_ said:

    @ersmith said:

    @evanh said:

    @ersmith said:

    @evanh said:
    I've confirmed that a relative branch, with DJNF, from cogRAM to lutRAM, works as expected without quirks.

    Thanks for checking this. I'll disable the error in flexspin then.

    You better look over my testing example too. That result was for the hardware with the appropriate machine code, not Flexspin. The assembler also needs fixed.

    No, the bad code was just because a dummy address was inserted at the point of the error to stop the error from appearing again. Now that the error is disabled the assembler is generating the same bytes as the original LONG did (this is with the github version of flexspin).

    Where exactly is the new flexspin.exe?
    flexprop5.5.1.zip is the same as before with bad code.

    It's the checked in source version. There hasn't been a new binary release (and likely won't be for a little while).

  • evanhevanh Posts: 11,291

    aaaw! didn't do lut<->hub ;)

Sign In or Register to comment.