My current code is compiling nicely. The wrong label offset is fixed for hub strings. It found a couple of minor bugs - amazing how I missed them but it had worked anyway (ie using ## in a call instead of a single #).
Oh, and it's now reporting errors with correct line numbers and object.
Thanks again Eric
@ersmith
Hello. I'm presenting a BASIC stress-test program for an issue I'm sometimes seeing.
It has all 8 COGS running. They're printing something (a burger ingredient), and then waiting.
Each cog waits a different amount of time.
The waits are chosen to really get the prints to overlap.
My expectation would be that PRINT would be thread-safe. But it currently is not.
What I mean by that, is that if one cog is in the middle of printing a string, and another tries to print, that second one would wait.
Essentially be first-come first-serve. Or rather, first to check gets it, and keep checking.
Here is an example output.
It starts off trampling on itself.
Runs for maybe 30 times almost ok.
And then gets stuck mostly printing Tomato and Pickles for a while.
With this new era of multiple cores, I don't know what "the rules" should be. But I'm thinking having PRINT block until it can succeed is probably the way?
Yes, PRINT is definitely not thread safe; it uses the serial tx pin, so like any pin access it must either be centralized to one COG or be explicitly protected by locks.
It would be a nice addition to have this done automatically, but (a) I'm not sure what the correct granularity is (probably the whole print statement, but that might introduce delays when printing the result of a complicated function) and (b) I want to minimize the overhead for the common case where just one COG is printing. I'll look at it, but it may take some time.
FlexGUI 4.2.2 is available now from the usual places. The editor has a few improvements, including optional automatic indentation of code (so when you hit return the next line starts with the same indentation as the previous line). The compiler has several bug fixes, including an important fix for ASM CONST in BASIC and some major fixes to P1 input functions.
OK, not to start a language war but I do want to correct something here: there's nothing special about Spin2 with regards to the P2 hardware. Don't get me wrong, Spin2 is a nice language and Chip has done a good job designing it. But the unique features of Spin2 (e.g. multiple return values, the SEND := mechanism) are not hardware specific, and the hardware specific features (various built-in functions and inline assembly) are easily added to other languages. As proof I offer the BASIC and C dialects in fastspin. There's nothing you can do in Spin2 that you can't do in those languages. If you think I'm wrong, please provide a counter-example.
So how do you use the SEND mechanism with flexC (and flexBasic) ?
I tried several things, but could not get it to work. I want to provide a C example with one of my objects, that use SEND in Spin2. Would be nice to show that this is also usable in C.
FlexGUI 4.2.3 is available now on github and Patreon. It has some important bug fixes in fastspin (including a lookup/lookdown alignment bug that could be triggered when code and/or data was re-arranged) and some new examples in the samples/Multi-Language directory. I plan on discussing those on the Zoom call on Wednesday .
FlexGUI 4.2.4 is now available. The fastspin compiler in this version has a lot of bug fixes and Spin2 compatibility improvements, so I highly recommend upgrading. The changes include:
Version 4.2.4
- Added FVAR and FVARS for Spin2
- Fixed "-C" option for case sensitivity
- Fixed detection of result variables in inline asm (e.g. polxy builtin)
- Fixed handling of # at start of line in Spin CON blocks
- Fixed handling of some Spin1 only keywords and operators
- Fixed label detection on instructions like djnf
- Fixed Spin2 ENCOD operator
- Fixed a -O2 loop optimization bug which could lose assignments inside IF
- Implemented INPUT #n in BASIC
- Improved handling of structure returns in C
- Improved handling of passing methods as function pointers
- Made the ?: ternary operator parse better in Spin2
- Optimized P2 multiplication by constants
- Optimized bytefill/bytemove on P2
- Properly supported expressions on strings (like "abc"|m) in Spin
FlexGUI 4.2.6 is now available. There are a number of significant improvements in the fastspin compiler:
Version 4.2.6
- Added sanity check for removing inlined functions (fixes an optimizer bug)
- Added __andthen__ and __orelse__ operators to Spin/Spin2.
- Fixed an optimizer bug in renaming registers
- Fixed assignments like x.byte[1] := y
- Fixed Spin AND and OR operators to evaluate both sides if they have side effects.
- Improved some error messages
- Merged improved P1 multiply/divide routines from Wuerfel21.
Version 4.2.5
- Added many more peephole optimizations
- Added -Wall flag for more warnings, including about language extensions
- Fixed the #warn preprocessor directive
- Fixed a bug in operator assignment (like +=) when both sides have side effects
- Fixed an optimizer bug where some conditional instructions were overlooked in optimizing cmp #0 cases
- Fixed a typo in TAN causing it to return bad values
- Fixed constant(@x - @y)
- Implemented _FREE and _STACK
- Improved optimization around ORG/END blocks (without touching the code inside)
- Improved FCACHE code to merge loops in some cases
- Improved inlining of functions
- On P2, use constants in the D field when we can
- Optimized special cases like x.byte[1] in Spin
- Optimized case statements with constant expressions
- Various other minor optimizations
There's a new release of FlexGUI (4.3.0) containing the latest fastspin compiler. This one has some preliminary support for the Spin2 DEBUG() keyword (enabled/disabled via a FlexGUI menu option) and many bug fixes and improvements to optimization. If you haven't updated in a while it's definitely time to do so .
Comments
Downloading now
Oh, and it's now reporting errors with correct line numbers and object.
Thanks again Eric
Hello. I'm presenting a BASIC stress-test program for an issue I'm sometimes seeing.
It has all 8 COGS running. They're printing something (a burger ingredient), and then waiting.
Each cog waits a different amount of time.
The waits are chosen to really get the prints to overlap.
My expectation would be that PRINT would be thread-safe. But it currently is not.
What I mean by that, is that if one cog is in the middle of printing a string, and another tries to print, that second one would wait.
Essentially be first-come first-serve. Or rather, first to check gets it, and keep checking.
Here is an example output.
It starts off trampling on itself.
Runs for maybe 30 times almost ok.
And then gets stuck mostly printing Tomato and Pickles for a while.
With this new era of multiple cores, I don't know what "the rules" should be. But I'm thinking having PRINT block until it can succeed is probably the way?
It would be a nice addition to have this done automatically, but (a) I'm not sure what the correct granularity is (probably the whole print statement, but that might introduce delays when printing the result of a complicated function) and (b) I want to minimize the overhead for the common case where just one COG is printing. I'll look at it, but it may take some time.
So how do you use the SEND mechanism with flexC (and flexBasic) ?
I tried several things, but could not get it to work. I want to provide a C example with one of my objects, that use SEND in Spin2. Would be nice to show that this is also usable in C.
Andy
As usual, the release is available from my Patreon page (https://patreon.com/totalspectrum) and from GitHub (https://github.com/totalspectrum/flexgui/releases/latest)