OpenSpin Compiler fault [closed]
frida
Posts: 155
Hello compiler guru!
There is something wrong with floating point in the compiler in Propeller Ide version 0.34.4.
In Propeller Tool and Propeller Ide version 0.25.1 works.
See pic01, pic02 and pic03.
The binary file in the Propeller Tool and Propeller Ide version 0.25.1 has same size: 4448 bytes.
In Propeller Ide version 0.34.4 is the binary only 4432 bytes.
Pic04 and pic 05 shows open spin versions.
Zip file attached.
There is something wrong with floating point in the compiler in Propeller Ide version 0.34.4.
In Propeller Tool and Propeller Ide version 0.25.1 works.
See pic01, pic02 and pic03.
The binary file in the Propeller Tool and Propeller Ide version 0.25.1 has same size: 4448 bytes.
In Propeller Ide version 0.34.4 is the binary only 4432 bytes.
Pic04 and pic 05 shows open spin versions.
Zip file attached.
Comments
I can only speak for the official version that is in Parallax's github, and that version does not have this problem. It produces an exact binary match with what PropTool outputs for this test program.
Also, Frida, I compiled your test code with the binaries that you yourself included in your archive and they produced the same results.
openspin 25.1
openspin 34.4
I'm not sure what you experienced, but it's not a compiler regression.
For anyone who wonders why PropellerIDE does not use the "official" OpenSpin repository, it is because I have been repeatedly denied attempts to add qmake project files to the repository, and given the choice between creating a separate adapter project containing just project files and just forking the thing, I chose the latter in the hopes that maybe someday someone would finally accept my pull request.
Well, it's been a year and I'm still waiting.
Surely PropellerIDE, as an IDE, should be using OpenSpin as an independent, external program that it runs. In the same way qtcreator runs gcc. Or pretty much the way all IDEs work except the PropTool.
It's not clear to me why PropellerIDE needs to include OpenSpin code or build it. What am I missing here?
I'm of the same opinion, personally. CMake actually has a dedicated function to handle this "externalproject_add". You give it a url and some command lines to execute and it will do exactly that. So I use that to build spin2cpp via PropWare, even though spin2cpp is gmake and PropWare is cmake
Adding a qmake project file does not introduce a Qt dependency any more than a Visual Studio project file introduces a dependency on Visual Studio, which, by the way, there is in the OpenSpin repository. I've worked with plenty frameworks that provide multiple ways of building a project. I don't see what is so awful or astonishing about making it convenient to build OpenSpin in a Qt environment.
Saying qmake calls gcc is like saying an operating system installer calls cp. Sure, it does, but it also performs a phenomenal amount of magic in the background to ensure that what you get is precisely targeted for whatever platform, architecture, build system, operating system, or toolchain you need.
PropellerIDE is a cross-platform IDE, and as such, it is a requirement that it is highly available, all the time, on whatever platforms are officially supported. I can't afford to sit around and wait for someone else to produce binaries for every conceivable platform I need. I don't have that kind of time, and it makes little sense when I've already built an infrastructure that does it cleanly, automatically, and predictably.
Any other approach, and I never would have gotten as far as I have on this project. So that's why I build OpenSpin myself, and that's why I build it with Qt; because I'd like to finish this project someday.
That's a bit of a gray area. Qt is a big project - it's not just the runtime libraries. I would also consider QMake part of Qt. So then it's a question of, are you proposing the existing build system get removed, or just add in another build system? I assume the latter, because removing the existing one is a bold move.
Anyway, short of implementing something like CMake's externalproject_add, I think you did exactly the right thing. That's what forking projects was made for. PropellerIDE is not an editor. In fact, it's not even "just" an IDE. It is a complete environment, build tools and all. And OpenSpin is one of those build tools, so it should therefore be shipped with PropellerIDE.
On the other hand, as that is the case, it's no hardship for you to fork the project, add the file, and then just pull updates from the original as time goes by.
But like Heater says, I'm not sure why you need any of that at all, you should just call openspin as an external process. Even Visual Studio does that with it's cl.exe compiler. I don't see why you need to build your own version of openspin with your own version of openspin.cpp and the addition of main.cpp (which seems to be bits of openspin.cpp moved into another file). This is going to become an even bigger issue in the near future when I completely restructure the openspin wrapper code around the compiler lib. You'll need to redo your alternate version of the code.
Also, you are behind a few versions in the compiler code.
The OpenSpin source and makefiles as they exist in the parallaxinc github will build just fine for the platforms you need. There is no need to involve Qt/QtCreator.
David Zemon's TeamCity service already builds Linux, Windows and R-Pi binaries for OpenSpin moments after I submit changes. If someone would hook in a Mac/OSX machine to there we could have those as well. Perhaps we need to talk to Ken And Jeff at Parallax about doing that?
You could then use those built version of OpenSpin for your PropellerIDE releases, and not need to do any of this other stuff with Qt wrappers and whatever.
Brett uses an automated build system. To that end, he needs it to have the reliable ability of automatically including and building all resources for every supported platform the moment he pushes his updates and says "go." Having to wait for any external resource to build resource x for platform y is a no-go time-wasting frustration. And what if he decides he needs to temporarily regress to a previous release of any external resource? Perhaps one that never had all the platform builds performed? I understand this. This is one of the reasons (along with the Qt mix) we preferred that he maintain the necessary items to do so via his own fork.
However, if there's overall compelling reasons to include a second build script in OpenSpin that makes this smoother for that external project (auto-builds, staying up-to-date, etc.), doesn't interfere with the existing build script / process in any way, and such an alternate build script is clearly labeled and actively maintained by the one who needs it most, I think we should seriously consider merging it via future pull requests. As long as there are no other changes in said pull requests, it has little effect on the original OpenSpin project and can be ignored by all projects and developers that don't need it.
As far as remember OpenSpin comes as C/C++ source code and a make file. As such it has been very easy to build for Debian on the PC and Raspberry Pi, for OpenWRT and using Emscripten.
An automated build tool ought to be able to do the same "git clone" and "make" steps that I have done manually many times.
As far as I can tell OpenSpin is written in the most platform neutral and simple way.
There is no "wait for any external resource to build resource x for platform y", just build it.
What am I missing in this picture?
Via this StackOverflow answer:
Shouldn't take all too many lines to make it happen.
qmake projects are extremely predictable in what they look like, which has made it fantastically easy to support pretty much any Qt application with my deployment tool, packthing. Packthing exists because deploying to new environments is a massive pain and packthing allows me to magically create builds for whatever packthing supports by adding only a short config file.
https://github.com/lamestation/packthing
The same absolutely can NOT be said of a plain ol' makefile. You can't reasonably infer what the output of a makefile might be, where the target ends up, what various settings there are, how it is impacted by the environment, because that's all left up to the developer. All of it. Every new foray into someone's makefile is yet another problem that has to be solved, and has to be solved over and over again to make sure not just your code, but all of the third-party code behaves the way you expect it to. That's a nightmare that I don't have time for.
I'm sure OpenSpin has been built for all kinds of platforms, but I can sleep easier at night knowing that if I can build it with one Qt installation, I can build it for any of these regularly tested platforms without changing a single line of code and know that what it spits out will already work with packthing without having to change anything there either.
For those concerned about the tweaks that I've made to my OpenSpin distribution, about the question of responsibility and whose going to manage the qmake project files, I am the one who maintains them, and who has been maintaining them, full-time, for over a year. I am the one who has to look after every single component that goes into the application and make sure that the open-box experience is as good as it possibly can be, and OpenSpin is right at the forefront of that. So naturally, it's driven me absolutely bonkers that whenever I've had a problem with it, I've had no path to getting it fixed in the mainline.
I have a test suite that I've set up that runs every time I check in any changes to my OpenSpin, on every platform. It's my version that gets distributed with PropellerIDE so it sees lots of usage in the field. Whenever people have complaints about OpenSpin, I'm one of the first to hear about them. But I don't want to have a version. I would love nothing more than to set up the resources that I have for the mainline Spin distribution so that every single version of OpenSpin in the wild would benefit from them, but to date, none of my changes have ever made it in.
As a final point, the goal for PropellerIDE is to provide both an embedded and a command-line version of the Spin compiler, so in the long term, it's absolutely not going to be as simple as calling an arbitrary makefile anyway.
I don't think anyone has an issue with adding a single project file to the repo.
Problem comes when changes are required to other files to support that build system/platform.
qmake is not going to work when I build with for MIPS based embedded machines or with Emscripten. That would be OK but if Qt dependencies creep into the rest of the source code that is going to make a mess.
I still don't see the need to have OpenSpin embedded in the IDE. We already have the stand alone command line tool.
Ohhh boy do I understand where brett is coming from with this. I'm astonished with how many users are having/have had trouble getting up and running with PropWare because CMake, Make, and PropGCC aren't packaged together. The need comes from users wanting everything ready to go in a single package, installable with a single click.
Make used to be packaged with PropGCC. I remember I was relying on that and was very saddened the day I found out it disappeared. I just double checked the contents of PropGCC coming out of my build server and make.exe is not there.
A proper installer would definitely help. Something that automatically modifies PATH. And perhaps Parallax taking over a (my?) TeamCity server to automatically build these things. Not only does PropGCC not provide an installer, but there is no "official" distribution outside of SimpleIDE! This still boggles my mind
No one else has to use the qmake project file, and it doesn't require any changes to the compiler code. The changes Roy mentioned previously are customizations that I made to my distribution that don't impact anyone else.
This is for distribution of PropellerIDE on mobile platforms and eventually Chrome. It also allows compilation and loading entirely in RAM and without saving, which is one of my favorite features of PropTool
And that!