I've tried a few of my spin2 files, and they mostly worked. Compatibility is now quite good, if you write your code first in PNUT and then use the same in Fastspin.
One problem I have found: locktry() and lockrel() of spin2 are not supported yet. Should not be a big thing.
I've tried a few of my spin2 files, and they mostly worked. Compatibility is now quite good, if you write your code first in PNUT and then use the same in Fastspin.
One problem I have found: locktry() and lockrel() of spin2 are not supported yet. Should not be a big thing.
Below is a code snippet from SimpleSerial.spin2 by @JonnyMac
pub hex(value) | digits
'' Transmit value in hexadecimal format
if (value == 0)
tx("0")
else
digits := ((encod value) >> 2) + 1
fhex(value, digits)
The above code worked flawlessly in earlier FlexGUI versions, but now in 4.1.5 it produces: "error: syntax error, unexpected identifier `value'"
This error pops-up a dozen times in this file, all involving the ENCOD. I'm definitely not a Spin2 guy, but it looks like ENCOD has been replaced by.... something. How do I fix this?
@JRoark: ENCOD is a .spin2 only feature, so it will only work in a file with a .spin2 extension (in .spin files it is assumed to be an ordinary variable name)
@ersmith Gotcha. But the filename is "SimpleSerial.spin2". Is there something else I need to do to have the compiler recognize it as spin2 source file? Or am I being obtuse here?
@JRoark: could you post your whole setup please? Are you compiling *just* the SimpleSerial.spin2 file, or is it being included as an object from something else? I tried the snippet you posted (adjusted to remove undefined stuff) and it compiled fine as a .spin2 file and gave the error as a .spin file, as I would expect.
Is there something about LOC not working for addresses below $400?
I have this old vga driver test file that I converted to Spin via adding a Pub Main routine and coginit for the assembly...
It's all good if I add in some buffer between the code and the bitmap. I think this pushes it past $400...
But, without that LOC doesn't work, but MOV does:
Ok, here's another strange thing...
I'm working on a code that reads in a bitmap from SD card and then displays it.
It doesn't seem like I need a defined buffer, just an address to load the bitmap to that the VGA driver can access.
But, if I don't declare a big buffer, something goes wrong...
See below, I put in a dummy buffer, just to make sure we are past $400.
I then have the SD driver read in the file to @BitmapFile
If I put in long 0[1000] we are good. long 0[640*480/4] works too.
long 0[100] doesn't work... long 0[1] doesn't work...
Any idea what is going on there?
' Bitmap
'
byte 0[2000] 'dummy buffer
orgh
BitmapFile
'orgh $1000 - $436 'justify pixels at $1000, pallete at $1000-$400
long 0[1000]'[640*480/4]'file "bitmap2.bmp" '640 x 480, 8pbb-lut
@JRoark: Thanks for checking this, there was a typo causing INSTR to act like INSTRREV. It's fixed in github now, and I hope to release a new binary soon.
I'd like to sort out what was happening for you with ENCOD, though. Do you have a reproducer for that? I'm unable to produce errors with ENCOD in .spin2 files, so there must be some kind of context dependence.
Also, I think I need to reserve the full buffer size as 0[1000] doesn't always work...
Is it true that there's a stack that starts right after code? Maybe I'm stomping on that...
If you're mixing Spin and PASM then yes, you can't make any assumptions about the memory layout and you'll definitely have to provide a buffer that's appropriately sized for what you're reading into it.
Yes, using LOC on hub addresses below $400 won't work: those addresses are interpreted as being in COG or LUT.
Really? I thought that was all fixed up long ago. Certainly I got the instruction encodings sorted.
EDIT: Just checked ... I'm readily using LOC for hubram addresses below $400. Quite a lot in fact.
EDIT2: Ah, would this be another difference between pasm2 and spin2?
Hmmm, I may have spoken too quickly. You're right, we did establish that LOC does work on hub addresses below $400 in some cases. But it looks like @Rayman's code was doing a relative LOC from COG to a hub address below $400, and I think that's one of the cases that doesn't work. It's certainly not something I would try. Doing an absolute LOC should always work though, i.e. doing "loc ptra, #\@buffer" should be OK even if buffer is below $400.
@JRoark: Thanks for checking this, there was a typo causing INSTR to act like INSTRREV. It's fixed in github now, and I hope to release a new binary soon.
I'd like to sort out what was happening for you with ENCOD, though. Do you have a reproducer for that? I'm unable to produce errors with ENCOD in .spin2 files, so there must be some kind of context dependence.
Unfortunately the project is 9 files and something like 10k lines, requires an offboard gps, RTC, rotary encoder, etc. But I will try to break this disaster down into a simple demo of the problem today. In the interim I just punted and replaced ENCOD with “>|” and it seems to work. I’m starting to realize that, like it or not, I’m going to have to learn Spin. And with quarantine happening, I’ve completely run out of excuses! Lol
@ersmith Once I stripped it all down, its an easy demo case. Here is the cut-n-paste code, and I'll upload the two different versions of SimpleSerial (one works, one breaks as shown) as attachments. All that is needed to do is comment/uncomment the CLASS definitions and change the paths to whatever is on your machine. (Set tab stops to 3 in Flexgui if you want it pretty.)
' ---------------------------------------------------------------------------------
' Simple test program to demonstrate an oddity relating to the SPIN2 ENCOD operator
' ---------------------------------------------------------------------------------
'
' -- Simple Serial stuff
CONST GPSTXPIN = 43 ' pin to transmit data (send, output)
CONST GPSRXPIN = 41 ' pin to receive data (listen, input)
CONST GPSBAUDRATE = 9600 ' baud rate (typically 300, 1200, 2400, 4800, 9600, etc)
CONST GPSPARITY = 0 ' parity (0=None/ignore, 1=odd, 2=even)
CONST GPSDBITS = 8 ' data bits (typically 5-8 bits, but can be more)
CONST GPSSBITS = 1 ' stop bits (1 or 2)
CONST GPSPPSPIN = 45 ' pulse per sec pin (toggles once per second, exactly. Active=HI, HI=100.00 mS)
DIM char as long
'dim SER as class using "D:\Flex2Gui\flexgui\debug\simple_serial_BROKEN.spin2" ' throws the errors shown below
dim SER as class using "D:\Flex2Gui\flexgui\debug\simple_serial_WORKS.spin2" ' works. same file but with ENCOD replaced by >|
SER.startx(GPSRXPIN, GPSTXPIN, GPSBAUDRATE)
SER.rxflush()
do
char = SER.rxcheck()
loop
' ---------------------------------------------------------------------------------
' Notes and compiler output
' ---------------------------------------------------------------------------------
'Compiling with this:
' dim SER as class using "D:\Flex2Gui\flexgui\debug\simple_serial_BROKEN.spin2"
'
'Gives this:
' "d:/Flex2Gui/flexgui/bin/fastspin" -2 -l -O1 -I "d:/Flex2Gui/flexgui/include" -I "d:/Flex2Gui/flexgui/P2 Libs" "d:/Flex2Gui/flexgui/Debug/EncodErrorDemo.bas"
' Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
' Version 4.1.5 Compiled on: Apr 18 2020
' EncodErrorDemo.bas
' |-simple_serial_BROKEN.spin2
' d:\Flex2Gui\flexgui\debug\simple_serial_BROKEN.spin2:347: error: syntax error, unexpected identifier `value'
' d:\Flex2Gui\flexgui\debug\simple_serial_BROKEN.spin2:370: error: syntax error, unexpected identifier `value'
' d:\Flex2Gui\flexgui\debug\simple_serial_BROKEN.spin2:396: error: syntax error, unexpected identifier `value'
' d:\Flex2Gui\flexgui\debug\simple_serial_BROKEN.spin2:413: error: syntax error, unexpected identifier `value'
' child process exited abnormally
' Finished at Sun Apr 19 08:58:27 2020
'
@JRoark : Thanks for the example! It turns out it was a fairly specific problem, and only shows up on Windows: if you use an absolute path starting with a drive letter (like C:) then the wrong language is selected, due to a weird typo in the code. The work-around for now is to use relative paths or to leave off the drive letter. I've checked a fix in to github and it'll be in the next binary release.
@"John Abshier" : The inline assembly in jm_analog.spin2 is causing problems because of the "longmove(@apin, @pin, 5)" command, which forces all the variables to be on the stack (and hence not in registers). This should have produced a more useful error or warning.
The work-arounds are either to rewrite the inline assembly in Spin (which should be no problem for that example) or else to replace the longmove with a series of assignments like:
@JRoark : Thanks for the example! It turns out it was a fairly specific problem, and only shows up on Windows: if you use an absolute path starting with a drive letter (like C:) then the wrong language is selected, due to a weird typo in the code. The work-around for now is to use relative paths or to leave off the drive letter. I've checked a fix in to github and it'll be in the next binary release.
@"John Abshier" : The inline assembly in jm_analog.spin2 is causing problems because of the "longmove(@apin, @pin, 5)" command, which forces all the variables to be on the stack (and hence not in registers). This should have produced a more useful error or warning.
The work-arounds are either to rewrite the inline assembly in Spin (which should be no problem for that example) or else to replace the longmove with a series of assignments like:
I've uploaded a flexgui 4.1.6-beta to my Patreon page which has a number of the bug fixes discussed above (e.g. for the problems @"Mike Green" and @JRoark found).
Yes, using LOC on hub addresses below $400 won't work: those addresses are interpreted as being in COG or LUT.
Really? I thought that was all fixed up long ago. Certainly I got the instruction encodings sorted.
EDIT: Just checked ... I'm readily using LOC for hubram addresses below $400. Quite a lot in fact.
EDIT2: Ah, would this be another difference between pasm2 and spin2?
Hmmm, I may have spoken too quickly. You're right, we did establish that LOC does work on hub addresses below $400 in some cases. But it looks like @Rayman's code was doing a relative LOC from COG to a hub address below $400, and I think that's one of the cases that doesn't work. It's certainly not something I would try. Doing an absolute LOC should always work though, i.e. doing "loc ptra, #\@buffer" should be OK even if buffer is below $400.
That was fixed too. Not specifying absolute is exactly how I enter all my LOCs, including Cogexec to low hubRAM. I haven't needed the backslash for anything since I got you to fix the bug. I even went to the trouble of removing them from earlier code.
If I declare a byte array in the main code like this:
dim buffer(64) as ubyte
... and then pass that array BYREF as a parameter into a function, is there a way I can determine the size of this array from within that function? What I'm looking for is something like _builtin_strsize but works on byte arrays. (FWIW I'm working on library functions that won't have the luxury of already knowing how big any given array is, and need to make sure that I don't go stomping-off the end of the array and into muddy waters).
Unfortunately there's no way at run time to get the size of an array that was passed to a function. In some BASICs arrays are more complicated things that include information about the base index and size as well as the actual array data, but in FlexBASIC it's just the data.
@whicker That was going to be my fallback position.
@ersmith I sort of figured this might be a non-starter, but figured it never hurts to ask. Thanks for the guidance!
@ersmith When coding in FlexBASIC 4.1.6-beta under Win10:
I'm having an issue with passing a byte array into a SUB using BYREF. It seems the BYREF keyword is ignored. What is really odd is the SUB doesn't ever get the values being passed to it. I could understand if the values passed to the SUB were correct but any changes made to them didn't propagate back to the caller. Instead the *structure* of the passed array gets passed to the SUB but its full of uninitialized data, and any changes made to the data in the array within the sub does not get returned. This code demonstrates it.
OPTION EXPLICIT
dim main_buffer(16) as ubyte
var n = 0
print "Running: ":print
print "MAIN: byte array data values BEFORE call to SUB"
for n = 0 to 15
main_buffer(n) = 255
print "["; main_buffer(n); "] ";
next n
print
ByRefTest(main_buffer())
print "MAIN: byte array data values AFTER call to SUB)"
for n = 0 to 15
main_buffer(n) = 255
print "["; main_buffer(n); "] ";
next n
print:print
Print "End."
'
' ======================================================================================
'
SUB ByRefTest(byref local_buffer() as ubyte)
dim i as long
print
print "BYREFTEST: byte array data values INSIDE of SUB BEFORE modification"
for i = 0 to 15
print "["; cast(ulong, local_buffer(i)); "] ";
next i
for i = 0 to 15
local_buffer(i) = i
next i
print:print
print "BYREFTEST: byte array data values INSIDE of SUB after modification"
for i = 0 to 15
print "["; cast(ulong, local_buffer(i)); "] ";
next i
print:print
END SUB
This is the output:
Running:
MAIN: byte array data values BEFORE call to SUB
[255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255]
BYREFTEST: byte array data values INSIDE of SUB BEFORE modification
[0] [1] [236] [99] [253] [2] [0] [0] [255] [0] [236] [231] [252] [0] [0] [0]
BYREFTEST: byte array data values INSIDE of SUB after modification
[0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]
MAIN: byte array data values AFTER call to SUB)
[255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255] [255]
End.
Is this a FlexBASIC problem or another loose nut behind the keyboard?
Comments
One problem I have found: locktry() and lockrel() of spin2 are not supported yet. Should not be a big thing.
Andy
pub hex(value) | digits '' Transmit value in hexadecimal format if (value == 0) tx("0") else digits := ((encod value) >> 2) + 1 fhex(value, digits)The above code worked flawlessly in earlier FlexGUI versions, but now in 4.1.5 it produces: "error: syntax error, unexpected identifier `value'"This error pops-up a dozen times in this file, all involving the ENCOD. I'm definitely not a Spin2 guy, but it looks like ENCOD has been replaced by.... something. How do I fix this?
EDIT: Would just replacing ENCOD with >| work?
I have this old vga driver test file that I converted to Spin via adding a Pub Main routine and coginit for the assembly...
It's all good if I add in some buffer between the code and the bitmap. I think this pushes it past $400...
But, without that LOC doesn't work, but MOV does:
mov ptra, ##BitmapFile 'loc ptra, #@BitmapFileI'm working on a code that reads in a bitmap from SD card and then displays it.
It doesn't seem like I need a defined buffer, just an address to load the bitmap to that the VGA driver can access.
But, if I don't declare a big buffer, something goes wrong...
See below, I put in a dummy buffer, just to make sure we are past $400.
I then have the SD driver read in the file to @BitmapFile
If I put in long 0[1000] we are good. long 0[640*480/4] works too.
long 0[100] doesn't work... long 0[1] doesn't work...
Any idea what is going on there?
' Bitmap ' byte 0[2000] 'dummy buffer orgh BitmapFile 'orgh $1000 - $436 'justify pixels at $1000, pallete at $1000-$400 long 0[1000]'[640*480/4]'file "bitmap2.bmp" '640 x 480, 8pbb-lutAlso, I think I need to reserve the full buffer size as 0[1000] doesn't always work...
Is it true that there's a stack that starts right after code? Maybe I'm stomping on that...
EDIT: Just checked ... I'm readily using LOC for hubram addresses below $400. Quite a lot in fact.
EDIT2: Ah, would this be another difference between pasm2 and spin2?
I'd like to sort out what was happening for you with ENCOD, though. Do you have a reproducer for that? I'm unable to produce errors with ENCOD in .spin2 files, so there must be some kind of context dependence.
If you're mixing Spin and PASM then yes, you can't make any assumptions about the memory layout and you'll definitely have to provide a buffer that's appropriately sized for what you're reading into it.
Hmmm, I may have spoken too quickly. You're right, we did establish that LOC does work on hub addresses below $400 in some cases. But it looks like @Rayman's code was doing a relative LOC from COG to a hub address below $400, and I think that's one of the cases that doesn't work. It's certainly not something I would try. Doing an absolute LOC should always work though, i.e. doing "loc ptra, #\@buffer" should be OK even if buffer is below $400.
Unfortunately the project is 9 files and something like 10k lines, requires an offboard gps, RTC, rotary encoder, etc. But I will try to break this disaster down into a simple demo of the problem today. In the interim I just punted and replaced ENCOD with “>|” and it seems to work. I’m starting to realize that, like it or not, I’m going to have to learn Spin. And with quarantine happening, I’ve completely run out of excuses! Lol
John Abshier
The work-arounds are either to rewrite the inline assembly in Spin (which should be no problem for that example) or else to replace the longmove with a series of assignments like:
John Abshier
Boy... that was quick! Cool! And thanks...
the multi assignment in one line is quite cool.
Makes me wonder if it may be possible to expand this to matrix operations, say
could be a way to do 64 (or even bigger) bit math without introducing a long long type in spin. Just use two variables...
I am working night shifts, so not fully awake yet.
Mike
If I declare a byte array in the main code like this: ... and then pass that array BYREF as a parameter into a function, is there a way I can determine the size of this array from within that function? What I'm looking for is something like _builtin_strsize but works on byte arrays. (FWIW I'm working on library functions that won't have the luxury of already knowing how big any given array is, and need to make sure that I don't go stomping-off the end of the array and into muddy waters).
@ersmith I sort of figured this might be a non-starter, but figured it never hurts to ask. Thanks for the guidance!
I'm having an issue with passing a byte array into a SUB using BYREF. It seems the BYREF keyword is ignored. What is really odd is the SUB doesn't ever get the values being passed to it. I could understand if the values passed to the SUB were correct but any changes made to them didn't propagate back to the caller. Instead the *structure* of the passed array gets passed to the SUB but its full of uninitialized data, and any changes made to the data in the array within the sub does not get returned. This code demonstrates it. This is the output: Is this a FlexBASIC problem or another loose nut behind the keyboard?