I've released 5.9.18 beta on Patreon. I think this is pretty close to the final release. There are a few bug fixes, and many improvements to the P2 bytecode ("nucode") generator. The generated code is now pretty small (often smaller than PNut's) and performance is improving, although still not quite up to PNut's yet. I plan eventually to add a JIT compilation module for inner loops that should dramatically improve that, but that will take a while.
@ersmith said:
performance is improving, although still not quite up to PNut's yet.
What benchmark are you using for that?
A few; fibo, toggle, and xxtea. For example, for the xxtea decompressor PNut gives a 6784 byte binary that runs in 155816 cycles, whereas flexspin -2nu -O2 gives a 3296 byte binary that runs in 200672 cycles. For recursive fibo(12) PNut is 6388 bytes / 237400 cycles and flexspin is 4348 bytes / 283528 cycles.
I don't have a lot of big Spin2 programs, but my VGA demo is 16348 bytes for PNut and 13436 bytes for flexspin -2nu, so flexspin is still competitive at that size of program. I'm not sure how much of the difference is due to unused method removal, though.
Yea, I don't have any Spin-heavy program that actually works on PropTool/PNut, either. Flexspin filesystem/sprintf/whatever is too good (though bloat from these two in particular is mildly painful)
@ersmith I have another oddity. (It takes one to know one, amiright?).
Something seems to have changed with the way string handling/garbage collection is done. What I am seeing is that GC works fine until you start passing strings to a device driver via its handle, at which time the passed string never seems to be GC'd. This code using your VGA driver will show it nicely:
#define VGA_BASE_PIN 48
CONST _CLOCKFREQ = 160_000_000
CONST HEAPSIZE = 8000
dim vga as class using "ansi.spin2"
dim n as uinteger
dim a$ as string
vga.start(VGA_BASE_PIN)
open SendRecvDevice(@vga.tx, nil, @vga.stop) as #2
for n = 1 to 125
a$ = "01234567889 abcdefghijklmnopqrstuvwxyz 01234567889 ABCDEFGHIJKLMNOPQRSTUVWXYZ " + chr$(13)
'print #2, n; "-"; a$
print n; "-"; a$
'delete a$
next n
As shown, the code works fine. But change that loop to print to the handle (#2) returned by SendRecvDevice() and it blows-up about halfway through the 125 iterations. If you uncomment the DELETE A$, that gets you back to working... for a while... but if you increase the loop iterations to 1000 or so it blows it up again.
So I'm thinking either GC as it relates to strings passed to a device driver are not being GC'd at all, and/or the GC that is happening isn't cleaning up completely.
FWIW, changing the HEAPSIZE (even to very large numbers, 32k, 64k) just kicks the can down the road until it eventually fails again. So to my mind there is definitely something odd about how GC and device drivers interact. Over to you...
ADDIT: On a separate issue #DEFINE must not have a tab char in front of it or it causes an error. A quick note to that effect in the docs might be in order.
@JRoark said:
@ersmith I have another oddity. (It takes one to know one, amiright?).
Something seems to have changed with the way string handling/garbage collection is done. What I am seeing is that GC works fine until you start passing strings to a device driver via its handle, at which time the passed string never seems to be GC'd. This code using your VGA driver will show it nicely:
No, alas, it does not show it -- that code works fine for me when I uncomment the print #2 and even when I increased the loop count to 999 . I'm using FlexProp 5.9.18-beta.
My guess is that there may be a bug in the VGA code you're using? I'm not sure which copy of ansi.spin2 / vga_tile_driver / etc. you're using. I used the one that is packaged in samples/vga in the flexprop 5.9.18 beta. Note that this has changed "recently", so it may not match yours. Also not sure what resolution you're using; I've tried the default 800x600 with full color (CELL_SIZE=8) and also 1024x768 with monochrome (CELL_SIZE=1), both of which worked at the default clock frequency. 1024x768 worked with CELL_SIZE=8, but I had to increase the clock frequency to 200_000_000 by adding
const _CLKFREQ = 200_000_000
to the program. I notice you have a _CLOCKFREQ constant defined; that doesn't have any default meaning, did you misspell _CLKFREQ?
Anyway, if none of this helps you, could you zip up a complete project (including your VGA driver) and also give me the command line you're using (or that FlexProp displays during compilation). I've tried various combinations of optimizations but they all seem to work for me.
FlexProp version 5.9.20 is available now. It has a lot of bug fixes, so I recommend updating to it. The compiler changes include:
- Added a new pass to re-calculate object sizes after symbol resolution (fixes some problems with memory overruns in C code used as Spin object)
- Added STRCOPY Spin2 function
- Fixed a crash when trivial C programs are submitted
- Fixed swapping 64 bit variables
- Fixed failure to change arrays to pointers in some C expressions
- Fixed 64 bit integer preincrement
- Fixed initializing local reference variables
- Fixed += and similar operators when used with references
- Implemented object constant overrides (object parameters) for Spin
- Implemented ... line continuation for Spin
- Inline assembly can now access multiple longs of large local variables.
- More fixes to C struct initialization
- Made debug output and C library output work better together
- Made repeat loops in Spin2 finish with the same value as in PNut
- Optimized initializers of large local variables
- Optimized long fills on P2 with SETQ (thanks to Ada Gottensträter again!)
- Remove unused methods even at -O0 optimization
- Relax type checking in C for pointer/integer conversion
Also, there's one small change to the GUI: the Help menu now includes a link to @Wuerfel_21 's great P2 documentation.
The Spin2 language has changed (again) and now FIELD is a reserved word. I'm sure @JonnyMac will have an updated version of jmfullduplexserial soon, or you can just do a search and replace and change every occurence of the variable field to something else (like fieldval).
@ersmith said:
The Spin2 language has changed (again) and now FIELD is a reserved word. I'm sure @JonnyMac will have an updated version of jmfullduplexserial soon, or you can just do a search and replace and change every occurence of the variable field to something else (like fieldval).
Thanks for pointing that out -- I will fix it today. These changes would be less bothersome if Chip would work on things we really need (e.g., a Spin2-compable uSD driver that works cleanly).
Noobie question here... I'm totally new in FlexProp and I'm trying to migrate a project from Prop Tool. Upon trying to compile it for the first time I got a syntax error on a call to a method pointer that works in Prop Tool, see screenshot
To troubleshoot I created this program that illustrates the problem:
Apparently FlexSpin doesn't recognize the method pointer using the syntax methods[0](1,2). Is this expected?
@whicker said:
@ersmith
in FlexBasic I am having trouble passing an array to a subroutine.
Multi-dimensional arrays aren't really supported very well in FlexBasic, unfortunately. I'll try to improve this in the future, but for now your best bet is to instead use structs, arrays of structs, or arrays of arrays. For example, you could declare a mat3d type similar to the vec3d. Or, you could do:
Sub MultiplyMatrixVector3(i As vec3d, o As vec3d, m() as Single(3))
@jrullan said:
Noobie question here... I'm totally new in FlexProp and I'm trying to migrate a project from Prop Tool. Upon trying to compile it for the first time I got a syntax error on a call to a method pointer that works in Prop Tool, see screenshot
Apparently FlexSpin doesn't recognize the method pointer using the syntax methods[0](1,2). Is this expected?
Not really "expected", but it is happening -- method pointers were only really tested with simple variables, not with arrays, so the array syntax isn't supported in this version. I hope that will be fixed soon. The work-around for now is to use a local variable and load the desired method pointer into that variable, and call through that. Thanks for the bug report,
@whicker and @jrullan : The most recent code (source in github) has fixes for the BASIC multi-dimensional array and Spin2 method pointer bugs you found. There's a binary on my Patreon page too. Thanks for your bug reports!
@ersmith said:
@whicker and @jrullan : The most recent code (source in github) has fixes for the BASIC multi-dimensional array and Spin2 method pointer bugs you found. There's a binary on my Patreon page too. Thanks for your bug reports!
@jrullan said:
@ersmith I opened another issue on Github. Do you prefer to be alerted of issues here or on the Github repo?
I'll look into it, thank you. The Github repo is good because it keeps track of outstanding bugs, but feel free to report here instead or as well if that's convenient for you.
@ersmith
Does anyone have a direct link to the latest flexprop. The github does not show a zip file and the patreon wants me to pay. I am confused about the patreon link. Is flexprop no longer free?
Thank you in advance.
Martin
@pilot0315 said:
@ersmith
Does anyone have a direct link to the latest flexprop. The github does not show a zip file and the patreon wants me to pay. I am confused about the patreon link. Is flexprop no longer free?
Thank you in advance.
Martin
I believe when he initially releases an update it is only available to patron’s initially and then is available for free to everyone else a bit later. I know I get an email whenever he releases a new version. I thought the older versions stayed available for download also.
Thanks.
I have been trying the github where @ersmith told me there is a drop down that says assets. Every time I click on it it just goes in circles. Hope to get it soon.
Martin
Comments
I've released 5.9.18 beta on Patreon. I think this is pretty close to the final release. There are a few bug fixes, and many improvements to the P2 bytecode ("nucode") generator. The generated code is now pretty small (often smaller than PNut's) and performance is improving, although still not quite up to PNut's yet. I plan eventually to add a JIT compilation module for inner loops that should dramatically improve that, but that will take a while.
What benchmark are you using for that?
A few; fibo, toggle, and xxtea. For example, for the xxtea decompressor PNut gives a 6784 byte binary that runs in 155816 cycles, whereas flexspin -2nu -O2 gives a 3296 byte binary that runs in 200672 cycles. For recursive fibo(12) PNut is 6388 bytes / 237400 cycles and flexspin is 4348 bytes / 283528 cycles.
Cool.
Tried how the density scales on bigger programs? With programs this small PNut obviously looses to interpreter bloat.
I don't have a lot of big Spin2 programs, but my VGA demo is 16348 bytes for PNut and 13436 bytes for flexspin -2nu, so flexspin is still competitive at that size of program. I'm not sure how much of the difference is due to unused method removal, though.
Yea, I don't have any Spin-heavy program that actually works on PropTool/PNut, either. Flexspin filesystem/sprintf/whatever is too good (though bloat from these two in particular is mildly painful)
@ersmith I have another oddity. (It takes one to know one, amiright?).
Something seems to have changed with the way string handling/garbage collection is done. What I am seeing is that GC works fine until you start passing strings to a device driver via its handle, at which time the passed string never seems to be GC'd. This code using your VGA driver will show it nicely:
#define VGA_BASE_PIN 48 CONST _CLOCKFREQ = 160_000_000 CONST HEAPSIZE = 8000 dim vga as class using "ansi.spin2" dim n as uinteger dim a$ as string vga.start(VGA_BASE_PIN) open SendRecvDevice(@vga.tx, nil, @vga.stop) as #2 for n = 1 to 125 a$ = "01234567889 abcdefghijklmnopqrstuvwxyz 01234567889 ABCDEFGHIJKLMNOPQRSTUVWXYZ " + chr$(13) 'print #2, n; "-"; a$ print n; "-"; a$ 'delete a$ next nAs shown, the code works fine. But change that loop to print to the handle (#2) returned by SendRecvDevice() and it blows-up about halfway through the 125 iterations. If you uncomment the DELETE A$, that gets you back to working... for a while... but if you increase the loop iterations to 1000 or so it blows it up again.
So I'm thinking either GC as it relates to strings passed to a device driver are not being GC'd at all, and/or the GC that is happening isn't cleaning up completely.
FWIW, changing the HEAPSIZE (even to very large numbers, 32k, 64k) just kicks the can down the road until it eventually fails again. So to my mind there is definitely something odd about how GC and device drivers interact. Over to you...
ADDIT: On a separate issue #DEFINE must not have a tab char in front of it or it causes an error. A quick note to that effect in the docs might be in order.
What? You're a compiler?
Of bad Dad-jokes, YES!
No, alas, it does not show it -- that code works fine for me when I uncomment the
. I'm using FlexProp 5.9.18-beta.
print #2and even when I increased the loop count to 999My guess is that there may be a bug in the VGA code you're using? I'm not sure which copy of ansi.spin2 / vga_tile_driver / etc. you're using. I used the one that is packaged in samples/vga in the flexprop 5.9.18 beta. Note that this has changed "recently", so it may not match yours. Also not sure what resolution you're using; I've tried the default 800x600 with full color (CELL_SIZE=8) and also 1024x768 with monochrome (CELL_SIZE=1), both of which worked at the default clock frequency. 1024x768 worked with CELL_SIZE=8, but I had to increase the clock frequency to 200_000_000 by adding
to the program. I notice you have a
_CLOCKFREQconstant defined; that doesn't have any default meaning, did you misspell_CLKFREQ?Anyway, if none of this helps you, could you zip up a complete project (including your VGA driver) and also give me the command line you're using (or that FlexProp displays during compilation). I've tried various combinations of optimizations but they all seem to work for me.
I've released FlexProp 5.9.19 on both Patreon and github. There are a lot of bug fixes in this version, including:
Also note that I've signed up for github sponsorship, as an alternate way of supporting FlexProp financially for those who prefer not to use PayPal.
FlexProp version 5.9.20 is available now. It has a lot of bug fixes, so I recommend updating to it. The compiler changes include:
Also, there's one small change to the GUI: the Help menu now includes a link to @Wuerfel_21 's great P2 documentation.
It would be good if it was pinned somewhere in the forum, but having it in Flexprop is even better.
"HyperJump" is cool AF
Switching from 5.9.16 to 5.9.20 and I get the following:
Switched back to 16 and everything is fine
Craig
The Spin2 language has changed (again) and now FIELD is a reserved word. I'm sure @JonnyMac will have an updated version of jmfullduplexserial soon, or you can just do a search and replace and change every occurence of the variable
fieldto something else (likefieldval).@ersmith
Many thanks Eric
Was thinking of hacking it anyway. Awful lot of stuff I don't need. Buffering was the main reason to start using JM_FDS
Thanks for pointing that out -- I will fix it today. These changes would be less bothersome if Chip would work on things we really need (e.g., a Spin2-compable uSD driver that works cleanly).
I have posted an update here:
-- https://forums.parallax.com/discussion/175034/updated-jm-fullduplexserial-spin2/p1?new=1
@ersmith
in FlexBasic I am having trouble passing an array to a subroutine.
Depending on how I declare array m() in the subroutine, I get either:
Sub MultiplyMatrixVector3 (i As vec3d, o As vec3d, m(3,3) As Single)
error: syntax error, unexpected integer number, expecting ')'
or
Sub MultiplyMatrixVector3 (i As vec3d, o As vec3d, m() As Single)
error: Array dereferences on non-array ((float **)m)
I've attached the code, look at about line 143
Noobie question here... I'm totally new in FlexProp and I'm trying to migrate a project from Prop Tool. Upon trying to compile it for the first time I got a syntax error on a call to a method pointer that works in Prop Tool, see screenshot
To troubleshoot I created this program that illustrates the problem:
Apparently FlexSpin doesn't recognize the method pointer using the syntax
methods[0](1,2). Is this expected?Multi-dimensional arrays aren't really supported very well in FlexBasic, unfortunately. I'll try to improve this in the future, but for now your best bet is to instead use structs, arrays of structs, or arrays of arrays. For example, you could declare a mat3d type similar to the vec3d. Or, you could do:
Not really "expected", but it is happening -- method pointers were only really tested with simple variables, not with arrays, so the array syntax isn't supported in this version. I hope that will be fixed soon. The work-around for now is to use a local variable and load the desired method pointer into that variable, and call through that. Thanks for the bug report,
@whicker and @jrullan : The most recent code (source in github) has fixes for the BASIC multi-dimensional array and Spin2 method pointer bugs you found. There's a binary on my Patreon page too. Thanks for your bug reports!
Thanks! @ersmith
@ersmith I opened another issue on Github. Do you prefer to be alerted of issues here or on the Github repo?
I'll look into it, thank you. The Github repo is good because it keeps track of outstanding bugs, but feel free to report here instead or as well if that's convenient for you.
@ersmith
Does anyone have a direct link to the latest flexprop. The github does not show a zip file and the patreon wants me to pay. I am confused about the patreon link. Is flexprop no longer free?
Thank you in advance.
Martin
I believe when he initially releases an update it is only available to patron’s initially and then is available for free to everyone else a bit later. I know I get an email whenever he releases a new version. I thought the older versions stayed available for download also.
@DiverBob
Thanks.
I have been trying the github where @ersmith told me there is a drop down that says assets. Every time I click on it it just goes in circles. Hope to get it soon.
Martin