My setup, for now is, using spin2gui to compile, and from the command line, use the propeller-load.exe to run the program.
You could also use "Configure Commands..." to change the Run command to use propeller-load instead of proploader.
Below is my test_temp program and the values that are being printed are way off. Did something happen to the '#' floating point variable, in the last update of fastspin?
I'm not sure what's going on there. I haven't changed anything in the floating point code lately that I'm aware of. You're not passing the --fixedreal option to fastspin by any chance are you? That would change BASIC to use fixed point for single variables, but the Spin part would still be using FloatMath and the two wouldn't be able to communicate properly.
I also tried using '%' integer variable in place of '#', to see what would happen, still was getting some way off results. I also noticed that by using '%' integer variable, it increased the size of the program by ~4000. I thought it would be the other way around.
The integer print code has a bunch of formatting code (for PRINT USING) that the floating point doesn't have yet. I need to find a way to remove most of that when PRINT USING doesn't actually get used.
I think I'm close to having a decent colorizer for FastBasic in SpinEdit (see attached).
@Rayman: that looks very nice!
I think I see some keywords not in documentation's list:
waitcnt getcnt clkfreq waitpeq waitpne const heapsize new delete chr$
Whoops! "const", "new", and "delete" definitely should have been in that list!
waitcnt, getcnt, waitpeq, waitpne, and chr$ are built-in functions, rather than keywords. You can redefine them (although it's probably better not to). heapsize is kind of an odd case in that syntactically it's a constant identifier, but redefining it to anything other than an integer is probably a very very bad idea, so maybe it should be treated as a keyword as well.
Also, what is with "mscycles"?
Do you need to define it to use "pausems"?
No, I think it's appearance in source code is just a leftover from the time when we were defining "pausems" ourselves. "pausems" is in the standard library now, so we don't have to define it (it's another predefined function).
Version 3.9.8
- Added __propeller__ symbol to preprocessor
- Added SELECT CASE to BASIC
- Fixed a nasty buffer overflow in integer prints
- Fixed close #n (it was losing the object pointer)
- Fixed an optimizer bug in replacing registers
- Fixed an assembly output bug when the input contains only leaf
functions
- Made for loops with float variables work
- Fixed missing _rx function for P2
There's also an undocumented feature which will be obvious to those who've read the source, but isn't ready for prime-time yet so I've left it as an "easter egg". (Hint: .bas is no longer the only file extension that's handled specially).
There's also an undocumented feature which will be obvious to those who've read the source, but isn't ready for prime-time yet so I've left it as an "easter egg". (Hint: .bas is no longer the only file extension that's handled specially).
That's the kind of (text) adventure I love to play!
\o/
Version 3.9.8
- Added __propeller__ symbol to preprocessor
- Added SELECT CASE to BASIC
- Fixed a nasty buffer overflow in integer prints
- Fixed close #n (it was losing the object pointer)
- Fixed an optimizer bug in replacing registers
- Fixed an assembly output bug when the input contains only leaf
functions
- Made for loops with float variables work
- Fixed missing _rx function for P2
There's also an undocumented feature which will be obvious to those who've read the source, but isn't ready for prime-time yet so I've left it as an "easter egg". (Hint: .bas is no longer the only file extension that's handled specially).
Seems to have rapid progress
In another thread, there are P2 fft comments and tests, is fastspin basic able to run fft yet ?
Over in FreeBASIC , Search found 21 matches: Fast Fourier Transform
A single source file that can use the new __propeller__ symbol in preprocessor, to run/report on either P2 or PC would make a great example ...
In another thread, there are P2 fft comments and tests, is fastspin basic able to run fft yet ?
Over in FreeBASIC , Search found 21 matches: Fast Fourier Transform
I'm sure it could, but I don't have a FreeBASIC version of the fftbench benchmark and I haven't had the time to port it from Spin or C yet. The performance of a BASIC version would be very similar to that of the fastspin compiled Spin version, I think, since the underlying compiler is the same. I can't think of anything in BASIC or in Spin that would give either language an edge in this benchmark.
You don't know how much I wish that were true . Any chance we might see an xlisp for P2?
If we have a C compiler for P2 then we can have XLISP. I guess it would even be possible to use XBYTE to make a fast XLISP VM. Who would actually use it though is a good question. At one point MIT was using Scheme in their introductory programming class and some students used XLISP because it was a superset of the version of Scheme that they were using at the time. That MIT class now uses Python. It might be more productive to look into what would be required to implement the Python VM using XBYTE.
If we have a C compiler for P2 then we can have XLISP. I guess it would even be possible to use XBYTE to make a fast XLISP VM. Who would actually use it though is a good question. At one point MIT was using Scheme in their introductory programming class and some students used XLISP because it was a superset of the version of Scheme that they were using at the time. That MIT class now uses Python. It might be more productive to look into what would be required to implement the Python VM using XBYTE.
Yes, I'd expect Python to be more widely accepted. There are already Pythons on other moderately large MCUs, so the industry already expects that.
spin2gui has everything you need for development, but it's a pretty bare bones GUI; something like @rayman's Spin tool would be nicer. If you just want the command line version of fastspin you can get it from the first link.
This release is mainly a bug fix release and is intended to provide a reasonably stable baseline. The underlying compiler is probably going to change a lot for the next release in order to provide better support for C input. C isn't officially supported yet because the compiler is still case insensitive and there are some other missing features (like structures and unions), but fastspin is capable of compiling very simple C programs even now, for example:
C support? That's cool! It will be interesting to try this with BlocklyProp when it is fleshed about a bit more. How much effort will be required to make it able to compile the Simple Libraries?
C support? That's cool! It will be interesting to try this with BlocklyProp when it is fleshed about a bit more. How much effort will be required to make it able to compile the Simple Libraries?
I haven't looked yet, but if the Simple Libraries are plain C89 (which at a first glance they generally seem to be) then it should be pretty straightforward to support them.
Spin2gui on the Mac: When first started, the text in the buttons doesn't show. If you grab the lower right corner of the window and make it a little bigger or smaller, when the window is re-drawn, the button labels are properly shown.
C support? That's cool! It will be interesting to try this with BlocklyProp when it is fleshed about a bit more. How much effort will be required to make it able to compile the Simple Libraries?
BlocklyProp should emit a consistent C style, so that should be easy to test and cover too ?
More of a monitor... But, something to see the value of HUB variables over serial port.
Actually, if you are compiling the code, can't you insert breakpoints that jumps to a serial interface routine before resuming?
And recompile the code every time the user changes breakpoints? An interesting idea, but I don't think it's practical -- for one thing it would cause variables to move around in memory, which could cause a lot of trouble at run time.
I was hoping that someone else already had a debugger that I could interface with. I'm not really an expert at writing GUIs, and the compiler itself will be plenty of work for me...
ELF appears well documented https://wiki.osdev.org/ELF_Tutorial
DWARF info https://en.wikipedia.org/wiki/DWARF says "Version 5 of the DWARF format was published in February 2017.[4][5] It "incorporates improvements in many areas: better data compression, separation of debugging data from executable files, improved description of macros and source files, faster searching for symbols, improved debugging of optimized code, as well as numerous improvements in functionality and performance.""
Maybe Debug and Link support for P2 needs a separate thread ?
I wrote a Zero Footprint Debugger for P1 (search for similar named thread). It lives in the shadow RAM and uses LMM HUBEXEC to execute the debug instructions. It works for both PASM and the SPIN Interpreter.
I used Viewport a lot, some years ago, but lost my key somehow and Hanno is awol. I do not need it anymore but it was nice to use.
Since Fastspin can include Spin-Objects I see no problem in just using ViewPort, It just needs one object (conduit) to do the communication between Prop and ViewPort.
Comments
I think this doesn't work:
Oops, have too many Props connected to my PC..
You could also use "Configure Commands..." to change the Run command to use propeller-load instead of proploader.
I'm not sure what's going on there. I haven't changed anything in the floating point code lately that I'm aware of. You're not passing the --fixedreal option to fastspin by any chance are you? That would change BASIC to use fixed point for single variables, but the Spin part would still be using FloatMath and the two wouldn't be able to communicate properly.
The integer print code has a bunch of formatting code (for PRINT USING) that the floating point doesn't have yet. I need to find a way to remove most of that when PRINT USING doesn't actually get used.
Thanks,
Eric
@Rayman: that looks very nice!
Whoops! "const", "new", and "delete" definitely should have been in that list!
waitcnt, getcnt, waitpeq, waitpne, and chr$ are built-in functions, rather than keywords. You can redefine them (although it's probably better not to). heapsize is kind of an odd case in that syntactically it's a constant identifier, but redefining it to anything other than an integer is probably a very very bad idea, so maybe it should be treated as a keyword as well.
No, I think it's appearance in source code is just a leftover from the time when we were defining "pausems" ourselves. "pausems" is in the standard library now, so we don't have to define it (it's another predefined function).
Thanks for your comments!
Eric
Yes, I forgot to implement _rx in the P2 runtime code. I'll fix that ASAP.
Thanks!
Eric
GUI+fastspin: https://github.com/totalspectrum/spin2gui/releases
just fastspin: https://github.com/totalspectrum/spin2cpp/releases
The changelog reads:
There's also an undocumented feature which will be obvious to those who've read the source, but isn't ready for prime-time yet so I've left it as an "easter egg".
\o/
In another thread, there are P2 fft comments and tests, is fastspin basic able to run fft yet ?
Over in FreeBASIC , Search found 21 matches: Fast Fourier Transform
A single source file that can use the new __propeller__ symbol in preprocessor, to run/report on either P2 or PC would make a great example ...
I'm sure it could, but I don't have a FreeBASIC version of the fftbench benchmark and I haven't had the time to port it from Spin or C yet. The performance of a BASIC version would be very similar to that of the fastspin compiled Spin version, I think, since the underlying compiler is the same. I can't think of anything in BASIC or in Spin that would give either language an edge in this benchmark.
You don't know how much I wish that were true
Cool, that's great to hear. Thanks for trying it on the Mac!
fastspin compiler: https://github.com/totalspectrum/spin2cpp/releases
spin2gui GUI: https://github.com/totalspectrum/spin2gui/releases
spin2gui has everything you need for development, but it's a pretty bare bones GUI; something like @rayman's Spin tool would be nicer. If you just want the command line version of fastspin you can get it from the first link.
This release is mainly a bug fix release and is intended to provide a reasonably stable baseline. The underlying compiler is probably going to change a lot for the next release in order to provide better support for C input. C isn't officially supported yet because the compiler is still case insensitive and there are some other missing features (like structures and unions), but fastspin is capable of compiling very simple C programs even now, for example:
#define PIN 26 void main(void) { unsigned long pinmask = 1<<PIN; DIRA |= pinmask; while(1) { OUTA ^= pinmask; waitcnt(40000000 + CNT); } }The ultimate goal is that the fastspin engine will allow mixing of code from Spin, BASIC, and C, with output for either P1 or P2.
I haven't looked yet, but if the Simple Libraries are plain C89 (which at a first glance they generally seem to be) then it should be pretty straightforward to support them.
... and Assembler ...
that's sounding quite compelling. Does this have Debug support ?
BlocklyProp should emit a consistent C style, so that should be easy to test and cover too ?
http://onerobot.org/#ViewPort
More of a monitor... But, something to see the value of HUB variables over serial port.
Actually, if you are compiling the code, can't you insert breakpoints that jumps to a serial interface routine before resuming?
I think Chip is changing some things like ">=" for Spin2...
It's kind of a Spin 1.5 syntax. It's compatible with Spin1 (so ">=" is still an assignment) but has many of the Spin2 operators.
And recompile the code every time the user changes breakpoints? An interesting idea, but I don't think it's practical -- for one thing it would cause variables to move around in memory, which could cause a lot of trouble at run time.
I was hoping that someone else already had a debugger that I could interface with. I'm not really an expert at writing GUIs, and the compiler itself will be plenty of work for me...
I think some work has already been done in this thread, in at least looking at Object file formats and Linkers.
http://forums.parallax.com/discussion/168535/pnut-and-p2asm-and-other-p2-tools/p1
ELF appears well documented https://wiki.osdev.org/ELF_Tutorial
DWARF info https://en.wikipedia.org/wiki/DWARF says
"Version 5 of the DWARF format was published in February 2017.[4][5] It "incorporates improvements in many areas: better data compression, separation of debugging data from executable files, improved description of macros and source files, faster searching for symbols, improved debugging of optimized code, as well as numerous improvements in functionality and performance.""
Maybe Debug and Link support for P2 needs a separate thread ?
I wrote a Zero Footprint Debugger for P1 (search for similar named thread). It lives in the shadow RAM and uses LMM HUBEXEC to execute the debug instructions. It works for both PASM and the SPIN Interpreter.
This may be of some use to you.
+1
So nice just to Watch <var> and have it show up on the terminal.
Since Fastspin can include Spin-Objects I see no problem in just using ViewPort, It just needs one object (conduit) to do the communication between Prop and ViewPort.
So it will even work with FastSpin(Basic)
Mike