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
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.
@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.
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..
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.
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 ?
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.
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.
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.
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.
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...
Comments
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:
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:
'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 daysinmonthIt 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 assignmentThat makes me happy. Thank you Eric! Happy to do my part.
Now, I am off to play!
Do you ever actually sleep?
I think Chip has fixed it. His current manual says:
Yes, SmartSerial was broken by a different change that I thought would be harmless
Seems to be all OK.
USB and 90's 3D all working.
Loc in hubexec seems to work with or without the "\".
Here is the FlexBASIC code fragment that initiates the error:
Here is the debug information from the Flex2GUI compiler pane:
Here is the offending snippet of the PASM file;
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.
Why do you need to use `!` here ?
"PI!" would be single precision floating point.
Dim k As Single, factor As Double, s As String
and inti vars as
Dim scalar_symbol As DataType] = expression
Right, I forgot to mention that the array things are totally separate issues. It will be a while before I can fix those, sorry.
Thanks for finding this!
Eric
I'll better quit thinking... ;-D
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.
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.
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:
Is this intentional? If so, I'll change my code to match...
Note: It starts with "D:", not the emoji...