@ersmith That makes sense. I also wasnt seeing the distinction between an “error” (handled by GETERR) and “exception” (catch/try). Words have meaning! And I see you posted some fresh code, so thank you!
There's a new version of FlexProp (version 5.4.3) available now, with a number of bug fixes and some minor improvements (e.g. the P2 command line shell now supports the "type" command to display files from the SD card or host).
@ersmith said:
If there's no sd card then the mount would fail. I don't think there's any other reliable way, and indeed I removed sdmmc_is_present() from the file system code a while back because it didn't always work (there may still be a copy in loadp2, but if so you could probably ignore it).
@ersmith Re: Flex 5.4.3
I can confirm that the "bugginess" with a successful OPEN returning an error is cured in 5.4.3.
Interestingly, if no SD card is installed, MOUNT doesn't throw an error or an exception. It simply chugs along and reports back as "OK". The exception (error 12, "I/O Error") only gets thrown when you try to do an OPEN after the MOUNT. This code shows it:
dim myerr as long
try
print "Attempting MOUNT"
mount "/sd", _vfs_open_sdcard()
print "MOUNT returned: ";strerror$(geterr())
print "Attempting OPEN"
open "/sd/testfile.log" for append as #3
print "OPEN returned: "; strerror$(geterr())
catch myerr
print "Whoops: ";myerr; " aka: "; strerror$(myerr)
end try
I report this only because the MOUNT behavior is different than what you expressed above as the expected behavior. From where I'm sitting, this isn't a bug since it is just as easy to trap the error at the OPEN phase.
@ersmith said:
There's a new version of FlexProp (version 5.4.3) available now, with a number of bug fixes and some minor improvements (e.g. the P2 command line shell now supports the "type" command to display files from the SD card or host).
Oh, there is indeed. I think you may have forgotten to put it on the spin2cpp releases page.
@Wuerfel_21 I note (goodnaturedly, and with tongue planted firmly in cheek) that it's on his Patreon page.
Nudge-nudge. Wink-wink.
Support your local genius. (You need a Patreon page, btw!)
I know that it's there early, but it is on the FlexProp github already, but not on the spin2cpp one.
I don't really care for myself, anyways (I only need the CLI tools, which I could compile myself (but in practice I just pull the CI artifacts)), but I hate releasing code that requires a compiler version that doesn't quite exist yet. (Because as I like to jokingly say, I usually find 1 flexspin bug each day I use it...)
@ersmith said:
There's a new version of FlexProp (version 5.4.3) available now, with a number of bug fixes and some minor improvements (e.g. the P2 command line shell now supports the "type" command to display files from the SD card or host).
Oh, there is indeed. I think you may have forgotten to put it on the spin2cpp releases page.
The last spin2cpp release was downloaded by a grand total of two (2) people. The one before that got 3 downloads. I don't think it's worth providing binary releases any more.
@ersmith I seem to have found an error in multi-value returns from functions in FlexBASIC V5.4.3. This code throws "error: Not enough elements on right hand side of assignment"
dim A,B as ubyte
A,B = SomeFunc()
print A,B
FUNCTION SomeFunc() as ubyte, ubyte
dim Y as ubyte
dim Z as ubyte
Y = &hFF
Z = &h00
return Y, Z
END FUNCTION
But if we change all the UBYTEs to ULONGs, it works fine:
dim A,B as ulong
A,B = SomeFunc()
print A,B
FUNCTION SomeFunc() as ulong, ulong
dim Y as ulong
dim Z as ulong
Y = &hFF
Z = &h00
return Y, Z
END FUNCTION
So the short story seems to be that returning multiple UBYTE values from a function is broken. Any thoughts?
EDITED TO ADD: I posted that right as you released 5.5.0-Beta. Running the same code under 5.5.0-Beta gives the same error as above but also adds: "warning: Internal assert failure: func numresults inconsistent for function SomeFunc"
Thanks for the bug report @JRoark . Yes, BASIC isn't handling multiple return values that are smaller than 4 bytes correctly. It should be fixed in the next release.
Eric,
I cannot see the fit command in the listing. Is it supposed to be there?
The program is OS243.spin2 and the fit command is in SD_DRIV.spin2 line 1762.
flexprop v5.4.3
Ray: Listing files are based on the generated code, so things like FIT and RES that don't generate any code don't always show up, particularly in sub-objects (the top level object is handled a bit differently). I will try to add some special cases for FIT and RES so that they will show in the next version.
Thanks Eric. I looked to see how close to the limit I was in an object so I searched for the fit line. I found others (I think they may have been internallly generated) but not the one I wanted.
So thought I would report it but it's certainly not a requirement.
I don't use the listing often, but when you need it - it's brilliant
There's a new version of FlexProp, 5.5.0, available at the usual places (see the first post or my signature for links). Changes to the compiler in this version include:
- Added warning for modifying ptra in inline assembly
- Added throwifcaught command for BASIC
- Allowed '$' in inline assembly in C
- Fixed a problem with large ranges in lookup/lookdown
- Fixed a preprocessor bug which sometimes caused failure to recognize comments
- Fixed a bug in handling multiple return values that are less than long sized
- If -Wall is given, warn about uninitialized local variables
- Implemented "public" and "private" in C++ classes
- Improved listing file output by adding RES and FIT entries
Improved listing file output by adding RES and FIT entries
Speaking of fit, seems that it doesn't support the limit value specified on the org line, like this:
DAT org $000, $1F0
Would be possible to add ?
Another question: it is possible to generate spin bytecode like Propeller Tool instead of the 'fast' code ? I'm looking at a Linux alternative to Propeller Tool but would like to generate the same binaries.
@macca said:
Speaking of fit, seems that it doesn't support the limit value specified on the org line, like this:
DAT org $000, $1F0
Would be possible to add ?
I'll look into this.
Another question: it is possible to generate spin bytecode like Propeller Tool instead of the 'fast' code ? I'm looking at a Linux alternative to Propeller Tool but would like to generate the same binaries.
This would be a lot of work, requiring:
Reverse engineering of the meaning of all the spin bytecodes from the interpreter
Implementation of a compiler backend to emit these spin bytecodes
Integration of inline assembly
All of the above done twice, once for P2 and once for P1, since the byte code is different between them
Unless some benefactor decides to hire me to do that work (or a whole lot more people decide to sign up for my Patreon) I doubt I will be able to find the time for this .
Reverse engineering of the meaning of all the spin bytecodes from the interpreter
Parts of this already exists as code in Spinix's Spin compiler, Sphinxcompiler, Homespun and OpenSpin. Spinix has a Spin bytecode assembler, that may be a start. Or had? In some versions only?
But sure documenting the bytecode should have been done at it's original source. Maybe there even exists some forgotten documentation?
@macca said:
Speaking of fit, seems that it doesn't support the limit value specified on the org line, like this:
DAT org $000, $1F0
Would be possible to add ?
I'll look into this.
Another question: it is possible to generate spin bytecode like Propeller Tool instead of the 'fast' code ? I'm looking at a Linux alternative to Propeller Tool but would like to generate the same binaries.
This would be a lot of work, requiring:
Reverse engineering of the meaning of all the spin bytecodes from the interpreter
Implementation of a compiler backend to emit these spin bytecodes
Integration of inline assembly
All of the above done twice, once for P2 and once for P1, since the byte code is different between them
Unless some benefactor decides to hire me to do that work (or a whole lot more people decide to sign up for my Patreon) I doubt I will be able to find the time for this .
Not sure about Spin2, but compiling Spin1 from an AST is not very difficult. I've read a good bit of the homespun source and it really just walks down the AST, emitting corrosponding bytecode along the way (though there is a bit context to it, such as QUIT mapping to a different opcode in a REPEAT N type loop (this was the source of one of the bugs I fixed in homespun, that bit of context didn't get restored after leaving a loop)). From a casual look, it would though seem to be difficult to hook it all up to the existing framework.
Reverse engineering of the meaning of all the spin bytecodes from the interpreter
Parts of this already exists as code in Spinix's Spin compiler, Sphinxcompiler, Homespun and OpenSpin. Spinix has a Spin bytecode assembler, that may be a start. Or had? In some versions only?
But sure documenting the bytecode should have been done at it's original source. Maybe there even exists some forgotten documentation?
The interpreter source does document the bytecodes, but you have to search around to locate specific bytecodes. It takes a bit of reverse engineering to figure it out, but it is doable from the source code. I wrote a bytecode assembler call spasm that runs under spinix. There were never any official names assigned to the bytecodes, so I created some names to use with spasm. The documentation for the spasm assembler is in the attached text file.
I was really thinking more of Spin2 as the difficult bytecode set to reverse engineer. I'm aware that there has been previous work to document the Spin1 bytecode set. Of course Spin1 bytecode has its own set of problems when it comes to implementing flexspin/basic/c, such as lack of support for unsigned operations and no way to escape to assembly code.
I really don't think I will be able to implement bytecode any time soon, so this is probably moot. Although I'm always happy to receive pull requests for flexspin, should someone else want to take the task on!
@Rayman said:
@ersmith Would it be difficult to build flexspin.exe as a 64-bit app?
Probably not, but I don't see a lot of benefit to it -- as long as some people are still using 32 bit Windows it seems safer to distribute it as a 32 bit binary that works under both environments.
Eric, just want to say you're doing a great job. Your work needs to be celebrated for what it does. It stands on its own as the only useful cross-platform multiple programming language compiler for the Propeller 2.
It's flexible, fast, and well documented. And for years now you've been very responsive with bug fixes and clarifications.
I too wish more people would sign up with Patreon. Not only for the hopes of further development and features, but to pay you back for the functionality you've created here and now.
When one does sign up for a monthly contribution, just think of Patreon acting as a kind of software delivery service where one can receive emails to go download the latest updates.
@Rayman said:
@ersmith Would it be difficult to build flexspin.exe as a 64-bit app?
Probably not, but I don't see a lot of benefit to it -- as long as some people are still using 32 bit Windows it seems safer to distribute it as a 32 bit binary that works under both environments.
Most applications make both 32 & 64 bit flavors available nowadays. Maybe something to consider?
@ersmith said:
I really don't think I will be able to implement bytecode any time soon, so this is probably moot. Although I'm always happy to receive pull requests for flexspin, should someone else want to take the task on!
I think I'll give it a shot. First goal would be to produce unoptimized Spin1 binaries identical to other Spin compilers and then go from there. Implementation will probably suck, lol.
@ersmith said:
I really don't think I will be able to implement bytecode any time soon, so this is probably moot. Although I'm always happy to receive pull requests for flexspin, should someone else want to take the task on!
I think I'll give it a shot. First goal would be to produce unoptimized Spin1 binaries identical to other Spin compilers and then go from there. Implementation will probably suck, lol.
Just committed some initial bytecode work. Is mostly going as easy as I thought it'd be, though I did overengineer some system to figure out ideal jump sizes. Probably was not necessary. Shouldn't bee too difficult to get it to something useable.
Comments
@ersmith That makes sense. I also wasnt seeing the distinction between an “error” (handled by GETERR) and “exception” (catch/try). Words have meaning! And I see you posted some fresh code, so thank you!
There's a new version of FlexProp (version 5.4.3) available now, with a number of bug fixes and some minor improvements (e.g. the P2 command line shell now supports the "type" command to display files from the SD card or host).
@ersmith Re: Flex 5.4.3
I can confirm that the "bugginess" with a successful OPEN returning an error is cured in 5.4.3.
Interestingly, if no SD card is installed, MOUNT doesn't throw an error or an exception. It simply chugs along and reports back as "OK". The exception (error 12, "I/O Error") only gets thrown when you try to do an OPEN after the MOUNT. This code shows it:
dim myerr as long try print "Attempting MOUNT" mount "/sd", _vfs_open_sdcard() print "MOUNT returned: ";strerror$(geterr()) print "Attempting OPEN" open "/sd/testfile.log" for append as #3 print "OPEN returned: "; strerror$(geterr()) catch myerr print "Whoops: ";myerr; " aka: "; strerror$(myerr) end tryI report this only because the MOUNT behavior is different than what you expressed above as the expected behavior. From where I'm sitting, this isn't a bug since it is just as easy to trap the error at the OPEN phase.
Oh, there is indeed. I think you may have forgotten to put it on the spin2cpp releases page.
@Wuerfel_21 I note (goodnaturedly, and with tongue planted firmly in cheek) that it's on his Patreon page.
Nudge-nudge. Wink-wink.
Support your local genius. (You need a Patreon page, btw!)
I know that it's there early, but it is on the FlexProp github already, but not on the spin2cpp one.
I don't really care for myself, anyways (I only need the CLI tools, which I could compile myself (but in practice I just pull the CI artifacts)), but I hate releasing code that requires a compiler version that doesn't quite exist yet. (Because as I like to jokingly say, I usually find 1 flexspin bug each day I use it...)
The last spin2cpp release was downloaded by a grand total of two (2) people. The one before that got 3 downloads. I don't think it's worth providing binary releases any more.
Well, I guess most people that use the command line tools alone compile them from source...
I myself generally only update to whatever git revision that fixes the showstopping bug of the day, so I myself rarely use the proper releases.
I guess there's still the ability to download CI artifacts or rip the binaries out of a FlexProp release.
@ersmith I seem to have found an error in multi-value returns from functions in FlexBASIC V5.4.3. This code throws "error: Not enough elements on right hand side of assignment"
dim A,B as ubyte A,B = SomeFunc() print A,B FUNCTION SomeFunc() as ubyte, ubyte dim Y as ubyte dim Z as ubyte Y = &hFF Z = &h00 return Y, Z END FUNCTIONBut if we change all the UBYTEs to ULONGs, it works fine:
dim A,B as ulong A,B = SomeFunc() print A,B FUNCTION SomeFunc() as ulong, ulong dim Y as ulong dim Z as ulong Y = &hFF Z = &h00 return Y, Z END FUNCTIONSo the short story seems to be that returning multiple UBYTE values from a function is broken. Any thoughts?
EDITED TO ADD: I posted that right as you released 5.5.0-Beta. Running the same code under 5.5.0-Beta gives the same error as above but also adds: "warning: Internal assert failure: func numresults inconsistent for function SomeFunc"
Thanks for the bug report @JRoark . Yes, BASIC isn't handling multiple return values that are smaller than 4 bytes correctly. It should be fixed in the next release.
Eric,
I cannot see the fit command in the listing. Is it supposed to be there?
The program is OS243.spin2 and the fit command is in SD_DRIV.spin2 line 1762.
flexprop v5.4.3
Thanks for a great compiler
Ray: Listing files are based on the generated code, so things like FIT and RES that don't generate any code don't always show up, particularly in sub-objects (the top level object is handled a bit differently). I will try to add some special cases for FIT and RES so that they will show in the next version.
Thanks,
Eric
Thanks Eric. I looked to see how close to the limit I was in an object so I searched for the fit line. I found others (I think they may have been internallly generated) but not the one I wanted.
So thought I would report it but it's certainly not a requirement.
I don't use the listing often, but when you need it - it's brilliant
There's a new version of FlexProp, 5.5.0, available at the usual places (see the first post or my signature for links). Changes to the compiler in this version include:
Speaking of fit, seems that it doesn't support the limit value specified on the org line, like this:
Would be possible to add ?
Another question: it is possible to generate spin bytecode like Propeller Tool instead of the 'fast' code ? I'm looking at a Linux alternative to Propeller Tool but would like to generate the same binaries.
I'll look into this.
This would be a lot of work, requiring:
Unless some benefactor decides to hire me to do that work (or a whole lot more people decide to sign up for my Patreon) I doubt I will be able to find the time for this
.
Parts of this already exists as code in Spinix's Spin compiler, Sphinxcompiler, Homespun and OpenSpin. Spinix has a Spin bytecode assembler, that may be a start. Or had? In some versions only?
But sure documenting the bytecode should have been done at it's original source. Maybe there even exists some forgotten documentation?
Not sure about Spin2, but compiling Spin1 from an AST is not very difficult. I've read a good bit of the homespun source and it really just walks down the AST, emitting corrosponding bytecode along the way (though there is a bit context to it, such as QUIT mapping to a different opcode in a REPEAT N type loop (this was the source of one of the bugs I fixed in homespun, that bit of context didn't get restored after leaving a loop)). From a casual look, it would though seem to be difficult to hook it all up to the existing framework.
Uhh, the Spin1 bytecodes are documented right in the interpreter source
The interpreter source does document the bytecodes, but you have to search around to locate specific bytecodes. It takes a bit of reverse engineering to figure it out, but it is doable from the source code. I wrote a bytecode assembler call spasm that runs under spinix. There were never any official names assigned to the bytecodes, so I created some names to use with spasm. The documentation for the spasm assembler is in the attached text file.
@ersmith Would it be difficult to build flexspin.exe as a 64-bit app?
I was really thinking more of Spin2 as the difficult bytecode set to reverse engineer. I'm aware that there has been previous work to document the Spin1 bytecode set. Of course Spin1 bytecode has its own set of problems when it comes to implementing flexspin/basic/c, such as lack of support for unsigned operations and no way to escape to assembly code.
I really don't think I will be able to implement bytecode any time soon, so this is probably moot. Although I'm always happy to receive pull requests for flexspin, should someone else want to take the task on!
Probably not, but I don't see a lot of benefit to it -- as long as some people are still using 32 bit Windows it seems safer to distribute it as a 32 bit binary that works under both environments.
Eric, just want to say you're doing a great job. Your work needs to be celebrated for what it does. It stands on its own as the only useful cross-platform multiple programming language compiler for the Propeller 2.
It's flexible, fast, and well documented. And for years now you've been very responsive with bug fixes and clarifications.
I too wish more people would sign up with Patreon. Not only for the hopes of further development and features, but to pay you back for the functionality you've created here and now.
When one does sign up for a monthly contribution, just think of Patreon acting as a kind of software delivery service where one can receive emails to go download the latest updates.
Most applications make both 32 & 64 bit flavors available nowadays. Maybe something to consider?
I think I'll give it a shot. First goal would be to produce unoptimized Spin1 binaries identical to other Spin compilers and then go from there. Implementation will probably suck, lol.
Just committed some initial bytecode work. Is mostly going as easy as I thought it'd be, though I did overengineer some system to figure out ideal jump sizes. Probably was not necessary. Shouldn't bee too difficult to get it to something useable.
\o/ What a towelday! \o/
;-D
Something neat I implemented while working on the bytecode stuff: Colored error messages.
https://github.com/totalspectrum/spin2cpp/pull/135
nice