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

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

12425272930116

Comments

  • RaymanRayman Posts: 13,797
    BTW: The "test.spin2" for testing the USB seems to report the cog# incorrectly... You have to subtract 1 due to the driver adding 1 to it...
  • evanhevanh Posts: 15,126
    Try the -2b option. Assuming the -2a bug is still there.
  • RaymanRayman Posts: 13,797
    I did, that didn't seem to have any affect...
  • JRoarkJRoark Posts: 1,214
    edited 2019-09-22 17:29
    I was playing with FlexBasic (current release) on a P1 (Flip) and seem to have found one new bug and one.... limitation (?).... or something.

    1). Use of a PRINT statement *immediately* upon program execution produces garbage characters as output. It seems like the PRINT critter just isn't ready for business yet. But if you put a short delay in there (usually 50-75 mS works), then it works fine. No garbage chars. The code snippets below show this workaround while showing the second issue...

    2). It seems you cant declare an array from within a Function. The only way to get an array within a function is to have declared it previously as SHARED at the module level. For example, this code works:
    option explicit
    dim shared daysInMonth(1 to 12) as integer
    pausems(250)		'pause briefly. The PRINT function gets woofie without this
    
    print "Days = "; NumOfDaysInMonth(5)	'return the number of days in the 5th month (May)
    
    '------------------------------------------------------------------------------------------
    FUNCTION NumOfDaysInMonth(myMonth% as integer) as integer
    'Returns the number of days in the month specified by MYMONTH%
    
       'setup the days of the month
       daysInMonth(1) = 31	'january
       daysInMonth(2) = 28	'february (+1 if leap year)
       daysInMonth(3) = 31	'march
       daysInMonth(4) = 30	'april
       daysInMonth(5) = 31	'may
       daysInMonth(6) = 30	'june
       daysInMonth(7) = 31	'july
       daysInMonth(8) = 31	'august
       daysInMonth(9) = 30	'september
       daysInMonth(10) = 31	'october
       daysInMonth(11) = 30	'november
       daysInMonth(12) = 31	'december
    
       return daysInMonth(myMonth%)
    
    END FUNCTION
    

    But if we move the DIM into the function, the code throws a "error: daysinmonth is not a function" for each of the 12 array elements:
    option explicit
    pausems(250)		'pause briefly. The PRINT function gets woofie without this
    
    print "Days = "; NumOfDaysInMonth(5)	'return the number of days in the 5th month (May)
    
    '------------------------------------------------------------------------------------------
    FUNCTION NumOfDaysInMonth(myMonth% as integer) as integer
    'Returns the number of days in the month specified by MYMONTH%
    
    dim daysInMonth(1 to 12) as integer
    
       'setup the days of the month
       daysInMonth(1) = 31	'january
       daysInMonth(2) = 28	'february (+1 if leap year)
       daysInMonth(3) = 31	'march
       daysInMonth(4) = 30	'april
       daysInMonth(5) = 31	'may
       daysInMonth(6) = 30	'june
       daysInMonth(7) = 31	'july
       daysInMonth(8) = 31	'august
       daysInMonth(9) = 30	'september
       daysInMonth(10) = 31	'october
       daysInMonth(11) = 30	'november
       daysInMonth(12) = 31	'december
    
       return daysInMonth(myMonth%)
    
    END FUNCTION
    
  • JRoarkJRoark Posts: 1,214
    edited 2019-09-22 18:51
    I'm still working around the edges of string arrays, this time using an alternate syntax. I'm encountering interesting behaviors:
    'From the module level:
       dim shared as integer daysInMonth(1 to 12) = {31,28,31,30,31,30,31,31,30,31,30,31}   'this works fine
       dim as integer daysInMonth(1 to 12) = {31,28,31,30,31,30,31,31,30,31,30,31}   'error: initialization is not supported for member variable daysinmonth
    
    It seems to me that if a DIM SHARED is allowed by the compiler, then a plain ol' DIM (no SHARED) in the same syntax form should work as well because SHARED is an optional attribute.

    And this gives an unexpected result that is likely tied to the second DIM example given above:
    'From within a Function:
       dim as integer daysInMonth(1 to 12) = {31,28,31,30,31,30,31,31,30,31,30,31}   'error: incompatible types in assignment
    
  • Hey, I get some P2 time today. On my update to what is now called FlexGUI, I see this nice note:
    Thanks to the support of my patrons at https://www.patreon.com/totalspectrum we have a digital signing certificate, which should remove the Windows Authenticode warnings for flexgui. Thank you to everyone who has contributed, and if you find fastspin/flexgui useful please consider signing up as a patron to continue to support its development!

    That makes me happy. Thank you Eric! Happy to do my part.

    Now, I am off to play!

  • @ersmith I just looked at the new FlexBASIC docs. Love ‘em!!! A TOC, version/date and everything! This stuff is really starting to look professional grade.

    Do you ever actually sleep? :)
  • Cluso99 wrote: »
    Code cannot run in hub below $400 from what Chip has said.
    Ah, OK. I thought there might be a way to trick the processor, but it makes sense that it's just plain impossible.
    If your definitions are correct, then Chip needs to change his document as it disagrees.

    I think Chip has fixed it. His current manual says:
    Absolute addressing can be forced by the use of "\" after the "#".

    The "@" operator can be used before an address label to return the hub address of that label, in case it was defined under an ORG directive to generate cog code, and the label would normally return the cog address..
  • Rayman wrote: »
    USB doesn't seem to work with the new fastspin either...

    I'm working with the "test.spin2" I think ersmith posted here earlier...
    It could be the serial coms that are broke, not sure...

    Nope, doesn't appear to be just the serial coms. I rigged it to toggle P56 led on keypress and it doesn't do it with new fastspin...

    Yes, SmartSerial was broken by a different change that I thought would be harmless :(. I'll be posting a new version of fastspin soon.
  • Ok, that answers my question. I can wait for it. Comms from BASIC appear to work.

  • I've posted a new version (3.9.33) of fastspin and flexgui which I hope will fix the issues people had with 3.9.32
  • Well cool!

  • RaymanRayman Posts: 13,797
    Congrats!
    Seems to be all OK.
    USB and 90's 3D all working.

    Loc in hubexec seems to work with or without the "\".
  • On the FlexBASIC side of the house, with regards to the latest version (Version 3.9.33 compiled on Sep 22 2019), this doesn't seem to have resolved any of the findings that I reported earlier today. Not complaining here. I just wanted to close the loop and report back.
  • I found an interesting bit of code that does not cause the BASIC parser to throw an immediate error, but when the assembler tries to assemble the resulting PASM code, then it throws an error.

    Here is the FlexBASIC code fragment that initiates the error:
       OPTION EXPLICIT
       const _clkfreq = 80_000_000
       const PI! = 3.14159     '<--- this is the offending line
       const HEAPSIZE = 4096
       ...
    

    Here is the debug information from the Flex2GUI compiler pane:
    "./bin/fastspin" -l -O1 -L "./include" "D:/Flex2Gui/flexgui/JeffsStandardLib.bas"
    Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2019 Total Spectrum Software Inc.
    Version 3.9.33 Compiled on: Sep 22 2019
    JeffsStandardLib.bas
    fmt.c
    strings.bas
    gcptrs.spin
    strcpy.c
    strlen.c
    JeffsStandardLib.pasm
    d:/Flex2Gui/flexgui/JeffsStandardLib.pasm:3: error: syntax error, unexpected '!', expecting end of line or ','
    child process exited abnormally
    Finished at Sun Sep 22 19:25:26 2019
    

    Here is the offending snippet of the PASM file;
    con
    	_clkfreq = 80000000
    	pi! = 1078530000	'<-- Line 3: "error: syntax error, unexpected '!', expecting end of line or ','"
    	heapsize = 4096
    pub main
      coginit(0, @entry, 0)
    dat
    ...
    
  • @JRoark
    I think constants (const) are direct substitution.
    So for example, when you say const PI = 3.14159
    from that point on, whenever you type PI in an expression, internally it substitutes 3.14159 for you.

    As for how to avoid type confusion, the manual says:
    Only numeric values (integers and floats) may be declared with const.

    It would see an integer as anything not with a decimal point .
    if you would need to force a number to float, you'd add .0 to the end of it. for example 10.0 is a float and 10 is an integer.


  • jmgjmg Posts: 15,140
    JRoark wrote: »
    I found an interesting bit of code that does not cause the BASIC parser to throw an immediate error, but when the assembler tries to assemble the resulting PASM code, then it throws an error.

    Here is the FlexBASIC code fragment that initiates the error:
       OPTION EXPLICIT
       const _clkfreq = 80_000_000
       const PI! = 3.14159     '<--- this is the offending line
       const HEAPSIZE = 4096
       ...
    
    ...
    Using the `!` inside a variable name, is unusual, and strictly I'd expect the Basic compiler to give the same error message as the Assembler.
    Why do you need to use `!` here ?
  • potatoheadpotatohead Posts: 10,253
    edited 2019-09-23 07:30
    In very old BASICS, seen on 8 bit computers, that suffix character indicated numeric type: (From a TRS-80 BASIC Manual)
    Variables
    A numeric variable stores a numeric value of type integer, single, or double. The lexical structure of a numeric variable name is letter {letter | number}* [{ % | ! | # }]. However, only the first two characters of a variable name are significant. Thus, AA, AAA, AAAA, etc. are all considered to be the same variable. The suffix character "%" indicates an integer value, "!" indicates a single, and "#" indicates a double. Variables are dynamically typed unless their type is explicitly specified using one of these suffix characters or a type declaration. Variable names cannot contain any BASIC keyword as a substring. An uninitialized numeric variable is considered to have value 0.
    A string variable stores a string value. The lexical structure of a string variable name is letter {letter | number}* $ (i.e. the same as a numeric variable but with $ appended). Like numeric variable names, only the first two characters are significant. As with numeric variables, string variable names cannot contain any BASIC keyword as a substring. Strings are implicitly dynamically allocated and their contents and length can be changed at any time. String length cannot exceed 255. There is no character type; a character is represented by a string of length 1. The empty string "" is a valid string, and has length 0.

    "PI!" would be single precision floating point.

  • jmgjmg Posts: 15,140
    More modern dialects, like FreeBASIC, which this one somewhat tracks, deprecates suffix chaff and instead supports DIM AS

    Dim k As Single, factor As Double, s As String
    and inti vars as
    Dim scalar_symbol As DataType] = expression
  • Yup, they do. I just wanted to explain the construct to ease the conversation along.
  • JRoark wrote: »
    On the FlexBASIC side of the house, with regards to the latest version (Version 3.9.33 compiled on Sep 22 2019), this doesn't seem to have resolved any of the findings that I reported earlier today. Not complaining here. I just wanted to close the loop and report back.

    Right, I forgot to mention that the array things are totally separate issues. It will be a while before I can fix those, sorry.

  • JRoark wrote: »
    I found an interesting bit of code that does not cause the BASIC parser to throw an immediate error, but when the assembler tries to assemble the resulting PASM code, then it throws an error.
    Yes, there's a bug in the handling of CONST names that contain !, #, $, or %. For now I suggest avoiding those characters in CONST names.

    Thanks for finding this!
    Eric

  • ersmith wrote: »
    Yes, there's a bug in the handling of CONST names that contain !, #, $, or %. For now I suggest avoiding those characters in CONST names.
    Wow! I stumbled over this a while ago and just thought it were intentionally so.
    I'll better quit thinking... ;-D
  • All of these things are true. I acknowledge the use of type declaration characters is deprecated in many modern BASIC dialects. There are certainly better ways to write the example code. But “deprecated” does not mean “wrong”. It just shows a preference. Lots of people will be coming at this compiler from different skill levels and differing generations of dialect. Some people will even write their first “Hello world!” program in FlexBASIC. So I’d suggest that absent a formal declaration of non-support, a BASIC compiler should ideally support as much deprecated syntax as reasonably possible.

    In my code examples the BASIC parser didnt throw an error, and strictly speaking, it should not have, because the syntax it encountered (while odd by “modern” standards), was generally valid. Instead the assembler threw an error, which suggests a rules conflict between the two that might need addressing.

    This may be a good time to begin a discussion about how much (if any) of the deprecated elements should be finally dropped. Personally I’d miss the removal of type-declaration characters (&$@!%#), but I survived the removal of line numbers once, so I could probably find the strength to soldier on... :)

    BTW: I’m not trying to find esoteric or impossible-case bugs here. I make interesting knots of the compiler because some of the libraries I’m porting over are 30+ years old and they reflect the coding styles and language features of that time. This makes for some interesting smoke sometimes.
  • @ersmith Looks like you posted just as I was. Anyway... this all sounds good to me! You've made some wonderful progress on this project. I'll keep banging on it until someone tells me to stop. :)
  • Cluso99Cluso99 Posts: 18,066
    Eric,
    Were there changes to loadp2 from version 3.9.31 to 3.9.33?

    v3.9.33 fails to run programs that run fine with v3.9.31 :(

    pnut compiles and loads/runs fine. I have compared the fastspin and pnut binarys and they are fine.

  • RaymanRayman Posts: 13,797
    edited 2019-09-28 13:19
    Looks like the compile error message format was changed, right?

    I had SpinEdit rigged so that double-clicking on the error would jump the editor to the line in question.
    Looks like I'm looking for "Line (" or "error".
    But now, the error messages look like this:
    D:\Propeller2\P2_EvalBoard\FSRW\test_1a\test_1a.spin2:77: error: unknown identifier string1 used in function call
    

    Is this intentional? If so, I'll change my code to match...

    Note: It starts with "D:", not the emoji...
  • Rayman: You can swap the “D” for lower case and it wont trigger the emoji.
  • RaymanRayman Posts: 13,797
    You'd think the software would be smart enough to not mess with text inside of "code" a tag...
  • Rayman wrote: »
    You'd think the software would be smart enough to not mess with text inside of "code" a tag...
    ...and don't ask about (AT)variable, (AT)(AT)variable and (AT)(AT)(AT)variable in code blocks!
    
    (AT) —▷ @
    ...and don't ask about @variable, @@variable and @@@variable in code blocks!
    
Sign In or Register to comment.