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

1789101113»

Comments

  • So many FastSpin threads... Maybe this is the right one...

    I'm getting an error when I use ".end" but not with "end" here:
    DAT 'ReadRegOrId 
    ReadRegOrId                
                    or      outa,mRSTn  'bring resetn high
                    setbyte   dira,#$FF,#0
                    andn      outa,mCSn 'bring cs low
                    
                    'Send Command Address
                    mov     altsd,#datain0
                    rep @.end,#7
    alts1           alts    altsd
                    setbyte outa,0,#0
                    xor     outa,mCK
                    add     altsd,#1
    .end
    

    this is the error (see attached image).
    541 x 150 - 7K
    Prop Info and Apps: http://www.rayslogic.com/
  • garryjgarryj Posts: 249
    edited 2019-03-12 - 19:48:43
    The .end label is local and is used prior to the alts1 label, which is not local, so the REP cannot "see" .end.

    Addit: if alts1 is not local you can just rename it to .alts1 and all should be good.
    garryj
  • Ok, I think you're saying one can't have non-local references in between local ones.
    Guess that explains it...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Ok, I think you're saying one can't have non-local references in between local ones.
    Guess that explains it...

    Correct. By definition a "local" reference only extends until the next non-local one. This is the same as for P1 PASM; the only difference is that for P2 PASM we use "." to introduce a local label instead of ":".
  • I don't really use this for P1.
    But, for P2 it's handy for the REP instruction...
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 9,347
    edited 2019-03-16 - 18:12:38
    So this is strange...
    If I add this line to a program, it doesn't work anymore:
    loc       ptra,##@HyperBuffer
    
    I think it's maybe supposed to just be #@ instead of ##@.
    But, don't know why that should kill the whole application...
    Prop Info and Apps: http://www.rayslogic.com/
  • Something is wrong with REP...
    It's slower using @.reploop2 than with #1..
    rep   #1,##640'@.reploop2,##640  
                  wfbyte    inb
    .reploop2
    
    Prop Info and Apps: http://www.rayslogic.com/
  • ersmithersmith Posts: 2,856
    edited 2019-03-16 - 20:49:46
    Rayman wrote: »
    Something is wrong with REP...
    It's slower using @.reploop2 than with #1..
    rep   #1,##640'@.reploop2,##640  
                  wfbyte    inb
    .reploop2
    

    Yes, there's a bug in the parsing of rep instructions; if a ## is present the augment instruction is counted as part of the loop for @ expressions. That's wrong of course, and I'll try to fix it soon. You can avoid it for now by putting the "640" in a register and using that for the loop count.

    As for the loc ptra, ##@HyperBuffer; there are probably multiple issues there. ## will generate an augment, which will probably mess up the loc address. Also, if you have Spin code in the same file (it's not a pure assembly program) then the whole meaning of "@" is a bit fuzzy, just as in Spin1 (where we had @ to handle this kind of thing). The upcoming fastspin release will handle this better, I think, but for now I'd suggest doing something like:
       mov ptra, HyperBufferPtr
       ...
    HyperBufferPtr long @ @ @ HyperBuffer
    
    (without the spaces between the "@" signs -- why does the forum try to parse those inside code blocks??) which will work even if you have Spin code there.
  • Thing about the loc ##@ is that it appears to mess up all the cogs, not just the one whose code this is in...
    Prop Info and Apps: http://www.rayslogic.com/
  • I tried using COGATN and WAITATN and couldn't make it work...
    Not sure it's a FastSpin bug, maybe I did it wrong...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Thing about the loc ##@ is that it appears to mess up all the cogs, not just the one whose code this is in...

    Well, I guess the effects would depend on what the loc result was used for -- if you end up with a bad address in ptra you could overwrite other COGs memory.
  • Rayman wrote: »
    I tried using COGATN and WAITATN and couldn't make it work...
    Not sure it's a FastSpin bug, maybe I did it wrong...

    Remember that cogatn takes a mask as parameter (to signal multiple COGs). I've attached a sample program that works for me.
  • I've posted new versions of fastspin and spin2gui.

    @Rayman : this fixes the REP bug you noticed, as well as another REP bug where the optimizer would get confused when inlining a function that contained REP. It also handles loc better, although there are probably still some issues with addresses when mixing Spin and PASM code.

    @pilot0315 : spin2gui checks now for deleted files and always re-writes the files if it can't find them on disk.

    There are also a bunch more bug fixes (see the release notes for details). The only major new feature is that FCACHE is supported in P2 mode, using the LUT to cache small loops, but that has to be explicitly enabled by saying something like --fcache=240 on the command line. FCACHE doesn't make nearly as much difference on P2 as on P1, since hub exec is already pretty efficient, but it does provide a small speedup, e.g. the fftbench time dropped from 46 microseconds without fcache to 40 microseconds with --fcache=240.
  • There are new releases of fastspin and spin2gui. Mostly this is a bugfix release to fix various issues that people have reported (thanks for the bug reports, everyone). The only "new" features are (1) FCACHE is enabled automatically on P2 at optimization level -O2, and (2) if an object is given without an extension, fastspin looks for it as a .spin2 file first, and then a .spin file.
Sign In or Register to comment.