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

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

12728303233115

Comments

  • JRoark wrote: »
    @ersmith The "Edit -> Search" feature in FlexGUI seems to have broken. The search dialog comes up normally, and it allows you to specify the text to search, but when you click "Next", it all goes kablooey.
    I think this only happens if you open a file and search immediately. If I click on the tab and do anything at all with the text then search seems to work for me. So there's a bug there, but it's not as catastrophic as search being totally broken :).
    Edited to add:
    There also seems to be a "turnaround" bug on the USB port. If, after downloading code, you immediately issue a "PRINT" statement, the first dozen (or more) characters displayed will be garbage. If however, you put a short delay before the PRINT statement (50 mS seems to work really well for me), then it's fine.
    I'm guessing that's a problem with proploader. I'm not too familiar with that code, but I'll take a look when I can.

    Thanks,
    Eric

  • When using FlexGUI 4.0.2, under Win10 and coding in BASIC for a FLiP:

    @ersmith There is some mischief afoot that feels like a "funny". It isn't a showstopper, but if you suddenly run out of projects (snicker) you might give this one some noodle-time:
    "D:/Flex2Gui/flexgui/bin/fastspin" -l -O1 -L "./include" "D:/Flex2Gui/flexgui/junk.bas"
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 4.0.2 Compiled on: Oct 26 2019
    child killed: segmentation violation
    Finished at Sat Nov  2 11:50:50 2019
    
    There is no way to reliably demonstrate this bug. It will occur in about 1 out of 20 compiles whenever the code size hits more than ~1500-2000 lines. I have never seen this error occur with small programs or when I'm coding exclsively in Spin. This seems to be a BASIC-only bug. It seems to occur more often when using multiple #INCLUDE files, but this may just be an artifact of increasing program size.

    Now for the odd part: if the error gets thrown and you do NOTHING but just attempt another compile (ie, dont touch the code, just dismiss the error message and then click on "Compile & Run On P1"), the bug usually goes away. On occasion it will rethrow the error, but that behavior is exceedingly rare.
  • @JRoark: I haven't seen that crash, but I'll keep my eyes open for uninitialized variables or anything else that might cause that kind of unreproducible problem.

    Thanks,
    Eric
  • evanhevanh Posts: 15,091
    JRoark wrote: »
    ... just dismiss the error message and then click on "Compile & Run On P1"), the bug usually goes away. On occasion it will rethrow the error, but that behavior is exceedingly rare.
    Symptomatic of an OS/hardware issue. If you have another computer to compile it with, it'd be worth using that for a while to see if the issue arises there at all.
  • evanh wrote: »
    Symptomatic of an OS/hardware issue. If you have another computer to compile it with, it'd be worth using that for a while to see if the issue arises there at all.
    That sounded reasonable so I went with your suggestion. I've now tried on two other machines. Both are running Win10. One is a clunker and it's bulletproof. It never sees that error. The other one is current-generation hardware and the error does occur on that one.

  • jef_vtjef_vt Posts: 23
    edited 2019-11-04 20:24
    Hi,
    I use fastspin in command line in combination with VScode on windows10.
    I just updated from 3.9.29 to 4.0.2

    Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
    I compiled the same files 20 times as test and only 4 times it completed.
    Never had this problem with v3.9.29
    the program is big. >10k lines.

    The program is written for P2 and the command line is:
    fastspin.exe -2 -l -O1 --code=hub path\of\program.spin2
    If you need more information, please let me know.

    edit: the size of the compiled program also changed. From 111360 bytes (3.9.29) to 111648 bytes (4.0.2)
  • jef_vt wrote: »
    Hi,
    I use fastspin in command line in combination with VScode on windows10.
    I just updated from 3.9.29 to 4.0.2

    Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
    I compiled the same files 20 times as test and only 4 times it completed.
    Never had this problem with v3.9.29
    the program is big. >10k lines.

    Are you able to share the program? I'd like to debug this but it would be helpful to have a repro case.
  • ersmith wrote: »
    jef_vt wrote: »
    Hi,
    I use fastspin in command line in combination with VScode on windows10.
    I just updated from 3.9.29 to 4.0.2

    Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
    I compiled the same files 20 times as test and only 4 times it completed.
    Never had this problem with v3.9.29
    the program is big. >10k lines.

    Are you able to share the program? I'd like to debug this but it would be helpful to have a repro case.

    How can I send you PM or email? (i am not familiar with this forum)
  • jef_vt wrote: »
    ersmith wrote: »
    jef_vt wrote: »
    Hi,
    I use fastspin in command line in combination with VScode on windows10.
    I just updated from 3.9.29 to 4.0.2

    Most of the time the new compiler takes a longer time to compile (like 2sec) and stops right before the p2asm file.
    I compiled the same files 20 times as test and only 4 times it completed.
    Never had this problem with v3.9.29
    the program is big. >10k lines.

    Are you able to share the program? I'd like to debug this but it would be helpful to have a repro case.

    How can I send you PM or email? (i am not familiar with this forum)

    http://forums.parallax.com/discussion/161418/how-to-sending-a-pm#latest
  • Thanks to @jef_vt I was able to reproduce the problem, and sure enough it was an uninitialized variable. @JRoark , this may also be behind your intermittent crashes. I'm attaching a beta version of fastspin 4.0.3 which has the fix in it. If you are able to give this a try, please let me know if it works better for you.
  • Interesting. I’m not sure how this fits into the overall scheme of things @ersmith , but suddenly with the new 4.0.3 version I can use a smaller HEAPSIZE. Typically I’d have to run a HEAPSIZE=4096 and now I can reduce it to about half (ish) of that without throwing errors.

    No segmentation violations yet, but the night is young and the code is free and there are adult beverages waiting seductively in the fridge for me. So I’ll let ya know!
  • There's a preview of the new FlexGUI available at my Patreon page. If all goes well then the "final" 4.0.3 can arrive this weekend, in time for the new P2 eval boards :).
  • When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a FLiP:

    @ersmith It appears the GOSUB/RETURN mechanism is broken. The compiler seems to be confusing the RETURN after the GOSUB label with the RETURN for the *function* and aborting prematurely. Or perhaps said differently: "As soon as the compiler hits any RETURN, it exits the function".

    This code demonstrates the bug. Cut and copy:
    OPTION EXPLICIT
    print SillyFunction(10)
    '------------------
    FUNCTION SillyFunction(limit as integer) as string
    	dim cntr as long
    	for cntr = 1 to limit
    		gosub PrintMe
    	next cntr
    	return "All Done after " + str$(cntr) + " loops"
    PrintMe:
    	print "The loop counter value is: ";cntr
    	return
    END FUNCTION
    
    SillyFunction() should execute the PrintMe: loop 10 times and then say "All Done after 10 loops", but it never gets to the "All done" part. I'm thinking this is an ooops. :)

  • The GOSUB documentation needs to be expanded a bit. Basically GOSUB is unusable in subroutines or functions, in there it will be treated like a GOTO (because "return" will exit the enclosing function or subroutine). GOSUB is only intended for compatibility with old programs, so I'd really avoid it in any new code you're writing.
  • ersmith wrote: »
    The GOSUB documentation needs to be expanded a bit. Basically GOSUB is unusable in subroutines or functions, in there it will be treated like a GOTO (because "return" will exit the enclosing function or subroutine). GOSUB is only intended for compatibility with old programs, so I'd really avoid it in any new code you're writing.

    Yep. I dont use GOSUB, but I was playing with some old code and stumbled on it. I restructured the code and moved the offender off into its own function where it belonged, but I figured the "bug" should be escalated. It might be wise to just remove the GOSUB/RETURN functionality from the compiler and docs entirely.

  • When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a FLiP:

    @ersmith Here is a wierd one for ya. There seems to be an inconsistency in how the complier is enforcing variable names that contain a trailing "%". Test case:
    print Reverse$("ABCDEFG")
    '----------------------------------------------------------
    FUNCTION Reverse$(theString$ as string) as string
    ' Purpose:  Reverses the order of all characters in THESTRING$ and returns the swapped string
    ' Example:  Print Reverse$("ABCDEF") would output "FEDCBA"
    
       var idx% = 0
       var strLen% = 0
       var out$ = ""
    
       strLen% = len(theString$)
    
    ' Check for a zero-length string. If found, return empty string
       if strLen% = 0 then      '<---- ERIC: THIS IS THE CULPRIT (see text)
          return ""
       end if
    
    ' Step thru each character in the string starting at the end and moving to the beginning. 
    ' Copy each char in the reverse order into the output string
    
       for idx% = strLen% to 1 step -1
          out$ = out$ + mid$(theString$, idx%, 1)
       next idx%
    
       return out$
    
    END FUNCTION
    

    The code above works fine. But if you change "if strLen% = 0" to "if strLen = 0", the complier throws this:
    "d: /Flex2Gui/flexgui/bin/fastspin" -l -O1 -I "D:/Flex2Gui/flexgui/include"  "D:/Flex2Gui/flexgui/temp.bas"
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 4.0.3-preview-5d9cb6d5 Compiled on: Nov  7 2019
    temp.bas
    fmt.c
    strings.bas
    gcptrs.spin
    strlen.c
    temp.pasm
    Done.
    d:/Flex2Gui/flexgui/temp.pasm:312: error: Destination operand too big for cmp
    child process exited abnormally
    Finished at Sun Nov 10 12:52:01 2019
    
  • @JRoark: Ouch, that's a nasty bug. The problem is that the symbol "strLen" is being resolved to the C library symbol "strlen" (since no definition was provided for it in the BASIC code, but it was used in that code). If you replace "strLen" with something like "theStrlen" everywhere then the error message is much more sensible.

    I'll have to think about how to handle this one.

    Thanks for the bug report!
  • That possibility never even crossed my mind, but it sure makes sense.

    I do tend to break things in obtuse and head-scratching ways. You should see my garage... :)
  • JRoarkJRoark Posts: 1,214
    edited 2019-11-12 21:15
    When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a P2-EVAL rev B board:

    @ersmith It appears that SELECT cant handle an expression or returning value from a function. Here is a cut-n-copy for ya:
    print "Silly$ returned: ["; Silly$(1);"]"
    '-----------------------------------------
    FUNCTION Silly$(a as integer) as string
       select case str$(a)      '<--- THIS LINE
          case "1"
             return "It was a 1"
          case "2"
             return "It was a 2"
          case else
             return "It wasnt a 1 or 2"
       end select
    END FUNCTION
    
    If you run that, you'll see that FlexBASIC doesn't like anything except a variable in the SELECT CASE line. If you put an expression of any sort there, the SELECT/END SELECT either goes off into Neverland, or returns random garbage. However, rewriting it this way makes it work every time:
    print "Silly$ returned: ["; Silly$(1);"]"
    '-----------------------------------------
    FUNCTION Silly$(a as integer) as string
       dim tmp$ as string
       tmp$ = str$(a)        'assign temp variable
       select case tmp$      'do the SELECT using the variable instead of an expression
          case "1"
             return "It was a 1"
          case "2"
             return "It was a 2"
          case else
             return "It wasnt a 1 or 2"
       end select
    END FUNCTION
    
    An important point: The code that triggered this bughunt worked flawlessly when compiled on the P1. In other words, SELECT CASE worked fine taking the output of a function as its test parameter. But as soon as I complied it and ran it for the P2, that was when the bug manifested itself. Nope. It breaks on the P1 too. My mistake.
  • That looks like a bad bug all right. Thanks for reporting it @JRoark , I'll see what I can do about fixing it!
  • JRoarkJRoark Posts: 1,214
    edited 2019-11-14 18:28
    When using FlexGUI 4.0.3, under Win10 and coding in BASIC for a P2-EVAL rev B board:

    @ersmith It appears that MOD isn't converting non-integer data types to integer prior to mod'ing and instead throws a "internal error unhandled operator". Here is a cut-n-copy for ya:
       x = 3.0 mod 2      '<-- throws the error
       y = 3 mod 2      '<-- happy camper/works as expected
    
    The error that gets thrown by the compiler is below.
    "d:/Flex2Gui/flexgui/bin/fastspin" -2b -l -O1 -I "D:/Flex2Gui/flexgui/include"  "D:/Flex2Gui/flexgui/test.bas"
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 4.0.3 Compiled on: Nov  9 2019
    test.bas
    d:/Flex2Gui/flexgui/test.bas:3: error: internal error unhandled operator
    child process exited abnormally
    Finished at Thu Nov 14 12:19:18 2019
    
  • Hmmm, MOD seems to be an interesting case, in fastbasic it always seems to do an integer operation. Is that what is desired? I would have expected for example "3.1 mod 2" to evaluate to "1.1", but it seems to evaluate to "1". Doing everything in integer (like fastbasic) would be straightforward to implement. Any objections?

  • yetiyeti Posts: 818
    edited 2019-11-15 13:26
    I hadn't even thought that "float mod float —▷ float" or "float mod int —▷ float" would make sense, so I wouldn't miss it. Division with remainder is an integer only thing for me. At least until now. Maybe I need to rethink that?
    A>mbasic
    BASIC-85 Rev. 5.29
    [CP/M Version]
    Copyright 1985-1986  $  by Microsoft
    Created: 28-Jul-85
    38968 Bytes free
    Ok
    print 3.1 mod 2
     1 
    Ok
    █
    
    Maybe not.
  • Maybe I missed it, but is there a listing of key words / reserved words for version 4.0.3 commands? I am interested in using the ADC and DAC smart pin functions.
  • yeti wrote: »
    I hadn't even thought that "float mod float —▷ float" or "float mod int —▷ float" would make sense, so I wouldn't miss it. Division with remainder is an integer only thing for me. At least until now. Maybe I need to rethink that?
    A>mbasic
    BASIC-85 Rev. 5.29
    [CP/M Version]
    Copyright 1985-1986  $  by Microsoft
    Created: 28-Jul-85
    38968 Bytes free
    Ok
    print 3.1 mod 2
     1 
    Ok
    █
    
    Maybe not.

    Looks like mbasic and fastbasic agree that mod only operates on integers, so I'll go along with that -- it's actually easier to implement that way too, since there's already code for treating the logical operators that way.

    Thanks,
    Eric
  • PropGuy2 wrote: »
    Maybe I missed it, but is there a listing of key words / reserved words for version 4.0.3 commands? I am interested in using the ADC and DAC smart pin functions.

    The doc/basic.pdf file has a pretty complete listing of the BASIC language support. doc/spin.pdf documents extensions to Spin (it expects you to already know Spin or to use the Prop1 Spin manual as reference) and doc/c.pdf documents the C support (again, it's just changes from the C standard).

    So far there aren't any library functions for dealing with the smart pins, other than the SmartSerial.spin object for doing serial I/O. Contributions in this area are welcome :).
  • ersmith wrote: »
    Hmmm, MOD seems to be an interesting case, in fastbasic it always seems to do an integer operation. Is that what is desired? I would have expected for example "3.1 mod 2" to evaluate to "1.1", but it seems to evaluate to "1". Doing everything in integer (like fastbasic) would be straightforward to implement. Any objections?

    Good points, all.

    My understanding from some previous posts was that FreeBASIC was sort of the goal for compatibility. Not really a strict compliance, mind you, but my understanding was that was the general intent of FlexBASIC. If so, then restricting MOD solely to integers is fine and would actually be the expected behavior. But of course if you toss a float at MOD, it needs to accept it and deal with it gracefully. :)

    That being said, I’d also like to have a BASIC version of the C language FMod() function (I call it ModF() in my own library so the compiler stays happy) that accepts two floats as inputs and returns a float. I seem to do a lot of spherical trig, and in these cases PI (or some multiple of PI) always winds-up getting fed to MOD, and you just cant get there from here efficiently with integer scaling and a MOD operator.

    Food for thought...
  • evanhevanh Posts: 15,091
    Eric,
    Pnut treats a RES directive in an ORGH block as an error. Fastspin fails to complain and then makes a group of them all the same address - whatever hub address the assembling is at.
  • roglohrogloh Posts: 5,119
    edited 2019-11-19 12:30
    Also Eric, I ran into 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.

    font                                        '64 entry font table stored here
    initialregion                               '...as well as scratch/sync code
    
    ' SDTV interlaced sync code (PAL variant coded, NTSC is patched)
    
    interlacedsd                                'some different sync code patches
                testb   fieldcount, #0 wc       'field interlace state
    cy    if_c  call    #\hsync                 'deal with interlaced field lines
    ci    if_c  xcont   m_slim, hsync0          'send a slim half line
    
              ' ... less than 64 instructions
    
               res     64 - ($-font)           'allocate remainder of font/scratch area
    linebufsize res     1
    scanline    res     1
    rowscan     res     1
    
    
  • evanh wrote: »
    Eric,
    Pnut treats a RES directive in an ORGH block as an error. Fastspin fails to complain and then makes a group of them all the same address - whatever hub address the assembling is at.

    RES advances the COG PC and leaves the HUB PC alone (so no HUB space is allocated for it). That's why the HUB address doesn't change. I guess it makes sense to print an error for RES after ORGH, and I've made it do that now.

Sign In or Register to comment.