Migrating from Propeller Tool to PropellerIDE or SimpleIDE
jac_goudsmit
Posts: 418
For my "L-Star" hardware project, I have several software projects developed in PASM with Spin, and I'm planning on writing some future projects in PASM with C/C++. There are some time-critical parts (I'm bitbanging a 6502 bus) so PASM is important.
I developed all existing projects in Propeller Tool under Windows but I want to make the source code usable for developers who may be using other operating systems, and I want to eventually move away from Spin because it poses an extra hurdle to get customers on board. So here are a couple of questions:
I've worked with SimpleIDE and PropellerIDE. They both seem to be in a pretty stable state at this time. Am I correct that SimpleIDE is intended more for casual developers (e.g. students), and PropellerIDE is geared more towards the professional developer? What's the future of both tools?
The most important difference as far as I can tell between SimpleIDE and PropellerIDE is that SimpleIDE uses .side project files which remember what the top file of the project is (and some other properties), whereas PropellerIDE expects you to activate the top file in the editor before you use Build or Run or Download. Is this correct? Any other important differences?
I read somewhere that SimpleIDE can't do Spin but I understand it has BSTC and/or OpenSpin too now, is that correct?
Is there a good reason to use BSTC vs. OpenSpin? How much development is happening on both and how stable is each of them?
When I tried to compile my projects with PropellerIDE (and SimpleIDE as well, I think), I had an issue that I had given one of my spin modules the same name as a library file, and BSTC as well as OpenSpin found the library file before they found my spin file. Easy to work around of course (just rename the file) but a possible future issue because, since library file names have priority, if a new library file is added that happens to have the same file as someone's file in some project, that project will be silently broken. I filed an issue on the OpenSpin github but haven't heard anything. Is anyone listening there?
Another important issue is that someone apparently thought it was a good idea to rename all the library files so my project that refers to "synth.spin" doesn't build unless I change the reference to "signal.synth.spin" or copy the library from Propeller Tool to the SimpleIDE or PropellerIDE library directory or add the path to the Propeller Tool library to the Preferences. Are there supposed to be symlinks to the old names (which Windows doesn't understand) or something? I would like to keep my spin files compatible with Propeller Tool as well as SimpleIDE/PropellerIDE if possible, and the renamed libraries are currently a show stopper for that.
For future GCC/gas projects: What's the compatibility status of the assemblers built into Propeller Tool, BSTC, OpenSpin and "gas"? I remember a few years ago you had to jump through some hoops (compiling the DAT sections of spin modules separately into separate binaries, or something) to combine assembly with C/C++, and the "gas" assembler had some subtle but severe issues with pointer arithmetic (I posted those issues in this forum myself). Has all that been resolved? Is it possible now to basically paste PASM code into a .s file (with common directives such as .include and .public) and build it with gas and link it against C/C++ modules without any rewriting of PASM code? Are SimpleIDE and/or PropellerIDE capable of handling projects with mixed sources? Or does it require writing a Makefile (and a whole lot of MinGW or Cygwin tinkering on Windows)?
Thanks!
===Jac
I developed all existing projects in Propeller Tool under Windows but I want to make the source code usable for developers who may be using other operating systems, and I want to eventually move away from Spin because it poses an extra hurdle to get customers on board. So here are a couple of questions:
I've worked with SimpleIDE and PropellerIDE. They both seem to be in a pretty stable state at this time. Am I correct that SimpleIDE is intended more for casual developers (e.g. students), and PropellerIDE is geared more towards the professional developer? What's the future of both tools?
The most important difference as far as I can tell between SimpleIDE and PropellerIDE is that SimpleIDE uses .side project files which remember what the top file of the project is (and some other properties), whereas PropellerIDE expects you to activate the top file in the editor before you use Build or Run or Download. Is this correct? Any other important differences?
I read somewhere that SimpleIDE can't do Spin but I understand it has BSTC and/or OpenSpin too now, is that correct?
Is there a good reason to use BSTC vs. OpenSpin? How much development is happening on both and how stable is each of them?
When I tried to compile my projects with PropellerIDE (and SimpleIDE as well, I think), I had an issue that I had given one of my spin modules the same name as a library file, and BSTC as well as OpenSpin found the library file before they found my spin file. Easy to work around of course (just rename the file) but a possible future issue because, since library file names have priority, if a new library file is added that happens to have the same file as someone's file in some project, that project will be silently broken. I filed an issue on the OpenSpin github but haven't heard anything. Is anyone listening there?
Another important issue is that someone apparently thought it was a good idea to rename all the library files so my project that refers to "synth.spin" doesn't build unless I change the reference to "signal.synth.spin" or copy the library from Propeller Tool to the SimpleIDE or PropellerIDE library directory or add the path to the Propeller Tool library to the Preferences. Are there supposed to be symlinks to the old names (which Windows doesn't understand) or something? I would like to keep my spin files compatible with Propeller Tool as well as SimpleIDE/PropellerIDE if possible, and the renamed libraries are currently a show stopper for that.
For future GCC/gas projects: What's the compatibility status of the assemblers built into Propeller Tool, BSTC, OpenSpin and "gas"? I remember a few years ago you had to jump through some hoops (compiling the DAT sections of spin modules separately into separate binaries, or something) to combine assembly with C/C++, and the "gas" assembler had some subtle but severe issues with pointer arithmetic (I posted those issues in this forum myself). Has all that been resolved? Is it possible now to basically paste PASM code into a .s file (with common directives such as .include and .public) and build it with gas and link it against C/C++ modules without any rewriting of PASM code? Are SimpleIDE and/or PropellerIDE capable of handling projects with mixed sources? Or does it require writing a Makefile (and a whole lot of MinGW or Cygwin tinkering on Windows)?
Thanks!
===Jac
Comments
While bst and homespun are robust, neither are supported. OpenSpin is supposedly robust and the only thing that it doesn't do is @@@. It does conditional compiles. Roy looks after OpenSpin.
Hope this helps.
Probably have some more changes in the near future.
...and there is Homespun: https://forums.parallax.com/discussion/106401/homespun-spin-compiler-0-31-now-open-source/p1 ...so that's half of good news about @@@ in an open sourced Spin compiler.
https://github.com/ZiCog/HomeSpun
Works a treat on Linux. I have never tried building it on a Windows machine.
OpenSpin works fine as well. Assuming you don't need @@@ or whatever features the Propeller Tool does not have.
I pretty much gave up following SimpleIDE and PropellerIDE ages ago. They were so neglected and in disarray.
Perhaps that has changed recently.
===Jac
Then you find you need @@@.
As far as features go, OpenSpin pretty much does everything the others do aside from @@@.
The unused method/object elimination is more aggressive than BSTCs in most cases.
@@@ = absolute byte address in HUB. The issue is that it has to work in context. As in, as part of of an expression. Since you don't know the final location of a label in hub memory until after everything is compiled and linked together into the final binary, you then need to go back and fix up already compiled code with new data. That could possibly change the end result compiled size, which could move the address of the thing in hub memory.
The way Chip's compiler does things is not a typical parser/compiler setup. It's parsing and compiling as it goes. The passes aren't even clearly separate, since the 1st pass ends up being done twice for every file that includes other files (OBJs). It's all very different from how BSTC or Homespun or any of the others do it.
My questions?
===Jac
SimpleIDE is for students, PropellerIDE is for pros? SimpleIDE is for C/C++, PropellerIDE is for Spin and PBasic. Whether or not SimpleIDE can do Spin is rather irrelevant I think - it was never intended to be an IDE/editor for Spin-focused projects and therefore isn't very good at it. Pick the right tool for the job, and SimpleIDE isn't the right tool for a Spin-focused project. You might then follow this up with "so C/C++ is for students and Spin is for pros?" at which point I would vehemently say "NO" and point you to any number of language war threads that already exist on this forum, and someone else would undoubtedly reply with why C/C++ is a terrible fit and you should stick with Spin, and of course Peter would quickly follow up saying we're all dumb for not just using Tachyon. And he'd probably be right.
What's the future of SimpleIDE/PropellerIDE? I don't think either is "dead" in the sense that they have no users and fail to run on moderns systems... but certainliy neither has seen any updates in quite a while. PropellerIDE was forked from SimpleIDE and (after the fork) written almost entirely by another forum member named Brett. Though I believe Parallax contracted him for some of the work, much of it was volunteer and he's since had to find other, full-time work. Long story short, no one here is aware of any plans to make any changes to PropellerIDE for the foreseeable future. If Parallax has any such plans, they haven't announced them. No forum member has stepped up to take Brett's place, except for one person who has been making a few tweaks. Time will tell whether or not he continues his improvements and accepts the responsibility of maintainer or prefers keep his footprint small. SimpleIDE... oh there's a story there too. Parallax seems to be far more vested in that due to their push in the education market and the fact that they are pushing C, not Spin, in education. That being said, we've seen only the most minimal in changes in SimpleIDE for the last few years. The key author, jazzed, did all the work under contract (I think??? i've never actually talked to him about that so i could be totally off base there), so the fact that we haven't seen any changes means Parallax cut off the money supply. We won't see any further work until Parallax deems it worthy/necessary. And just like PropellerIDE, I don't think there has been any public mention of future plans.
What's up with renamed libraries in PropellerIDE? I think that was Brett trying to refactor the libraries for better organization. It is indeed a breaking change, but I personally like the result a lot more. I hope you do too, after some adjustment period.
Compatibility of PASM/BSTC/OpenSpin? PASM issues in gas? gas is only available from PropGCC, none of the Spin compilers. On the other hand, (new versions of) PropGCC know how to compile PASM as well as gas. On the other hand, PropGCC uses a different binary output format. Basically... either write your code in Spin and pick any number of the Spin compilers (Parallax Propeller Tool, openspin, homespun, bstc, who knows what else) or write your code in C/C++ with PropGCC. There are ways to mix Spin and C/C++ too, but I don't think that's what you're asking about here. Ignore PASM from a requirements standpoint - both the spin compilers and PropGCC will build your assembly code just fine.
IF you're on Linux and IF you like the command line and IF you like PropGCC, then we should chat about PropWare - I happen to think it's just dandy for that niche case.
1. SimpleIDE is for C more than anything, and PropellerIDE is for Spin and PropBasic. At least those are my understanding of the target usages.
2. I think active development on both of them is on hold or stopped.
3. PropellerIDE is meant to be an alternative to PropTool, it's differences are mainly additional features. I don't really know specifics since I do not use it.
4. No one is working on BSTC and it's closed source, no one is actively working on Homespun that I know of either. I will continue to support OpenSpin until the Prop dies or I die (whichever comes first).
5. I had not seen your issue submitted at the OpenSpin github, sorry about that. It doesn't seem to be emailing me notifications again.
I replied over there, but your bug is not an OpenSpin one, it's a PropellerIDE one. OpenSpin does already search the current path for files before going to look in the passed in paths (the lib path is passed in).
6. I believe the "renamed" libraries in PropellerIDE are stuff to go with Lamestation? That was Brett's motivation for making/working on PropellerIDE. Again, I don't use it so I don't know the details.
7. OpenSpin, BSTC and the other spin compilers should all be the same for Spin and PASM source code. Only the "gas" variant is different syntax, etc. for PASM. I'm also no aware of any cross language support being in any of the compilers. If you want to use PASM stuff with propgcc then you have to do the same stuff you've always had to do over there. OpenSpin and BSTC do have a compile option for making a binary file of the DAT stuff, which can then be used with propgcc somehow.
Forgot about it to mention in my previous reply.
from bottom up...
Compatibility of PASM/BSTC/OpenSpin? PASM issues in gas? Answer: YES - except @@@ and gas. The syntax and usage of GAS is different and direct copy of PASM is not there. Thus the trick using binary blobs.
PropellerIde is made by Brent for his own Game-Development System and he renamed the Libraries to fit his purpose. This is not a Parallax Product. It does Spin/Pasm, but not C/C++.
SimpleIde is made by @Jazzed with some support from Parallax and mainly made for C development. Spin support was added later as well as support for Basic. This is somehow a Parallax Product, but mainly for C and Blockly.
I never had that Library issue, I mainly use the PropTool and there the current directory is searched first, then the library folder. Should be the same for openSpin, worked for me fine.
BST is also not a Parallax Project, as far as I remember Brad stopped working on it because of no support/interest from Parallax to work on it. Consider it dead.
Same goes for Homespun, no further development as far as I know. Consider it dead.
PropellerIDE is made by Brent, now back at a fulltime job. He will/may do some more but no timeframe. Consider it as not dead yet, but on hold.
SimpleIDE is under developmet at Parallax, mainly used for Blockly and will be supported, but development somehow stopped while waiting for the P2.
OpenSpin is made by Roy but for Parallax, this is somehow a Parallax Product and actively supported by Roy. It will also grow into the P2 Spin compiler as Roy stated.
SimpleIDE is mainly for C (thus the project files) PropellerIDE is opensource and both run on Windows Linux and some macs.
PropTool is Windows only and has not been changed for a while now.
My personal feeling here is that @Ken is busy getting Blockly into the education market to finance @Chips P2, all Parallax developer are working on Blockly and everything else like PropGCC, SimpleIDE, new PropTool or whatever else are on hold until the P2 is done and in production.
Then there will be a furious action to get the Software tools done to have something when the chips finally arrive.
Enjoy!
Mike
===Jac
It is the only C++ way to handle the p1 I heard of, and @DavidZemon does a really great job doing so. He also runs a build-server providing actual binaries for propGCC and more.
He is a great and dedicated guy, pushing along for a couple of years now. He has probably the most current sources for most of the tools needed to use C/C++ on a propeller in his builds.
Enjoy
Mike
I've cobbled together a working macOS version of PropellerIDE that removes bstc support (since it does not run on macOS) and adds PropBasic->OpenSpin compilation, to get around the dependency on bstc for compiling PropBasic. It's just a juggling around with the sources, that I have not tested on Win or Linux systems. It also does not support @@@ and is only a partial solution.
There are other forum folks that have also made some interesting changes to the PropellerIDE sources. Perhaps we should open up an experimental/development branch of PropellerIDE on GitHub with these changes and have forum folks test on the variety of systems? This, only on Parallax's approval!
dgately
Works great and gets the job done.
I am able to build libraries and functions with no issues. I find most of the time Assembly code is not necessary as the C code generates the same code and works just fine.
Look at hacking the parallax badge in c code which is all in C code.
Mike
Thanks!
I haven't looked at the C/C++ compilers for a while. But I remember a few years ago, the C compiler wasn't smart enough to generate assembly code that would work for me. The biggest problem was that the generated code would "juggle" values between "registers" unnecessarily because the compiler is based on the assumption that registers are more efficient than memory, whereas on the Propeller registers ARE memory.
So if you would want to do something like a bitwise OR operation on the OUTA register, it would copy the value from OUTA to one of the pseudo-registers, perform the operation and then copy the pseudo-register back to OUTA. (I'm doing this from memory so this may not be a valid or true example but you get the gist. The more complicated the expression, the more juggling it would do). My code bitbangs a 6502 at 1MHz; that gives me only 20 non-hub PASM instructions per 6502 clock cycle to do the work. Even a single unnecessary instruction generated by the C compiler might make the code not meet its timing requirements.
I was hoping to read a comment saying "Oh, <insert name> is working on GCC/gas and made a lot of improvements <so many months> ago, it should all work now!" so I'm a bit disappointed but not terribly surprised about the answers. It's good that some developers such as Roy are still seriously maintaining things and it's a shame (but understandable) that minor problems aren't getting fixed because of internal priorities at Parallax.
Anyway, eventually I want to try and explain how things in my project work by using C. And I'll use either SimpleIDE or PropWare (I haven't had a chance to try that yet) to do that. It'll just run slower than the Assembly code. I think my target audience would be willing to read the Assembly source code and they would understand it if they already know what the corresponding C code looks like. But I don't want to ask readers to take a jump from "This is how it works in C" to "This is how it works in assembler and oh by the way you have to convert the higher level stuff from C to Spin to make the PASM parts work". That would just be silly.
So I'll probably have to deal with whatever incompatibilities are left in gas. Or now that it's in Github, I might fork GCC/binutils/gas to make it work the way I think it's supposed to. Maybe I can even convince some people that my ideas in that old thread were not so bad after all. At this time, I'm not yet angry enough at the mess to attack it :-)
===Jac
Here's an example of what "modern" PropGCC will do when combined with (good) C++:
My C++ example for blinking a GPIO (docs on this example here: https://david.zemon.name/PropWare/api-develop/Blinky_Demo_8cpp-example.xhtml)
#include <PropWare/PropWare.h> #include <PropWare/gpio/pin.h> using PropWare::Pin; using PropWare::Port; int main () { const Pin led1(Port::P17, Pin::Dir::OUT); led1.start_hardware_pwm(4); // This is in Hertz const Pin led2(Port::P16, Pin::Dir::OUT); while (1) { led2.toggle(); waitcnt(CLKFREQ / 4 + CNT); } }And the generated assembly file:
That's exactly what I mean with "too much juggling".
Your constructor code for the Pin class probably just has something similar to "DIRA |= 1 << pinnum;"
In assembler, I would just write this as:
That is a 4x speed up, and saves 3 longs. Or a 5x speed up if you count the extra instruction that the compiler generates because it somehow thinks it's a good idea to get ahead of itself.
And actually it's worse than that because you're compiling in LMM mode.
I have great respect and admiration for the engineers that made gcc work for the Propeller. But there is a lot of room for improvement.
===Jac
When PropGCC was first implemented we had the COG and LMM models. The hub memory issue became a major problem, so the XMM and XMMC models were added. Finally, the CMM model was added, which uses about the same amount of memory as Spin, and typically runs slightly faster.
The P2 should be a joy to program in C or C++. With 512K of hub RAM we won't have to struggle so much with running out of memory.
void set_dir (const PropWare::Port::Dir direction) const { DIRA = (DIRA & ~(this->m_mask)) | (this->m_mask & static_cast<uint32_t>(direction)); }This code is used for both ports (multi pin, not consecutive) and individual pins.
You'll notice the part where performance matters - the toggle - is nice and fast.
Absolutely. And in those scenarios, PropWare::Pin::set_direction would not be appropriate. But of course there are many ways to solve that problem with PropGCC as the build tool of choice
What's not to like here.
Mike
Yup. In most of my code, DIRA gets updated between 1 million and 2 million times per second (once or twice per 6502 clock cycle). Every extra instruction counts.
For example, check out https://github.com/jacgoudsmit/L-Star/tree/master/Software/SimpleIDE/Demo3 which is a complete emulator for the Apple 1. It runs as fast as it can, and it does the trick of demonstrating and explaining how the Propeller bitbangs the 6502. But I can only make it run at 1 MHz if I use assembler for the low level stuff. That's okay, because most of my audience is probably not going to be interested in that kind of detail anyway; they can just use a library or object file that contains the assembly code, or I can use inline assembly. But there is still a large amount of value in having an IDE that handles the tediousness of compiling and linking various modules together.
===Jac
Thanks! I'm working on documentation this weekend.
===Jac
C may be faster than Spin but Assembler is even faster. As I already mentioned, some of my code has to do its job in loops that take 1 microsecond. That usually comes down to about 15 or 16 regular instructions, plus one or two waitpxx instructions, plus one hub instruction. That leaves me no playing room to let the C compiler insert instructions like it does in that code fragment above. Therefore I said: C is great but could be greater, and for at least some parts of my software it's simply not good enough.
===Jac