Spin / BASIC to C / C++ / PASM converter version 3.9.10 released this 15 days ago · 13 commits to master since this release
Changes in this release:
Added a peephole optimizer to replace "mov x, #0 ; add x, y" with "mov x, y"
Added sqrt() operator to BASIC
Fixed a problem with passing (some) floating point parameters to functions
Fixed another REP bug in the P2 optimizer
Fixed cognew/coginit return value when no free cog is available
Fixed another CSE bug
Fixed a floating point display bug (E notation was off by one)
#ifdef/#endif around #include was broken, fixed now
Many improvements to the C frontend
I have seen the code generated by spin2cpp and it's ugly. The code may work but it's not C code I have been use to seeing. In most cases it doesn't generate very efficient code.
I have seen the code generated by spin2cpp and it's ugly. The code may work but it's not C code I have been use to seeing. In most cases it doesn't generate very efficient code.
Mike
The generated code then gets compiled by PropGCC which should generate more efficient code than the Parallax Spin compiler which doesn't do any optimization at all.
Just my two bits, but why not use an editor like netbeans or visual studio or eclipse? One person in one man month could write a plugin, or just a gdb compatible exe, and perhaps a custom formatter for spin perhaps.
I prefer to write my own bad C code and compile it. It seems everyone is on the Spin band wagon which is not for me.
Mike
Certainly, if you know and like C you should write it directly rather than writing Spin and translating it to C. The spin2cpp translator was written to allow Spin programmers to compile their Spin programs into something more efficient than the Parallax Spin interpreter can manage.
I have one question. If parallax or forum members decide to choose gcc, is there any plan to develop with the goal of having the code submitted upstream? I mean, is there any plan to made it easy for gcc developpers to merge that version into the official GCC source code? I think it should be desirable to do it in this way (with the purpose of being a official port of GCC), if not please explain why.
I am rather curious to see what comes out of the tools planning meeting mentioned by Ken. If Parallax does choose to target gcc I would certainly hope they intend to get it merged into the upstream in the long run.
The microcontroller families I am targeting with this library are AVR and ARM, both of which are officially supported by GCC. Releases of the GCC AVR toolchain (at least through Debian Stretch and Arduino) use GCC 4.9, so to be able to use C++17 features with AVRs I am compiling the latest version of GCC (currently 8.2) and the rest of the toolchain from source which is quite painless. I haven't started active development for ARM yet, but I imagine I will be building from source for it as well.
The portable portions of the library have automated unit tests (at least most of them do at the moment) written using googletest/googlemock which are compiled for native execution (Debian Stretch in my case).
Currently I only have two real gripes when developing:
1) avr-libc's complete lack of C++ standard library headers. This library will only ever make use of the facilities provided in the freestanding C++ implementation headers (minus exception) so I have been writing these headers for the AVR as needed.
2) The version of GCC currently available in Debian Stretch is GCC 6.3 which only partially supports C++17 language features. To address this I just need to get around to using a parallel installation of GCC that is built from the latest source.
Where the Propeller 1/2 come into this:
I have a fair amount of Propeller 1 hardware laying around which I haven't really used over the last 2 years. I would love to add Propeller 1 support (and Propeller 2 when C++ tools are available for it) to this library to at the very least see how well the hardware abstractions work on a microcontroller with a non-traditional architecture (and I'd get some use out of the hardware I've got again). However, doing so at the moment would require me to either:
a) Set the language feature bar to what is available in the Propeller toolchain's GCC 4.6.1 (incomplete C++11 support)
b) Look back into using the GCC 6 work that I was referred to when I asked about GCC maintenance and further development almost 2 years ago
In either case I would effectively be restricting the library to using what is available in that version of GCC for the foreseeable future (and would not be able to take advantage of what is coming in C++20 and beyond) due to the Propeller work not being part of upstream GCC. This is not something I am willing to do, so for now all the Propeller 1 hardware I have will continue to collect dust. Depending on the path Parallax decides to take when this tools meeting happens it may simply be time for me to sell the Propeller hardware I have and wish Parallax the best of luck in their efforts.
Depending on the path Parallax decides to take when this tools meeting happens it may simply be time for me to sell the Propeller hardware I have and wish Parallax the best of luck in their efforts.
I'd really like to bring a board using P2 to my group of S-100 board friends, but this is where I'm at as well. If there is not a clear path on tools, I'll do the board with a Teensy 3.5 from PJRC instead.
PropTool is the original closed source Windows application Parallax released for programming the P1 in Spin/PASM using Chip's x86 ASM compiler code. It's the tool many here know and love. OpenSpin is an open source C++ port of Chip's x86 ASM compiler code. It has some added features like a preprocessor, unused method elimination, longer symbol names, able to handle more symbols, and is usually a fair bit faster at compiling. PropellerIDE is meant to be a cross platform replacement for PropTool. If uses BSTC or OpenSpin to compile Spin/PASM. propgcc is a fork of gcc made to target P1. This produces PASM or LMM/CMM/XMM/etc. (which is PASM like). SimpleIDE is mainly used for compiling C/C++ using propgcc. Although it can also be configure to compile Spin/PASM using OpenSpin (I believe).
All of the above tools are existing P1 stuff that has been developed over the years by many different people. There are a bunch more.
Then we get to stuff for P2: pnut is Chip's simple editor that wraps his x86 compiler/assembler for P2. It's the first thing we had for P2 coding. fastspin is a tool that compiles Spin to PASM/LMM for P1 or straight PASM2 (which can be in cog/lut/hub memory) for P2, it also has BASIC and C (partial?) support now too. p2asm is an assembler for P2. I don't know much about it sorry. p2gcc is a set of stuff that takes the output of propgcc and retargets it to the P2 (basically). From what I can tell it's not complete, but it's fairly functional.
Based on what Ken has said, I don't think they plan to make any official IDE/editors going forward. So, it sounds like PropTool won't be updated for P2. I think the intention is to get command line compilers done for what they need and leverage existing IDE/editors.
For Spin/PASM on P2, chips x86 ASM will be the "source of truth" for defining what Spin/PASM for P2 is. I plan to port over that x86 code into a new version of OpenSpin (note, a lot of it is the same as before so I only need to port over changes and additions). This could then be used with existing IDEs that work with OpenSpin with minimal effort (mainly just updating them for P2 keywords for syntax highlighting).
For C/C++, I think it would be best to get propgcc updated to target P2. This could then be used with SimpleIDE and any other editor/IDEs that can work with gcc like tools (most of them).
For MicroPython/Python, we can build them with propgcc, and just make whatever changes are need for P2.
fastspin, and any other existing tools will continue to exist and be used/support by whoever wants to do so.
The microcontroller families I am targeting with this library are AVR and ARM, both of which are officially supported by GCC. Releases of the GCC AVR toolchain (at least through Debian Stretch and Arduino) use GCC 4.9, so to be able to use C++17 features with AVRs I am compiling the latest version of GCC (currently 8.2) and the rest of the toolchain from source which is quite painless.
Sounds like you are ahead of the pack there.
You say AVR releases are 4.9, did you find any issues when compiling with 8.2 ? I think you mean this works ok ?
However, doing so at the moment would require me to either:
a) Set the language feature bar to what is available in the Propeller toolchain's GCC 4.6.1 (incomplete C++11 support)
Agreed, not ideal, but I notice you mention AVR is quite similar in being release 4.9 limited ?
Interesting, I see no mention of specific issues there - how did your tests go back then ?
If AVR moves from 4.9 to 8.2 ok in your environment, (which is what I think you are saying) maybe P1 can do the same ?
Did you try the merge ?
A list of problems would help quantify the things needing fixing.
Thank you. My concern was what languages I had to learn to program the P2. I will download fastspin once it comes out of beta.
I was concerned that I would be forced to learn C++ and Python. :frown:
The microcontroller families I am targeting with this library are AVR and ARM, both of which are officially supported by GCC. Releases of the GCC AVR toolchain (at least through Debian Stretch and Arduino) use GCC 4.9, so to be able to use C++17 features with AVRs I am compiling the latest version of GCC (currently 8.2) and the rest of the toolchain from source which is quite painless.
Sounds like you are ahead of the pack there.
You say AVR releases are 4.9, did you find any issues when compiling with 8.2 ? I think you mean this works ok ?
However, doing so at the moment would require me to either:
a) Set the language feature bar to what is available in the Propeller toolchain's GCC 4.6.1 (incomplete C++11 support)
Agreed, not ideal, but I notice you mention AVR is quite similar in being release 4.9 limited ?
When distributed as binaries (such as in Debian Stretch's package repositories, or Arduino IDE), the provided version of avr-gcc/avr-g++ is typically 4.9. avr-gcc/avr-g++ is in no way release 4.9 limited since cross compiling for the AVR is officially supported by GCC and thus any version of GCC, including 8.2 which was the most recent release, can be built as a cross compiler for the AVR. I had no issues building GCC version 8.2 (or 8.1) as a cross compiler for the AVR, and have had no issues with the resulting cross compiler.
Interesting, I see no mention of specific issues there - how did your tests go back then ?
If AVR moves from 4.9 to 8.2 ok in your environment, (which is what I think you are saying) maybe P1 can do the same ?
Did you try the merge ?
A list of problems would help quantify the things needing fixing.
I only did some trivial testing at that time and never went back to it for a variety of reasons.
Cross compiling for the AVR is officially supported by GCC which is why I was able to easily just switch to using 8.2, and will be able to easily switch to using any future releases when they occur. I am not familiar with the with the internal state of the Propeller GCC efforts so I am not able to make an informed comment on what would be involved to get things working with GCC 8.2, but I suspect it is not trivial.
I did not try submitting the Propeller GCC work to the upstream, but would be willing to support getting things into a state where such a submission could be made if Parallax leads/supports a serious effort to make it actually happen. Working on GCC Propeller support is a complete waste of time from the perspective of my wants/needs if there isn't going to be a serious effort to get it officially supported by GCC, but if Parallax's needs are met by supporting/stagnating the port themselves that is their decision to make.
It would certainly be good to upstream the Propeller GCC changes. We looked into that at one point and that is one reason Eric did some work to move us to a more recent version of GCC. Unfortunately, we never got enough use of the newer version of PropGCC to justify upstreaming it. It's largely untested and is not in use for any official Parallax products. In any case, I agree that it should be a goal.
For those interested in helping out with a potential GCC port to P2, here is an interesting link that might help you understand the current P1 GCC backend:
The PropGCC backend files are located in propgcc/gcc/gcc/config/propeller. The most interesting file is propeller.md which is the Propeller (P1) machine description.
For those interested in helping out with a potential GCC port to P2, here is an interesting link that might help you understand the current P1 GCC backend:
The PropGCC backend files are located in propgcc/gcc/gcc/config/propeller. The most interesting file is propeller.md which is the Propeller (P1) machine description.
That's a great blog! Thank you! I feel a lot less intimidated now
Probably Eric's would be the best place to start. It uses a more recent release of GCC. However, it's P1 compiler was never adopted by Parallax. It would be nice if both P1 and P2 used the same GCC code base so it would be nice to figure out how to get Parallax to adopt the newer P1 compiler.
Supposedly there is some incompatibility with the simple library. It seems like it's just a matter of finding the incompatibility and fixing the simple library.
So should we create yet another repository based on Eric's code, or can we work in Eric's repository?
I don't know if we can work directly with Eric's repository. I'm hoping he'll comment here about how he thinks we should move forward.
BTW, I looked over propeller.md in the Parallax propgcc repository and there doesn't seem to be any P2-specific code in their. It looks like our previous port was done when there weren't that many differences between P1 and P2 so the gcc backend just generated the same code for both. I think the main changes were in binutils.
I'm wondering if we might be able to use p2pasm as an assembler for P1 as well as P2. A lot of the ugly work involved with porting gcc is in the gas code in binutils. If we could avoid that we might be able to make faster progress. This requires p2pasm to generate ELF files though and I think the DWARF symbol table format is kind of complicated.
The parallaxinc repository does contain a propeller2.h file in the lib/include directory, and some of the library files use the __PROPELLER2__ flag. However, it seems like Eric's repository has a bit more P2 stuff in it than parallaxinc. We need guidance from Eric on this.
I've looked at the ELF and DWARF formats, and it is very complicated. However, my hope is that the assembler only uses a small subset of this. I've started writing a utility that converts p2asm's format to the ELF format, but I haven't gotten very far on it. I think it's doable within a finite amount of time and effort.
The parallaxinc repository does contain a propeller2.h file in the lib/include directory, and some of the library files use the __PROPELLER2__ flag. However, it seems like Eric's repository has a bit more P2 stuff in it than parallaxinc. We need guidance from Eric on this.
I've looked at the ELF and DWARF formats, and it is very complicated. However, my hope is that the assembler only uses a small subset of this. I've started writing a utility that converts p2asm's format to the ELF format, but I haven't gotten very far on it. I think it's doable within a finite amount of time and effort.
I think most of the symbol table stuff is generated by the compiler and just needs to be passed through by the assembler.
The library definitely has a bunch of stuff for P2 but it doesn't appear that the compiler does.
Why the heck do we need Proptool, Openspin, Fastspin, SimpleIDE, PropellerIDE, etc?
This is NOT a weakness. But a strength.
The more things people put up on github means the more CODE you can rip off for your own uses.
THIS is theeeeeee most important factor, availability of ANY material.
Sure much of it ends up dead, but the history is there and that is pure gold.
NEVER underestimate the value of dead projects, you can just cut its arm off and sew it to your NEW monster.
Such is the life of CS. Thats the future of CS, anything and everything goes.
Haven't you noticed?
The companies that control their chips and platforms tightly so they don't have "fragmentation" end up stealing their customers money just so they can have the mpeg decoder module.
ADDON GALORE that you must pay subscription fees to have, and THEY EXPIRE.
We CAN sort thru it all, if we can manage to install windows10 and get it working, or linux, .... i think we can deal with a bit of too much CHOICE.
Forget that, keep the FREE opensource tools comin guys...
Make a million, and let 999,999 of them rot, only used for code examples and ripoffs...
I used to use proptool, then I got into simpleIDE. And even though its a MONSTER, its free, and all the tools I need to develop with it are free.
I would have liked to have proptool open source, but because its not, i don't really want it, i can't modify it, or even learn from it.
If its a tool that isn't open, i kinda don't even want it.
Since simpleIDE is available, works, has totally open code, and the dev environment is free, I am now LAUNCHED into learning how it works, and the c code (or is it c++?) .
Its a bit like diving off a cliff for the first time, totally over my head and im thinking what could i possibly accomplish here.
But then thats why we have our beds and pillows, and a button that says OFF.
Do I care that it uses gcc4 or whatever else thats old...
NO, because what good is the new stuff if it has no examples, but the old stuff has a million.
I can get up to speed on the old stuff, while you guys are working on the new stuff.
And after years of me working with the old stuff.. i'll be ready to move into and possibly help with newer tools.
TAKE NOTE, parallax still sells the Basic Stamp.
Hold old is that chip?
I really wonder, are their ANY companies still making and supporting their first generation chip?
(does intel still sell the 4004?) This company is .... different.
The parallaxinc repository does contain a propeller2.h file in the lib/include directory, and some of the library files use the __PROPELLER2__ flag. However, it seems like Eric's repository has a bit more P2 stuff in it than parallaxinc. We need guidance from Eric on this.
Any P2 stuff in my repo is extremely old and probably not useful (except perhaps as a guide to where to put the "real" P2 code). P2 has changed so much over the years...
I don't know what the best way forward is for P2 support for GCC. GCC has moved on a lot since the last time I tried to build it, so perhaps the best approach is for someone to do a clean copy of a recent GCC repository and start adding in the Propeller specific code to get a P1 version. Then once that's working to move to P2.
Alternatively we could use an old version of GCC (like one of the ones that already supports P1) and just add P2 support to it. But the older GCC seems to have build issues on new versions of Linux, so that may not be very viable. GCC is a constantly moving target and it's a bit of a pain to keep up with it.
This is confusing. How did PropGCC get in such a mess? I suggest that we start with whatever is currently being used. The current code that is being used is under the parallaxinc GitHub account, right?
This is confusing. How did PropGCC get in such a mess? I suggest that we start with whatever is currently being used. The current code that is being used is under the parallaxinc GitHub account, right?
It's not really in a mess. The repository in the Parallax GitHub account has the version that Parallax uses in SimpleIDE. That version is in a branch called something like release_1_0. The default branch of the repository has the version that Parallax asked us to create that has a number of improvements and a new model for XMM drivers. Unfortunately, they never had time to integrate it into SimpleIDE. It was ready to go as far as we were concerned. It just needed testing with the Simple Libraries which is something Parallax had to do. They didn't have time. I suspect you know by now that they don't have a large staff and supporting their educational efforts takes most if not all of their resources.
Eric's repository was his attempt to move to a newer release of GCC and binutils. It works but hasn't been exercised a lot and, like the default branch of the Parallax repository, it hasn't been tested with the Simple Libraries.
I guess what we need to figure out is how to help Parallax integrate new versions of the tools into their SimpleIDE and BlocklyProp releases so that we don't get stuck with an ancient set of tools. It seems like we could get together some volunteer testers. Maybe people could even volunteer to write regression tests so some of the testing of a new release could be automated. This doesn't require compiler gurus. Anyone should be able to help.
I guess what we need to figure out is how to help Parallax integrate new versions of the tools into their SimpleIDE and BlocklyProp releases so that we don't get stuck with an ancient set of tools. It seems like we could get together some volunteer testers. Maybe people could even volunteer to write regression tests so some of the testing of a new release could be automated. This doesn't require compiler gurus. Anyone should be able to help.
Hopefully others will join me in saying "YES! I'll help write automated regression test suites!" and then we'll get all this running on a (my?) CI server.
I brought this up a while ago with exactly the same sentiment as you. The mess with PropGCC happened because Parallax never had the confidence they needed to proceed with a new release of PropGCC. They couldn't get confident with it themselves because they didn't have the time (money). Volunteers didn't because... no I'm not going there. I don't want to put words in anyone else's mouth. And the automated tests built into PropGCC (GCC comes with some, right?) don't do much to ensure the Simple libraries still work as intended. And there are no automated tests for the Simple libraries, let alone a standalone build system to build the Simple libraries.
The solution is that round 2 needs to have automated testing as a TOP priority to ensure changes can get continuously integrated into released products. I'd love to help out with some of the fun programming, like hardware abstraction libraries and whatnot, but if getting the tooling and documentation set up to quickly write, build, and run test suites is what this community needs most, I'll happily do it.
As C/C++ compiler status proceeds it will be paramount that remember the following: Parallax don't have the time to check each release for bugs. If we don't get specific requirements from them defining what they need in order to feel confident with a new version of the compiler and then act on those requirements to satisfy them ourselves without any help from Parallax, new features will never be released by Parallax. And we all know, products not officially endorsed by Parallax have a staggeringly difficult time gaining traction.
This is confusing. How did PropGCC get in such a mess? I suggest that we start with whatever is currently being used. The current code that is being used is under the parallaxinc GitHub account, right?
This is a loaded question I love it. "the current code that is being used"... used by whom? For what? My CI server is actually building David Betz's repository here: https://github.com/dbetz/propeller-gcc
Maybe I should change that to someone elses? Maybe I should add someone elses? Oh that'd be fun wouldn't it, having two (or more) different PropGCC repositories on my CI server, each with two upstream versions of GCC and for each version of GCC a Windows/Linux/Raspberry Pi build.
Actually, my repository is really just a container for other stuff. It includes Eric's GCC repository, Eric's binutils reposotory, Eric's library repository, Parallax's OpenSpin repository, etc. The only pieces that are in my own GitHub account are the gcc portion of the old Parallax GCC repository and propeller-load. To be honest, I don't know why I have my own copy of propeller-load. I should probably just get that from the Parallax account as well. And I should just remove the old propgcc/gcc repository and just go with Eric's new GCC repository. In any case, my propeller-gcc project is really just a Makefile to build a bunch of other stuff that is included as submodules.
Comments
Out of those efforts, one will gain traction. Maybe a couple. Center of gravity.
Can't tell people what to do, unless we are paying them. And that's OK. Human nature.
So, what to do?
Attract them. That can be done. And there is your center of gravity in action.
Want more efforts on one tool? Attract them. Use the tool, build mass, others will gravitate toward it, and it all builds nicely.
If you mean do you need to learn anything more ?
The best single-tool to learn would be fastspin compiler for P2
That has P2 ASM, Spin and also a Basic and C compilers, and already looks usable...
See also
https://github.com/totalspectrum/spin2cpp/releases
Spin / BASIC to C / C++ / PASM converter version 3.9.10 released this 15 days ago · 13 commits to master since this release
Changes in this release:
Added a peephole optimizer to replace "mov x, #0 ; add x, y" with "mov x, y"
Added sqrt() operator to BASIC
Fixed a problem with passing (some) floating point parameters to functions
Fixed another REP bug in the P2 optimizer
Fixed cognew/coginit return value when no free cog is available
Fixed another CSE bug
Fixed a floating point display bug (E notation was off by one)
#ifdef/#endif around #include was broken, fixed now
Many improvements to the C frontend
and
https://github.com/totalspectrum/spin2cpp/compare/v3.9.10...master
This multiple language approach I think will have wide appeal.
Mike
Mike
I am rather curious to see what comes out of the tools planning meeting mentioned by Ken. If Parallax does choose to target gcc I would certainly hope they intend to get it merged into the upstream in the long run.
My perspective:
My main hobby software project is a microcontroller hardware abstraction and peripheral IC driver library written in C++ (currently C++17). This library is still in the early stages of development.
The microcontroller families I am targeting with this library are AVR and ARM, both of which are officially supported by GCC. Releases of the GCC AVR toolchain (at least through Debian Stretch and Arduino) use GCC 4.9, so to be able to use C++17 features with AVRs I am compiling the latest version of GCC (currently 8.2) and the rest of the toolchain from source which is quite painless. I haven't started active development for ARM yet, but I imagine I will be building from source for it as well.
The portable portions of the library have automated unit tests (at least most of them do at the moment) written using googletest/googlemock which are compiled for native execution (Debian Stretch in my case).
Currently I only have two real gripes when developing:
1) avr-libc's complete lack of C++ standard library headers. This library will only ever make use of the facilities provided in the freestanding C++ implementation headers (minus exception) so I have been writing these headers for the AVR as needed.
2) The version of GCC currently available in Debian Stretch is GCC 6.3 which only partially supports C++17 language features. To address this I just need to get around to using a parallel installation of GCC that is built from the latest source.
Where the Propeller 1/2 come into this:
I have a fair amount of Propeller 1 hardware laying around which I haven't really used over the last 2 years. I would love to add Propeller 1 support (and Propeller 2 when C++ tools are available for it) to this library to at the very least see how well the hardware abstractions work on a microcontroller with a non-traditional architecture (and I'd get some use out of the hardware I've got again). However, doing so at the moment would require me to either:
a) Set the language feature bar to what is available in the Propeller toolchain's GCC 4.6.1 (incomplete C++11 support)
b) Look back into using the GCC 6 work that I was referred to when I asked about GCC maintenance and further development almost 2 years ago
In either case I would effectively be restricting the library to using what is available in that version of GCC for the foreseeable future (and would not be able to take advantage of what is coming in C++20 and beyond) due to the Propeller work not being part of upstream GCC. This is not something I am willing to do, so for now all the Propeller 1 hardware I have will continue to collect dust. Depending on the path Parallax decides to take when this tools meeting happens it may simply be time for me to sell the Propeller hardware I have and wish Parallax the best of luck in their efforts.
I'd really like to bring a board using P2 to my group of S-100 board friends, but this is where I'm at as well. If there is not a clear path on tools, I'll do the board with a Teensy 3.5 from PJRC instead.
PropTool is the original closed source Windows application Parallax released for programming the P1 in Spin/PASM using Chip's x86 ASM compiler code. It's the tool many here know and love.
OpenSpin is an open source C++ port of Chip's x86 ASM compiler code. It has some added features like a preprocessor, unused method elimination, longer symbol names, able to handle more symbols, and is usually a fair bit faster at compiling.
PropellerIDE is meant to be a cross platform replacement for PropTool. If uses BSTC or OpenSpin to compile Spin/PASM.
propgcc is a fork of gcc made to target P1. This produces PASM or LMM/CMM/XMM/etc. (which is PASM like).
SimpleIDE is mainly used for compiling C/C++ using propgcc. Although it can also be configure to compile Spin/PASM using OpenSpin (I believe).
All of the above tools are existing P1 stuff that has been developed over the years by many different people. There are a bunch more.
Then we get to stuff for P2:
pnut is Chip's simple editor that wraps his x86 compiler/assembler for P2. It's the first thing we had for P2 coding.
fastspin is a tool that compiles Spin to PASM/LMM for P1 or straight PASM2 (which can be in cog/lut/hub memory) for P2, it also has BASIC and C (partial?) support now too.
p2asm is an assembler for P2. I don't know much about it sorry.
p2gcc is a set of stuff that takes the output of propgcc and retargets it to the P2 (basically). From what I can tell it's not complete, but it's fairly functional.
Based on what Ken has said, I don't think they plan to make any official IDE/editors going forward. So, it sounds like PropTool won't be updated for P2. I think the intention is to get command line compilers done for what they need and leverage existing IDE/editors.
For Spin/PASM on P2, chips x86 ASM will be the "source of truth" for defining what Spin/PASM for P2 is. I plan to port over that x86 code into a new version of OpenSpin (note, a lot of it is the same as before so I only need to port over changes and additions). This could then be used with existing IDEs that work with OpenSpin with minimal effort (mainly just updating them for P2 keywords for syntax highlighting).
For C/C++, I think it would be best to get propgcc updated to target P2. This could then be used with SimpleIDE and any other editor/IDEs that can work with gcc like tools (most of them).
For MicroPython/Python, we can build them with propgcc, and just make whatever changes are need for P2.
fastspin, and any other existing tools will continue to exist and be used/support by whoever wants to do so.
Sounds like a good idea.
Sounds like you are ahead of the pack there.
You say AVR releases are 4.9, did you find any issues when compiling with 8.2 ? I think you mean this works ok ?
Agreed, not ideal, but I notice you mention AVR is quite similar in being release 4.9 limited ?
Interesting, I see no mention of specific issues there - how did your tests go back then ?
If AVR moves from 4.9 to 8.2 ok in your environment, (which is what I think you are saying) maybe P1 can do the same ?
Did you try the merge ?
A list of problems would help quantify the things needing fixing.
Thank you. My concern was what languages I had to learn to program the P2. I will download fastspin once it comes out of beta.
I was concerned that I would be forced to learn C++ and Python. :frown:
When distributed as binaries (such as in Debian Stretch's package repositories, or Arduino IDE), the provided version of avr-gcc/avr-g++ is typically 4.9. avr-gcc/avr-g++ is in no way release 4.9 limited since cross compiling for the AVR is officially supported by GCC and thus any version of GCC, including 8.2 which was the most recent release, can be built as a cross compiler for the AVR. I had no issues building GCC version 8.2 (or 8.1) as a cross compiler for the AVR, and have had no issues with the resulting cross compiler.
I only did some trivial testing at that time and never went back to it for a variety of reasons.
Cross compiling for the AVR is officially supported by GCC which is why I was able to easily just switch to using 8.2, and will be able to easily switch to using any future releases when they occur. I am not familiar with the with the internal state of the Propeller GCC efforts so I am not able to make an informed comment on what would be involved to get things working with GCC 8.2, but I suspect it is not trivial.
I did not try submitting the Propeller GCC work to the upstream, but would be willing to support getting things into a state where such a submission could be made if Parallax leads/supports a serious effort to make it actually happen. Working on GCC Propeller support is a complete waste of time from the perspective of my wants/needs if there isn't going to be a serious effort to get it officially supported by GCC, but if Parallax's needs are met by supporting/stagnating the port themselves that is their decision to make.
https://kristerw.blogspot.com/2017/08/writing-gcc-backend_4.html
The PropGCC backend files are located in propgcc/gcc/gcc/config/propeller. The most interesting file is propeller.md which is the Propeller (P1) machine description.
That's a great blog! Thank you! I feel a lot less intimidated now
So should we create yet another repository based on Eric's code, or can we work in Eric's repository?
BTW, I looked over propeller.md in the Parallax propgcc repository and there doesn't seem to be any P2-specific code in their. It looks like our previous port was done when there weren't that many differences between P1 and P2 so the gcc backend just generated the same code for both. I think the main changes were in binutils.
I've looked at the ELF and DWARF formats, and it is very complicated. However, my hope is that the assembler only uses a small subset of this. I've started writing a utility that converts p2asm's format to the ELF format, but I haven't gotten very far on it. I think it's doable within a finite amount of time and effort.
The library definitely has a bunch of stuff for P2 but it doesn't appear that the compiler does.
This is NOT a weakness. But a strength.
The more things people put up on github means the more CODE you can rip off for your own uses.
THIS is theeeeeee most important factor, availability of ANY material.
Sure much of it ends up dead, but the history is there and that is pure gold.
NEVER underestimate the value of dead projects, you can just cut its arm off and sew it to your NEW monster.
Such is the life of CS. Thats the future of CS, anything and everything goes.
Haven't you noticed?
The companies that control their chips and platforms tightly so they don't have "fragmentation" end up stealing their customers money just so they can have the mpeg decoder module.
ADDON GALORE that you must pay subscription fees to have, and THEY EXPIRE.
We CAN sort thru it all, if we can manage to install windows10 and get it working, or linux, .... i think we can deal with a bit of too much CHOICE.
Forget that, keep the FREE opensource tools comin guys...
Make a million, and let 999,999 of them rot, only used for code examples and ripoffs...
I used to use proptool, then I got into simpleIDE. And even though its a MONSTER, its free, and all the tools I need to develop with it are free.
I would have liked to have proptool open source, but because its not, i don't really want it, i can't modify it, or even learn from it.
If its a tool that isn't open, i kinda don't even want it.
Since simpleIDE is available, works, has totally open code, and the dev environment is free, I am now LAUNCHED into learning how it works, and the c code (or is it c++?) .
Its a bit like diving off a cliff for the first time, totally over my head and im thinking what could i possibly accomplish here.
But then thats why we have our beds and pillows, and a button that says OFF.
Do I care that it uses gcc4 or whatever else thats old...
NO, because what good is the new stuff if it has no examples, but the old stuff has a million.
I can get up to speed on the old stuff, while you guys are working on the new stuff.
And after years of me working with the old stuff.. i'll be ready to move into and possibly help with newer tools.
TAKE NOTE, parallax still sells the Basic Stamp.
Hold old is that chip?
I really wonder, are their ANY companies still making and supporting their first generation chip?
(does intel still sell the 4004?) This company is .... different.
Any P2 stuff in my repo is extremely old and probably not useful (except perhaps as a guide to where to put the "real" P2 code). P2 has changed so much over the years...
I don't know what the best way forward is for P2 support for GCC. GCC has moved on a lot since the last time I tried to build it, so perhaps the best approach is for someone to do a clean copy of a recent GCC repository and start adding in the Propeller specific code to get a P1 version. Then once that's working to move to P2.
Alternatively we could use an old version of GCC (like one of the ones that already supports P1) and just add P2 support to it. But the older GCC seems to have build issues on new versions of Linux, so that may not be very viable. GCC is a constantly moving target and it's a bit of a pain to keep up with it.
Eric's repository was his attempt to move to a newer release of GCC and binutils. It works but hasn't been exercised a lot and, like the default branch of the Parallax repository, it hasn't been tested with the Simple Libraries.
I guess what we need to figure out is how to help Parallax integrate new versions of the tools into their SimpleIDE and BlocklyProp releases so that we don't get stuck with an ancient set of tools. It seems like we could get together some volunteer testers. Maybe people could even volunteer to write regression tests so some of the testing of a new release could be automated. This doesn't require compiler gurus. Anyone should be able to help.
Hopefully others will join me in saying "YES! I'll help write automated regression test suites!" and then we'll get all this running on a (my?) CI server.
I brought this up a while ago with exactly the same sentiment as you. The mess with PropGCC happened because Parallax never had the confidence they needed to proceed with a new release of PropGCC. They couldn't get confident with it themselves because they didn't have the time (money). Volunteers didn't because... no I'm not going there. I don't want to put words in anyone else's mouth. And the automated tests built into PropGCC (GCC comes with some, right?) don't do much to ensure the Simple libraries still work as intended. And there are no automated tests for the Simple libraries, let alone a standalone build system to build the Simple libraries.
The solution is that round 2 needs to have automated testing as a TOP priority to ensure changes can get continuously integrated into released products. I'd love to help out with some of the fun programming, like hardware abstraction libraries and whatnot, but if getting the tooling and documentation set up to quickly write, build, and run test suites is what this community needs most, I'll happily do it.
As C/C++ compiler status proceeds it will be paramount that remember the following: Parallax don't have the time to check each release for bugs. If we don't get specific requirements from them defining what they need in order to feel confident with a new version of the compiler and then act on those requirements to satisfy them ourselves without any help from Parallax, new features will never be released by Parallax. And we all know, products not officially endorsed by Parallax have a staggeringly difficult time gaining traction.
This is a loaded question
Maybe I should change that to someone elses? Maybe I should add someone elses? Oh that'd be fun wouldn't it, having two (or more) different PropGCC repositories on my CI server, each with two upstream versions of GCC and for each version of GCC a Windows/Linux/Raspberry Pi build.