no concept of a project in terms of a unit of several source files.
A P2 flexprop project in most cases is a directory that contains several files. There is no project description file. Instead, there is always the main file you compile, which can (and in most cases do) use another files as objects.
One of the strongest feature in Flexprop is - you can combine all 3 languages (Basic, C, Spin) in one project and it works. I prefer Basic as the main program language, but then I use all kinds of drivers written in Spin and a code written in C
You can #include the file if it is Basic or C and what you #include is in the same language as the file in which the #include is. You can declare objects written in other languages.
This is what it looks like (the beginning of the player code) - the Basic program declaring Spin programs as its objects. The same can be done in C or Spin:
const _clkfreq = 336956522
dim v as class using "hg008.spin2"
dim rm as class using "retrocog.spin2"
dim tracker as class using "trackerplayer.spin2"
dim paula as class using "audio093b-8-sc.spin2"
dim sid as class using "sidcog8.spin2"
dim psram as class using "psram.spin2"
dim spc as class using "spccog.spin2"
dim a6502 as class using "a6502-1.spin2"
#include "dir.bi"
insane complexity of VS Code
Yes. Instead of telling it where the compiler is and how to call it, you have to write some black magic incantations for every project. Not for me, too.
Yes. Instead of telling it where the compiler is and how to call it, you have to write some black magic incantations for every project. Not for me, too.
???? But that's exactly what you do? And setting it up globally instead of per-project would be really, really, really obnoxious and stupid.
Then again, I basically never actually set up any tasks in VSC. I just create a shell script that builds the program and run that from the terminal pane.
What I use for everyday programming is either Flexprop (commands->configure .... and in most cases forget until platform change)....
.... or Lazarus, in both "PC with OS" and Ultibo versions... While Lazarus has a complex project structure a "new project" option sets defaults for your hardware/system/cpu so no black magic required too.
Lazarus has also a code editor with syntax highlighting you can define, so one of my ideas is to adapt it to P2 languages/compilers. No time, as always. I was dragged into a project that I have to do in languages I don't know in a system I don't know. If it wasn't for chatGPT, which I can ask how to do this and how to call that, it would be a disaster. It still can be a disaster.
Flexprop having the commands as a global configuration falls under the same problem - as soon as you need to use a compiler option that changes the program behavior it becomes very "funny" to remember the correct settings for each project.
As said, in my opinion the by far ideal setup is to create a .sh (or .bat if one really wants) that looks maybe a little like this
@knivd said:
First, it looks to me like there is no concept of a project in terms of a unit of several source files. Am I right to assume that?
Yes, that's correct, the model is more like that of Spin where there's a main source file that includes other source files either explicitly (via #include or object references) or indirectly (via __fromfile declarations).
Is there any chance at least document tabs might appear any time soon in Flexprop?
What, precisely, do you mean here by "document tabs"? Flexprop can already open multiple documents in different tabs, if that's what you mean -- every time you open a new file from the File menu a new tab is created, similarly if you click on the hyperlink made out of #include or struct __using.
@ersmith said:
What, precisely, do you mean here by "document tabs"? Flexprop can already open multiple documents in different tabs, if that's what you mean -- every time you open a new file from the File menu a new tab is created, similarly if you click on the hyperlink made out of #include or struct __using.
Ah, I surely qualify as the today's idiot... That's what I meant, but didn't notice it is already there. Thanks
I've uploaded a new binary release (6.0.4) which fixes a bug in P1 listing output and an incorrect file name in error messages appearing after a #include of a file whose name exactly matches the end of the current file's name. It's probably worth upgrading to this version even if you haven't run into those bugs. I'm being very conservative with changes in the 6.0.x branch, only bug fixes (and fairly cautious ones at that) should be going in there.
I think I just found another Optimizer bug. In FSRW there is this methode:
pub pputs(b) : r1
' Write a string into the file open for write. Returns
' 0 if successful, or a negative number if some error occurred.
return pwrite(b, strsize(b))
When I call this methode, the optimizer inlines the whole pputs() methode and the strsize() methode is put into FCACHE:
...
02ea0 | ' return pwrite(b, strsize(b))
02ea0 00 CC 05 F6 | mov local04, #0
02ea4 68 D1 9F FE | loc pa, #(@LR__0238-@LR__0237)
02ea8 8C 00 A0 FD | call #FCACHE_LOAD_
02eac | LR__0237
02eac DE AC C9 FA | rdbyte result1, arg01 wz
02eb0 01 CC 05 51 | if_ne add local04, #1
02eb4 01 BC 05 51 | if_ne add arg01, #1
02eb8 F0 FF 9F 5D | if_ne jmp #LR__0237
02ebc | LR__0238
02ebc E6 BE 01 F6 | mov arg02, local04
02ec0 E6 BC 01 F6 | mov arg01, local04 <---- can't be right
02ec4 B8 29 B0 FD | call #_fsrw2_pwrite
...
But it does it not fully right, the arg01 also gets the stringsize instead of the original stringpointer (which is damaged by the strsize code).
@Ariba : Are you able to share a bit more of the code, at least the function that calls pputs? I'm not able to reproduce the problem with simple examples, so I suspect it is very context dependent.
@msrobots : The P2 side of the host file system code is in the file include/filesys/fs9p/fs9p_internal.cc in the flexprop distribution. The PC side is in the loadp2 and proploader sources, inside a directory called u9fs. The 9p protocol is documented in various places on the web, including at http://9p.cat-v.org/documentation/ and at https://9fans.github.io/plan9port/man/man9/intro.html .
@ersmith said:
@Ariba : Are you able to share a bit more of the code, at least the function that calls pputs? I'm not able to reproduce the problem with simple examples, so I suspect it is very context dependent.
Okay here is a heavy stripped down version that shows the error. Near the end of the top file, there is a method 'getstr'. If you comment out the marked line, the optimizer works, otherwise it produces the described error.
@Ariba Thank you for the more detailed example. I was able to track down the bug -- some registers were being re-used incorrectly when an inlined function was inside another function that was in turn inlined in a third function (in this case stringsize, inside getstr, inside savetext). It's fixed in 6.0.5, the sources for which are up on github now.
@Rayman said:
@ersmith Are all the floating point functions in math.h implemented somewhere?
I'm not seeing them all in math.c ...
They're in some of the other libsys files, like powers.c etc. The linking of the builtins to there happens through the hardcoded float.spin (found with the other hardcoded stuff in the sys directory of the source tree)
FlexProp 6.0.5 is available now (from the usual places, e.g. see my signature). It has a few minor improvements to error messages, and a fairly big bug fix in the optimizer to address the problem @Ariba found above with inline functions inside inline functions.
@ersmith said:
FlexProp 6.0.5 is available now (from the usual places, e.g. see my signature).
Not able to build 6.0.5 from latest flexprop sources on MacOSX with latest OSX SDK... Issue #69 has been posted on github.
dgately
The error is in PropLoader, which hasn't changed in a very long time, so my guess is that no version of flexprop can build with the latest OSX SDK. I'm guessing Apple broke something. It's possible that sprinkling #include at the beginning of all the .cpp files in PropLoader/src might help, at least with the nullptr_t errors, but I can't test this.
FlexProp 6.1.0 is available now in the usual places (see my signature). It has support for multi-file projects, conditional assembly, and the Spin2 FIELD[] and ^@ operations, along with some nice optimizations by @Wuerfel_21 . The full changelog is:
Version 6.1.0
- Added basic support for compiling project files (.fpide or .side)
- Implemented ^@ and FIELD[] for Spin2
- Implemented conditional assembly instructions if, elseif, else, and endif
- Merged Ada's improved strlen() function
- Merged some register allocation improvements from Ada
- Provide syntax for C `struct using` to override constants in Spin2 objects
The project files are basically the same as SimpleIDE's .side files, and in many cases FlexProp can compile those (providing the C code doesn't have any GCC specific features, which unfortunately many of the simple libraries do).
Does FlexProp has a feature to download a complete project archive (assume as a .zip file)?
Specifically- The archive must include everything to allow compilation, so I'm thinking that means common libs that are referenced in the code, but perhaps stored outside of the user code/working folder, must also be included in the archive.
The behaviour would resemble what PropellerTool archive function does, so the single zip can be shared to another user, and they can be assured the code will compile because all src references are included, and with the versions the author intended.
@VonSzarvas said:
Does FlexProp has a feature to download a complete project archive (assume as a .zip file)?
Specifically- The archive must include everything to allow compilation, so I'm thinking that means common libs that are referenced in the code, but perhaps stored outside of the user code/working folder, they must also be included in the archive.
Eric added that feature some while ago, but I myself haven't used it. Perhaps just try it out and see if it works as you'd want it to.
@VonSzarvas said:
Does FlexProp has a feature to download a complete project archive (assume as a .zip file)?
Yes, it's under the Commands menu (Commands > Create zip archive). Which now that I think about it could be considered an odd place for it, maybe the File menu would be better. But internally creating a zip archive is basically the same as compiling the program or running it (they all use flexspin as back end).
Didn't know about this. Guess this can only work if all the files that would otherwise be on the command line are included in the main file.
Does it really do all the libraries and the executables needed too?
I just tried it and didn't work...
Main file has this: #include "Antares.h"
Get this error:
error: Unable to write file C:\FlexProp\Antares.h to zip
child process exited abnormally
It's looking in wrong place for .h file, it's on D drive, like the main C file...
This is version 5.9.26 though, maybe it's been fixed?
@Rayman said:
Didn't know about this. Guess this can only work if all the files that would otherwise be on the command line are included in the main file.
Does it really do all the libraries and the executables needed too?
I just tried it and didn't work...
Main file has this: #include "Antares.h"
It looks like there's a bug in packaging C header files, due to the different preprocessor used in C. I'll fix that in the next release.
- Added special -D_XTLFREQ=x and -D_XINFREQ=x command line defines
- Fixed IF in assembly debug
- Fixed constant SIGNX evaluation
- Made the preprocessor ignore characters after a line comment start (like ')
- Made jmp relative calculations act more like the official compiler
- Use proper full name for C include files in zip creation
- Remove .zip file on failed creation
The bug fixes are significant, so I encourage upgrading to this version.
I got myself used to working with an additional FTDI chip (e.g. the venerable proplug) when working with the Px. The biggest reason for me: I don't need to juggle flashing vs monitoring by terminating by screen command (which I'm usually using). That works nicely with all the handrolled stuff so far, but I want to leverage the stdio-library of flexspin/prop. However there the output pins are hard-wired. I'd be interested in making that more flexible, and would even put in the effort myself and create pull request. But of course only if this stands a chance of acceptance into the upstream.
The idea would be to follow debug_baud and build a system that allows the exact same customisation. One critical point would be that I think I need a breaking change from _setbaud(baud) to something like _setserial(baud, tx, rx). Otherwise one could be in a weird state of not having defined one or the other. And that added complexity isn't worth it IMHO.
Comments
A P2 flexprop project in most cases is a directory that contains several files. There is no project description file. Instead, there is always the main file you compile, which can (and in most cases do) use another files as objects.
One of the strongest feature in Flexprop is - you can combine all 3 languages (Basic, C, Spin) in one project and it works. I prefer Basic as the main program language, but then I use all kinds of drivers written in Spin and a code written in C
You can #include the file if it is Basic or C and what you #include is in the same language as the file in which the #include is. You can declare objects written in other languages.
This is what it looks like (the beginning of the player code) - the Basic program declaring Spin programs as its objects. The same can be done in C or Spin:
Yes. Instead of telling it where the compiler is and how to call it, you have to write some black magic incantations for every project. Not for me, too.
???? But that's exactly what you do? And setting it up globally instead of per-project would be really, really, really obnoxious and stupid.
Then again, I basically never actually set up any tasks in VSC. I just create a shell script that builds the program and run that from the terminal pane.
What I use for everyday programming is either Flexprop (commands->configure .... and in most cases forget until platform change)....
.... or Lazarus, in both "PC with OS" and Ultibo versions... While Lazarus has a complex project structure a "new project" option sets defaults for your hardware/system/cpu so no black magic required too.
Lazarus has also a code editor with syntax highlighting you can define, so one of my ideas is to adapt it to P2 languages/compilers. No time, as always. I was dragged into a project that I have to do in languages I don't know in a system I don't know. If it wasn't for chatGPT, which I can ask how to do this and how to call that, it would be a disaster. It still can be a disaster.
Flexprop having the commands as a global configuration falls under the same problem - as soon as you need to use a compiler option that changes the program behavior it becomes very "funny" to remember the correct settings for each project.
As said, in my opinion the by far ideal setup is to create a .sh (or .bat if one really wants) that looks maybe a little like this
and then run that through whatever means necessary (just a terminal, setting up an IDE task, whatever).
I then usually invoke the loader as a separate command because I keep switching between boards on different ports.
Yes, that's correct, the model is more like that of Spin where there's a main source file that includes other source files either explicitly (via #include or object references) or indirectly (via __fromfile declarations).
What, precisely, do you mean here by "document tabs"? Flexprop can already open multiple documents in different tabs, if that's what you mean -- every time you open a new file from the File menu a new tab is created, similarly if you click on the hyperlink made out of #include or struct __using.
Ah, I surely qualify as the today's idiot...
That's what I meant, but didn't notice it is already there. Thanks
I usually use a makefile project in Visual Studio (not VS code). Makes things very nice…
I've uploaded a new binary release (6.0.4) which fixes a bug in P1 listing output and an incorrect file name in error messages appearing after a #include of a file whose name exactly matches the end of the current file's name. It's probably worth upgrading to this version even if you haven't run into those bugs. I'm being very conservative with changes in the 6.0.x branch, only bug fixes (and fairly cautious ones at that) should be going in there.
Eric
I think I just found another Optimizer bug. In FSRW there is this methode:
When I call this methode, the optimizer inlines the whole pputs() methode and the strsize() methode is put into FCACHE:
But it does it not fully right, the arg01 also gets the stringsize instead of the original stringpointer (which is damaged by the strsize code).
Andy
@ersmith,
Hi Eric, is there somewhere a source file where I could peek at the serial communication between P2 and the host file-system?
Mike
@Ariba : Are you able to share a bit more of the code, at least the function that calls pputs? I'm not able to reproduce the problem with simple examples, so I suspect it is very context dependent.
@msrobots : The P2 side of the host file system code is in the file
include/filesys/fs9p/fs9p_internal.ccin the flexprop distribution. The PC side is in the loadp2 and proploader sources, inside a directory calledu9fs. The 9p protocol is documented in various places on the web, including at http://9p.cat-v.org/documentation/ and at https://9fans.github.io/plan9port/man/man9/intro.html .Okay here is a heavy stripped down version that shows the error. Near the end of the top file, there is a method 'getstr'. If you comment out the marked line, the optimizer works, otherwise it produces the described error.
Andy
@Ariba Thank you for the more detailed example. I was able to track down the bug -- some registers were being re-used incorrectly when an inlined function was inside another function that was in turn inlined in a third function (in this case stringsize, inside getstr, inside savetext). It's fixed in 6.0.5, the sources for which are up on github now.
@ersmith Are all the floating point functions in math.h implemented somewhere?
I'm not seeing them all in math.c ...
They're in some of the other libsys files, like powers.c etc. The linking of the builtins to there happens through the hardcoded float.spin (found with the other hardcoded stuff in the sys directory of the source tree)
FlexProp 6.0.5 is available now (from the usual places, e.g. see my signature). It has a few minor improvements to error messages, and a fairly big bug fix in the optimizer to address the problem @Ariba found above with inline functions inside inline functions.
Not able to build 6.0.5 from latest flexprop sources on MacOSX with latest OSX SDK... Issue #69 has been posted on github.
dgately
The error is in PropLoader, which hasn't changed in a very long time, so my guess is that no version of flexprop can build with the latest OSX SDK. I'm guessing Apple broke something. It's possible that sprinkling #include at the beginning of all the .cpp files in PropLoader/src might help, at least with the nullptr_t errors, but I can't test this.
FlexProp 6.1.0 is available now in the usual places (see my signature). It has support for multi-file projects, conditional assembly, and the Spin2 FIELD[] and ^@ operations, along with some nice optimizations by @Wuerfel_21 . The full changelog is:
The project files are basically the same as SimpleIDE's .side files, and in many cases FlexProp can compile those (providing the C code doesn't have any GCC specific features, which unfortunately many of the simple libraries do).
Does FlexProp has a feature to download a complete project archive (assume as a .zip file)?
Specifically- The archive must include everything to allow compilation, so I'm thinking that means common libs that are referenced in the code, but perhaps stored outside of the user code/working folder, must also be included in the archive.
The behaviour would resemble what PropellerTool archive function does, so the single zip can be shared to another user, and they can be assured the code will compile because all src references are included, and with the versions the author intended.
Eric added that feature some while ago, but I myself haven't used it. Perhaps just try it out and see if it works as you'd want it to.
Thanks @Wuerfel_21 - That's good to know provisionally. Yeah- I will try it out before signing the bottom line
Yes, it's under the Commands menu (Commands > Create zip archive). Which now that I think about it could be considered an odd place for it, maybe the File menu would be better. But internally creating a zip archive is basically the same as compiling the program or running it (they all use flexspin as back end).
Didn't know about this. Guess this can only work if all the files that would otherwise be on the command line are included in the main file.
Does it really do all the libraries and the executables needed too?
I just tried it and didn't work...
Main file has this: #include "Antares.h"
Get this error:
error: Unable to write file C:\FlexProp\Antares.h to zip
child process exited abnormally
It's looking in wrong place for .h file, it's on D drive, like the main C file...
This is version 5.9.26 though, maybe it's been fixed?
It looks like there's a bug in packaging C header files, due to the different preprocessor used in C. I'll fix that in the next release.
Deleted
I've released FlexProp 6.1.1. The Changelog is:
The bug fixes are significant, so I encourage upgrading to this version.
I got myself used to working with an additional FTDI chip (e.g. the venerable proplug) when working with the Px. The biggest reason for me: I don't need to juggle flashing vs monitoring by terminating by screen command (which I'm usually using). That works nicely with all the handrolled stuff so far, but I want to leverage the stdio-library of flexspin/prop. However there the output pins are hard-wired. I'd be interested in making that more flexible, and would even put in the effort myself and create pull request. But of course only if this stands a chance of acceptance into the upstream.
The idea would be to follow debug_baud and build a system that allows the exact same customisation. One critical point would be that I think I need a breaking change from _setbaud(baud) to something like _setserial(baud, tx, rx). Otherwise one could be in a weird state of not having defined one or the other. And that added complexity isn't worth it IMHO.
How would you feel about that, Eric?
I think I've stumbled across an optimisation bug.
Nope. I was an idiot, nothing to see here...
Not sure in what dimension you live in, but in ours 16777471 is the correct result of 0xff - 0xff000000