Shop OBEX P1 Docs P2 Docs Learn Events
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 31 — Parallax Forums

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

12829313334115

Comments

  • rogloh wrote: »
    Also Eric, I ran int a problem with use of "res" too in FASTSPIN. For the code snippet below P2ASM worked okay and allowed me to pad out to 64 instructions, but it was no go in FASTSPIN. I'd like this to work otherwise I need to compute a hard coded pad value which changes as I change the code, unless there is another common way that works.

    Sorry, that was an oversight -- I didn't add the special code to handle $ to the RES directive, although it was supported for ORG. It's fixed in github now and will be in the next release.

    In the meantime you could probably work around it by doing something like "ORG font + 64" instead of "RES 64 - ($ - font)".

  • When using FlexGUI 4.0.4-beta, under Win10 and coding in BASIC for a P2-EVAL rev B board:

    @ersmith It appears the FlexBASIC clkfreq() function is misbehaving. The code snipped shown in the manual won't compile. This doesn't work:
    	current_freq = clkfreq 
    	print current_freq
    
    The code above throws an "error: incompatible types in assignment". The code below returns a really (really) big integer that clearly isn't the clock freq:
    	current_freq = cast(long, clkfreq)
    	print current_freq
    
    But if you call CLKFREQ as if it were a function, the error is avoided but the return value is always zero:
    	current_freq = clkfreq()
    	print current_freq
    

    On a different subject, someone (I don't remember who, or in what thread) recently suggested adding stand-alone code snippets to the FlexBASIC docs. If I generated and tested a bunch of "cut-n-copy" snippets, would this be something you'd consider putting in the manual? Or maybe I need to generate a separate document to be included in the distro? Your thoughts would be appreciated.
  • JRoark wrote: »
    When using FlexGUI 4.0.4-beta, under Win10 and coding in BASIC for a P2-EVAL rev B board:

    @ersmith It appears the FlexBASIC clkfreq() function is misbehaving. The code snipped shown in the manual won't compile.
    Oops, yes, it certainly is misbehaving. I've changed it to go back to the old behavior. Long term it would be nice to get away from having a built-in variable for clkfreq, since it should only be changed via the clkset() function, but for now it's a variable again. Thanks for the bug report!
    On a different subject, someone (I don't remember who, or in what thread) recently suggested adding stand-alone code snippets to the FlexBASIC docs. If I generated and tested a bunch of "cut-n-copy" snippets, would this be something you'd consider putting in the manual? Or maybe I need to generate a separate document to be included in the distro? Your thoughts would be appreciated.

    I'm always happy to get contributions for the FlexGUI code and docs. If there are appropriate places to put the code snippets in the manual, we can certainly do that, or perhaps we could put them in an appendix or stand-alone document.

    Thanks!
    Eric
  • When using FlexGUI 4.0.4 under Win10 and coding in BASIC for a P2-EVAL rev B board:

    @ersmith Okay... FlexGUI is looking better and better!

    With reference to the earlier bug, I have some interesting results to report. This code now compiles fine, but returns "0" all the time:
    		print clkfreq
    
    But if you go chase it a bit, it turns-out that CLKFREQ is actually working... its just that FlexBASIC didnt set the CLKFREQ variable to a proper default clock value. So it just returns "0". By manually setting the clock frequency we can prove this, as this code shows:
    	clkset(0x015166F4, 350_000_000)    ' 350 MHz PLL 
    	_setbaud(230400)                   ' keep our USB connection happy after the clock speed change
    	print clkfreq
    
    This code prints "350000000", just as it should.

    So it appears that FlexBASIC needs to initialize CLKFREQ to the actual clock value it is using. (BTW: What is the default clock speed set by Flex? 80 mhz? 160 mhz?)
  • FlexGUI does initialize clkfreq, but it does so at the first I/O. That's probably the wrong place for it, and I've opened a bug.

    If you only do "print clkfreq" then yes, it will print 0 (it evaluates clkfreq before any I/O, so the clock has not been set yet). If however you do:
    print "frequency=",clkfreq
    
    then it should print 160000000.
  • dgatelydgately Posts: 1,620
    edited 2019-12-01 18:42
    ersmith,
    After exec'ing "git pull" in a spin2cpp repository directory, running make and then launching (in the build directory) fastspin, it returns:
    % fastspin
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 4.0.5-beta-cac4de16 Compiled on: Dec  1 2019
    usage: fastspin [options] filename.spin | filename.bas
    

    After exec'ing "git pull" & "git submodule update" in a flexgui repository directory, running make and then launching the built fastspin, it returns:
    ~/source/flexgui/spin2cpp/build% ./fastspin
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 4.0.4-beta-5bec2198 Compiled on: Dec  1 2019
    usage: ./fastspin [options] filename.spin | filename.bas
    

    I assumed that "git submodule update" would grab the latest spin2cpp & fastspin sources, no? Note: I always exec "make clean" before building any projects after git updates to make sure they build with the current sources... Is there another git command that will ensure the latest sources get inside flexgui?

    dgately

  • dgately wrote: »
    After exec'ing "git pull" & "git submodule update" in a flexgui repository directory, running make and then launching the built fastspin, it returns:
    ~/source/flexgui/spin2cpp/build% ./fastspin
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 4.0.4-beta-5bec2198 Compiled on: Dec  1 2019
    usage: ./fastspin [options] filename.spin | filename.bas
    

    I assumed that "git submodule update" would grab the latest spin2cpp & fastspin sources, no? Note: I always exec "make clean" before building any projects after git updates to make sure they build with the current sources... Is there another git command that will ensure the latest sources get inside flexgui?

    No, that's an interesting feature of git -- the submodules refer to a specific version, so "git pull" and/or "git submodule update" at the top level will pull that particular version. Which is sometimes what you want (it guarantees that all the pieces work together) but is sometimes surprising.

    To get the latest fastspin/spin2gui from inside the flexgui tree, cd to the spin2cpp subdirectory and do "git pull" there. That should pull the latest version, if I remember correctly. If not, you can do "git checkout master" inside the spin2cpp subdirectory.
  • ersmith wrote: »
    To get the latest fastspin/spin2gui from inside the flexgui tree, cd to the spin2cpp subdirectory and do "git pull" there. That should pull the latest version, if I remember correctly. If not, you can do "git checkout master" inside the spin2cpp subdirectory.
    Running only "git pull" in those directories almost works...
    ~/source/flexgui/loadp2% git pull
    remote: Enumerating objects: 19, done.
    remote: Counting objects: 100% (19/19), done.
    remote: Compressing objects: 100% (7/7), done.
    remote: Total 17 (delta 10), reused 17 (delta 10), pack-reused 0
    Unpacking objects: 100% (17/17), done.
    From https://github.com/totalspectrum/loadp2
       b94d6c9..e66f467  master     -> origin/master
    You are not currently on a branch.
    Please specify which branch you want to merge with.
    See git-pull(1) for details.
    
        git pull <remote> <branch>
    
    But, running "git checkout master" first, gets you closer:
    ~/source/flexgui/loadp2% git checkout master
    Previous HEAD position was b94d6c9 Checked in MainLoader*.h to make bootstrapping easier
    Switched to branch 'master'
    Your branch is behind 'origin/master' by 7 commits, and can be fast-forwarded.
      (use "git pull" to update your local branch)
    
    Then "git pull" responds with success!
    ~/source/flexgui/loadp2% git pull
    Updating 6e9861c..e66f467
    Fast-forward
     .gitignore    |   2 --
     MainLoader.h  |  46 ++++++++++++++++++++++++++
    ...
     10 files changed, 372 insertions(+), 63 deletions(-)
    ...
    



    Thank you!

    dgately

  • I am having an issue with the port definition when trying to program a Prop1 on a Windows 10 machine using Flexgui_4.0.3. See attached file for screen shot. The Prop1 is on comport 15. The PropTool is able to access it on COM15. What am I doing wrong?
  • @TrapperBob : is it possible some other program is using the serial port and preventing PropLoader from accessing it? Otherwise I'm not sure what could be going on; I have a pretty similar setup, although it is COM7 instead of COM15.

    Another thing you could try is to launch proploader from a command line and see if it accepts "-p COM15" instead of "-p \\.\COM15, that is try:
    C:\my_exec\flexgui4_03\bin\proploader -Dbaudrate=115200 -p COM15 C:/Users/rpflaus/Desktop/Test1.binary -r -t -k
    
  • @ersmith

    I checked and no other device is using the port. I was able to launch proploader directly using the -p COM15 syntax from cmdline without the backslash escapes as when it is called by the gui ?
  • TrapperBob wrote: »
    @ersmith

    I checked and no other device is using the port. I was able to launch proploader directly using the -p COM15 syntax from cmdline without the backslash escapes as when it is called by the gui ?

    Huh, that's very strange. I have tried several combinations of backslashes on the command line and they all seem to work for COM7, including the original one that the GUI sends. If you manually type in the command with -p \\.\COM15 or -p \\\\.\\COM15 do either of those work?
  • RaymanRayman Posts: 13,767
    I just tried it with P1 on com17 and it worked the second time...

    The first time, it tried the wrong serial port...

    Maybe look in device manager to see which com port it is actually on?
  • @ersmith , @Rayman

    Thanks for suggestions!

    I changed to com2 and tried from the gui. It fails using the syntax that the gui specifies \\.\COM2.
    I can successfully from the cmdline use either -p COM2 , -p \\\\.\\COM2 or -p \\.\com2 . The same holds true for the original COM15.
    I tried on a different Windows 10 machine and the gui worked just fine.

    I also truied running flexgui as admin without any difference in operation. I am not sure what is going on on this particular PC. It is my PC at work. I will continue to "fiddle" with it. More ideas are welcome.
  • TrapperBob wrote: »
    I changed to com2 and tried from the gui. It fails using the syntax that the gui specifies \\.\COM2.
    I can successfully from the cmdline use either -p COM2 , -p \\\\.\\COM2 or -p \\.\com2 . The same holds true for the original COM15.
    Wait, so the lower case version of the GUI syntax worked, but the upper case one failed? That's just weird.
    I tried on a different Windows 10 machine and the gui worked just fine.
    I don't know what to suggest, it also works fine on my Windows 10 machine here.

    You can always use Commands > Configure Commands... to change the command line that the GUI will use, so you could hard code the port there. To do that, replace the %P string in the run command with "-p COM2" or whatever is appropriate.
  • RaymanRayman Posts: 13,767
    It is hard to see how this can happen...
    FlexGui must be using some external dll or something that is different on that pc...
  • @ersmith , @Rayman,

    I have harcoded it as suggested for now. I did not mean to imply that case had anything to do with it. It does NOT seem to. (com2 vs COM2).
    What I have found is that the syntax that the %P in the config file resolves to when execute by flexgui is -p\\.\COM2 and this form does not seem to work when it is the command presented by flexgui. I need to verify on my computer at home if this resolves to //./COMx or ////.//COMx, I do not remeber now.
    Thanks for your help!
  • RaymanRayman Posts: 13,767
    I got an interesting error while converting this Spin1 driver to Spin2...
    Says a bunch of labels are "not on lonword boundary".

    I think this is due to my use of a byte jump table.
    This kind of jump table is used a lot with P1 ASM to save instructions....
    I'm sure there is something better for P2.
    However, I think the compiler could be made to accommodate this...

    BTW: I sometimes use a word jump table instead.
    Just mentioning it in case it's something you want to fix (or not).
  • RaymanRayman Posts: 13,767
    Something else...
    This commented out section of code should be ignored, but gives a "unexpected end of line, expecting indentation" error...
    I've put it into the attached.
  • ersmithersmith Posts: 5,898
    edited 2019-12-04 21:02
    The problem is that on P2 instructions and the "long" pseudo-instruction do not automatically align to a longword boundary. So in:
                  and     t2,#$FF
                  jmp     t2                                'jump to command
    jumps         byte    0                                 '0
                  byte    CaptureFrame_                     '1
    
    DummyOp_              
    NotUsed_      jmp     #loop
    

    Everything after "DummyOp_" is no longer long aligned on P2 (it is on P1 because of the automatic alignment). So the compiler error is legit in this case. You can fix it by inserting "alignl" after your jump table to resume long alignment.

    BTW there's also a warning from the new fastspin:
    FLIR_Driver3a.spin2:254: warning: Second operand is a constant used without #; is this correct? If so, you may suppress this warning by putting +0 after the operand
    
    In this case it's OK because the instruction is "mov t2, 0" and the source is actually set by a "sets" earlier. Still, you might want to write "mov t2, 0-0" to get rid of the warning and also to make it clearer to the reader that the source is programmed by an earlier sets.
  • RaymanRayman Posts: 13,767
    Yes, I understand the alignment.
    Was merely commenting that Spin1 allowed this and Chip's Spin2 probably will too (?)...
  • Rayman wrote: »
    Yes, I understand the alignment.
    Was merely commenting that Spin1 allowed this and Chip's Spin2 probably will too (?)...

    I wouldn't be so sure. Have you tried it in PNut? I think @cgracey intended that P2 instructions do not have to be long aligned in HUB memory, so mixing byte directives and instructions may be problematic if you're intending to load them into COG memory. On P1 it was never an issue because instructions automatically became long aligned.

    Chip, am I wrong about this?
  • RaymanRayman Posts: 13,767
    It compiles in PNut… Attached...
  • msrobotsmsrobots Posts: 3,701
    edited 2019-12-04 21:46
    If one looks at his code you might be right that he assumes long aligned instructions
    '
    ' Send results serially on P62
    '
    		call	#tx_string			'clocks
    		byte	13," clocks:",0
    		callpa	clocks,#tx_decimal
    
    		call	#tx_string			'states
    		byte	"    states:",0
    		callpa	states,#tx_decimal
    …
    '
    ' Transmit zero-terminated string following call
    '
    tx_string	pop	x				'pop return address and make byte ptr
    		shl	x,#2
    
    .loop		altgb	x				'get character
    		getbyte	y
    		tjz	y,#.done			'if 0, done
    		callpa	y,#tx_chr			'else, output character
    		ijnz	x,#.loop			'inc byte ptr and loop
    
    .done		shr	x,#2				'make long ptr
    		add	x,#1				'inc long ptr to instruction following string
    		jmp	x				'return to caller
    '
    
  • RaymanRayman Posts: 13,767
    I think any byte or word data has to be expanded to multiple of 4 byte (long) size by the compiler...
  • cgraceycgracey Posts: 14,131
    edited 2019-12-04 22:37
    Under ORG mode (but not ORGH mode), any PASM instruction automatically bumps to the next long-aligned cog address (not hub address). When I wrote that code yesterday, I realized that we need maybe a special directive or BYTE/WORD version (BYTECOG/WORDCOG?) to pad to the next long-aligned cog address after its data. Or, what if BYYE/WORD under ORG mode just padded to the next long automatically?
  • ersmithersmith Posts: 5,898
    edited 2019-12-04 23:04
    cgracey wrote: »
    Under ORG mode (but not ORGH mode), any PASM instruction automatically bumps to the next long-aligned cog address (not hub address).
    Ah, OK. I had it never bumping the address (so acting like ORGH mode all the time). I'll fix that in the next version of fastspin.
    When I wrote that code yesterday, I realized that we need maybe a special directive or BYTE/WORD version (BYTECOG/WORDCOG?) to pad to the next long-aligned cog address after its data. Or, what if BYYE/WORD under ORG mode just padded to the next long automatically?

    I don't think we'd want BYTE/WORD padding automatically in ORG mode, because there might be cases where you really want to put bytes in COG memory (for use by getbyte, for example) without any padding. I think this is one of those situations where people are going to have to be careful and/or use explicit "alignl" if they want padding.

    It might make sense for LONG to automatically align itself in ORG mode though, if it doesn't already (does it?)
  • for data in Hub we already have alignl/w if needed so that is fine.
    for Cog images in Hub we already have them aligned at long and in the COG code instructions need to get automatically padded to long boundaries, everything else could not run.
    for Data in a Cog I see not really a need to have a directive like wordcog, labels in COG/LUT are always long aligned, so what should it do?

    curious,

    Mike
  • Rayman wrote: »
    Something else...
    This commented out section of code should be ignored, but gives a "unexpected end of line, expecting indentation" error...
    I've put it into the attached.

    That's an interesting bug, nice catch. The bug would happen if a REPEAT (or similar instruction needing indentation after it to indicate a block) was the last instruction in the last function in the file, and everything after it was either blank or {} comments. I'll fix that in the next version, but for now you can work around it by putting a RETURN after the REPEAT. The RETURN will be optimized away (since it can never be reached) and is harmless as the last instruction in a function.

    Thanks for the bug report!
  • Copied from the reciprocal counter demo thread to this Fastspin thread...
    ersmith wrote: »
    rogloh wrote: »
    ersmith wrote: »
    Bean wrote: »
    P.S. Could someone explain the use of a dot before some of the labels ? ".wait", ".loop", ".done"

    It's to indicate a temporary label that only lasts until the next regular label. In P1 PASM that was indicated with a colon (":wait", ":loop", ":done" etc.) but in P2 PASM it's a dot.

    @ersmith , Does fastspin allow the @.endloop type of addressing with REP? I vaguely recall I had trouble with this when porting over to use fastspin instead from P2ASM and I think I needed to change my labels to get rid of the period for my rep loop addressing to work.

    eg. try this...
        REP @.endloop, #4
        ADD A, #1  ' some loop
    .endloop
    

    Seems to work for me.



    Well this code compiles okay...
    p4          if_nz           rep     @endnormal, #COLS       '2760 clocks for 80 normal wide
                                skipf   a                       'skip 2 of the next 5 instructions
                                xor     a, #%11110              'flip skip sequence for next time
                                rdlut   d, pb                   'read pair of characters/colours
                                getword c, d, #1                'select first word in long (skipf)
                                getword c, d, #0                'select second word in long (skipf)
                                sub     pb, #1                  'decrement LUT read index (skipf)
                                getbyte b, c, #0                'extract font offset for char 
                                altgb   b, #font                'determine font lookup address
                                getbyte pixels, 0-0, #0         'get font for character's scanline
    testflash                   bitl    c, #15 wcz              'test (and clear) flashing bit
    flash       if_c            and     pixels, #$ff            'make it all background if flashing
                                movbyts c, #%01010101           'colours becomes BF_BF_BF_BF
                                mov     b, c                    'grab a copy for muxing step next
                                rol     b, #4                   'b becomes FB_FB_FB_FB
                                setq    ##$F0FF000F             'mux mask adjusts fg and bg colours
                                muxq    c, b                    'c becomes FF_FB_BF_BB
                                testb   modedata, #10 wz        'repeat columns test, z was trashed
    endnormal                                                   'end rep 2 instructions early (skipf)
                if_nz           movbyts c, pixels               'select pixel colours for char
    

    But this code below with the dot in front of the label gives this error on the rep line, seems to ignore the dot in front of the symbol.

    Version 4.0.4-beta- Compiled on: Nov 16 2019
    /Users/roger/Downloads/flexgui-4.0.3/samples/p2videodrv.spin2:1035: error: Unknown symbol p4:endnormal
    /Users/roger/Downloads/flexgui-4.0.3/samples/p2videodrv.spin2:1035: error: Destination operand too big for rep
    p2videodrv.spin2

    p4          if_nz           rep     @.endnormal, #COLS       '2760 clocks for 80 normal wide
                                skipf   a                       'skip 2 of the next 5 instructions
                                xor     a, #%11110              'flip skip sequence for next time
                                rdlut   d, pb                   'read pair of characters/colours
                                getword c, d, #1                'select first word in long (skipf)
                                getword c, d, #0                'select second word in long (skipf)
                                sub     pb, #1                  'decrement LUT read index (skipf)
                                getbyte b, c, #0                'extract font offset for char 
                                altgb   b, #font                'determine font lookup address
                                getbyte pixels, 0-0, #0         'get font for character's scanline
    testflash                   bitl    c, #15 wcz              'test (and clear) flashing bit
    flash       if_c            and     pixels, #$ff            'make it all background if flashing
                                movbyts c, #%01010101           'colours becomes BF_BF_BF_BF
                                mov     b, c                    'grab a copy for muxing step next
                                rol     b, #4                   'b becomes FB_FB_FB_FB
                                setq    ##$F0FF000F             'mux mask adjusts fg and bg colours
                                muxq    c, b                    'c becomes FF_FB_BF_BB
                                testb   modedata, #10 wz        'repeat columns test, z was trashed
    .endnormal                                                   'end rep 2 instructions early (skipf)
                if_nz           movbyts c, pixels               'select pixel colours for char
    
Sign In or Register to comment.