Since I'm actually finding issues/exceptions that concern spin2cpp more than spinconveri.tcl, should I just write these up as issues in git on the master branch of spin2cpp? Looks like spin2cpp still does not know to handle the 'abort' expression, yet:
Thanks Dennis. spin2cpp can handle abort in C and C++ code, but it looks like I missed it in the PASM code (d'oh!). I'll look into it -- thanks for catching this.
Development has moved back to the master branch, so opening issues on that branch of spin2cpp would work (no need to open an issue for this one).
I'd like to thank everyone who has tried out the converter on their code and submitted bug reports. These have really helped to improve spinconvert / spin2cpp.
I think the code is now stable enough for real use, and so in the github project I've moved it back to the "master" branch and tagged it with v3.0.0. There are new binary downloads for spincvt.zip (the GUI) and spin2cpp.zip (the command line tools). The GUI version has everything you need to compile Spin to PASM and then binary. If you want to convert to C and then compile that, you'll need a C compiler. PropGCC is probably the best choice there, since spin2cpp is tested with that; Catalina did work to compile spin2cpp output at one point in the not too distant past, and probably still works, but I haven't tested it lately.
I finally had chance to play with this today, very impressive.
I tried compiling some of the library demos with varying results.
The Graphics Demo for example shows the following errors:-
./bin/spin2cpp --noheader -g --asm --code=cog --data=hub -o {C:/Users/Graham/Desktop/GFX Demo/TV.pasm} {C:/Users/Graham/Desktop/GFX Demo/Graphics_Demo.spin} error: Array does not reference memory
error: Array does not reference memory
error: Array does not reference memory
When I tried to compile some other source I noticed it doesn't parse the Reboot command error: Symbol reboot is of a type not handled by PASM output yet
Coley: Thanks for trying this out. Are you sure you're using the most recent version (3.0.0)? The reboot bug was fixed quite recently, which makes me think you may be using the 3.0.0-beta version.
Coley: Thanks for trying this out. Are you sure you're using the most recent version (3.0.0)? The reboot bug was fixed quite recently, which makes me think you may be using the 3.0.0-beta version.
Yes I think it's the beta version, I will DL the latest and re-test. Thanks!
I am doing a kind of different testing here. I am running ubuntu 15.10, I installed WINE so I could see if spinconvert.exe would run. I also installed the latest Propeller IDE.
I did a conversion of led.spin -> pasm and lmm, and then changed the the created led.pasm file to led.spin and ran it in Propeller IDE, I get:
Why not just produce the binary in spinconvert? That's the simplest way, and is guaranteed to work. Does Propeller IDE have an option to just load a .binary file?
openspin (the compiler used by Propeller IDE) doesn't support the @@@ operator, so it won't be able to compile the LMM output even if you do add a PUB. bstc and homespun could though. I don't recall whether they support compiling without a PUB. If not then you'd have to add:
pub main
coginit(0, @LMM_LOOP, 0)
to the program to make it work there. I guess I should have spinconvert output that by default, although that wouldn't help with the @@@ problem. That one needs better documentation.
Thanks for trying it out and reporting your experience,
Eric
Thanks Eric. Propeller IDE only deals with .spin files. I find the LMM aspect a very interesting development, making Spin programs able to run in LMM mode.
The only problem with the LMM effort is that you have a very very limited amount of programs that can work with that. Just making a couple of observations, I do not want to divert or hijack this thread.
How far are you planing to expand spinconvert.exe? Maybe a built in editor, propeller-loader, ..., etc?
Thanks Eric. Propeller IDE only deals with .spin files. I find the LMM aspect a very interesting development, making Spin programs able to run in LMM mode.
Ah, I see -- I haven't used Propeller IDE myself, I tend to stick to the command line. For Linux I would recommend producing a binary with spinconvert, and then using the command line propeller-load tool to run it:
propeller-load foo.binary -r -t
For Windows, the Propeller Tool can load binaries.
How far are you planing to expand spinconvert.exe? Maybe a built in editor, propeller-loader, ..., etc?
I don't know -- there are already a lot of IDEs for the Propeller, I'm not sure I need to add another one. I guess a simple "Run" option to spinconvert might be useful, but where does one draw the line? What do you think?
Another option I had thought of was making an openspin compatible front end (maybe called "fastspin"), which could then be used in PropellerIDE.
I don't know -- there are already a lot of IDEs for the Propeller, I'm not sure I need to add another one. I guess a simple "Run" option to spinconvert might be useful, but where does one draw the line? What do you think?
Eric, you have developed and provided a very good program, now, how do you really use it, in the most efficient manner, for new users, and old users?
The existing IDEs that are available are starting to look like niche programs, none of which are able to work with the new tools that are available, especially the ones that you have created. And the existing IDEs are in a state of sleep, the best word that I can use here without being kicked off the forum.
Since the P2 is not going to be available for quite some time yet, I think the LMM feature makes the use of the P1 that much more compelling. It would be nice if there was a tool, yes, I like the GUI stuff, that you could use your tools in a GUI setting. It seems right now you have to develop the original Spin program in one environment, then you to go to another environment to use your tools, and then you have to find another environment to use the new Spin program. It would be nice to have a minimal amount of steps involved to produce and run that new Spin program. Oh, and it would be nice to be able to take some exiting Object code, from the OBEX, produce a PASM program and then somehow be able to implement that within PropGCC, in a simple manner.
So, yes, another IDE, built around the use of your new tools would be helpful. Since it is your time and effort, you will have to decide what is in your best interests. Thanks again for your tools.
Is using ${insert_your_favourite_editor_here}, a propeller loader and make (or some glue scripts in your favourite scripting language) really too complicated?
Right now, PropWare only supports Spin2cpp's Spin -> C++ and Spin -> dat features. However, if you think it would satisfy your requirements, I would happily add Spin -> binary (which implies Spin -> PASM -> binary too). Since PropWare is built with CMake, you would then have access to IDEs such as Eclipse, Code::Blocks, QtCreator, and CLion.
This is a whole different world in terms of complexity under the hood, so I certainly understand if it's not what you're looking for. But it would be many times easier to implement than another IDE.
Is using ${insert_your_favourite_editor_here}, a propeller loader and make (or some glue scripts in your favourite scripting language) really too complicated?
If you feel comfortable with doing that, then be my guest, and do it that way to your hearts content. If I were a "command line" enthusiast, than I would not be suggesting GUI stuff.
Since PropWare is built with CMake, you would then have access to IDEs such as Eclipse, Code::Blocks, QtCreator, and CLion.
In fact I just downloaded PropWare to my Ubuntu setup, honest opinion, it just does not feel right for me. Not being negative, but that is my first impression. I had a similar impression with Catalina, after the Code::Blocks feature was added, not for me.
In fact, I went so far, the other day, to see how VIM would work out... lets just leave it at that. Just cannot get the right tool in my hands, either you end up with something that is just too much, or something that is just not enough.
In fact I just downloaded PropWare to my Ubuntu setup, honest opinion, it just does not feel right for me. Not being negative, but that is my first impression. I had a similar impression with Catalina, after the Code::Blocks feature was added, not for me.
I certainly don't want to hijack this thread, but I'd love it if you dropped your opinions either in my inbox or on the PropWare thread. I don't have many (vocal) users so every bit of negative feedback is quite appreciated.
In fact, I went so far, the other day, to see how VIM would work out... lets just leave it at that. Just cannot get the right tool in my hands, either you end up with something that is just too much, or something that is just not enough.
I've been using gedit under Linux and it seems to work pretty well. I also use vi for quick edits.
No more IDE's thank you. The world is full of them. Always a pain in the...
Don't get me wrong, there is nothing wrong with an IDE. I like syntax highlighting, linting, auto-completion, push button compile/download, debugging as much as anyone.
But, I believe the tools at the bottom of all this should be independent, stand alone, usable from the command line. Separation of concerns and all that, as software architects like to say.
Meanwhile a GUI IDE should be configurable, or be able to use plugins, to use whatever compilers and loaders etc are appropriate.
Of course that idea leads to monstrosities like Eclipse or on a small scale the mess that is SimpleIDE/PropellerIDE. It takes a lot of resources to keep such an IDE working with everything that comes along.
No more IDE's thank you. The world is full of them. Always a pain in the...
Don't get me wrong, there is nothing wrong with an IDE. I like syntax highlighting, linting, auto-completion, push button compile/download, debugging as much as anyone.
But, I believe the tools at the bottom of all this should be independent, stand alone, usable from the command line. Separation of concerns and all that, as software architects like to say.
Meanwhile a GUI IDE should be configurable, or be able to use plugins, to use whatever compilers and loaders etc are appropriate.
Of course that idea leads to monstrosities like Eclipse or on a small scale the mess that is SimpleIDE/PropellerIDE. It takes a lot of resources to keep such an IDE working with everything that comes along.
Vim is of course great
How is vim not an IDE? It has syntax highlighting, auto-completion, and build system integration. Ever try ":make"? It runs "make" and then brings you the first line with an error or warning. Just type ":cn" or ":cp" to scroll to the next or previous error. It's great for fixing problems after doing major refactoring via macros or /search/replace. There is a plugin that adds gdb integration, but I've never really tried it. There's a vim plugin called easytags that adds better (contextual) syntax highlighting. Gvim, which you probably have already installed if you have vim, has a GUI.
OK. I give up. What is an Integrated Development Environment (IDE) today?
Like many terms in the computing world it seems to have been bent an twisted to mean whatever. Far away from any original understanding of the term.
It used to be that an IDE was everything you needed to develop software integrated into a single program or package. Canonical examples of "IDE" are the old Turbo Pascal, MS Visual Studio, or the Arduino system, or the XMOS system, or MPLAB or .... many others. An IDE included the editor, yes with syntax highlighting, auto-completion etc. It also included the compiler and debugger for whatever language you were using. And in the embedded world the tools required to program your target device. And so on. One never had to leave a running IDE to get the job done.
Given all the above is Vim and IDE?
I say no. I can install Vim and get no compiler/interpreter for any language. Even syntax highlighting is no enabled by default. Vim brings no debuggers or loaders or other tools with it.
Yes, with enough tweaking I can use it as a development environment. I have Vim here with syntax highlighting for Spin for example. With a bit of work I could get it to run OpenSpin and load binaries to a Prop.
Hm... very interesting point Heater. Certainly when I see the acronym "IDE" the first programs that come to my mind are Eclipse, IntelliJ, Code::Blocks, etc.... but I like your definition of IDE quite a bit more and none of those three satisfy your definition.
So I would say, despite what the acronym may stand for, it's colloquial definition is now: a program that has the potential (given enough configuration) to act like a single program or package with everything you need to develop software.
This basically opens up any text editor with an interface to the command line or ability to invoke external commands. Which means the term "IDE" isn't very useful anymore.
What worries me about the sloppy use of such terms is that we end up with people posting here about some problem in Prop Tool when they mean there is something they don't understand about Spin. Or with SimpleIDE when C is the issue.
That confusion between what is the language and what is the editor/IDE makes me cringe every time it comes up.
I can go with your modern definition of "IDE". My Debian Linux install is a full integrated development environment straight out of the box. Great!
Sometimes @Heater, you disagree with yourself in a couple of posts.
First you say:
Meanwhile a GUI IDE should be configurable, or be able to use plugins, to use whatever compilers and loaders etc are appropriate.
Of course that idea leads to monstrosities like Eclipse or on a small scale the mess that is SimpleIDE/PropellerIDE. It takes a lot of resources to keep such an IDE working with everything that comes along.
Then you say:
It used to be that an IDE was everything you needed to develop software integrated into a single program or package. Canonical examples of "IDE" are the old Turbo Pascal, MS Visual Studio, or the Arduino system, or the XMOS system, or MPLAB or .... many others. An IDE included the editor, yes with syntax highlighting, auto-completion etc. It also included the compiler and debugger for whatever language you were using. And in the embedded world the tools required to program your target device. And so on. One never had to leave a running IDE to get the job done.
Exactly what plain English does or SimpleIDE or PropellerIDE or the PropTool, or BST. Having one install and no need leave the IDE. (theoretically)
Then you say:
My Debian Linux install is a full integrated development environment straight out of the box
Now I give up. What exactly do you want. Command line tools, a GUI, fully integrated or configurable, what exactly are you proposing?
To me this sounds all like "wash me but do not get me wet".
As I was programming Mainframes in COBOL and Assembler I sure needed JCL to run jobs and had to configure environment stuff. But there was no IDE as such to use.
As I was programming the TRS80 I also needed a command line. Even them 8-bit Commodores or Atari's needed the command line. But already the 32 bit versions of Commodore and Atari and Acorn did away with that. The IBM PC was a step back.
I am programming in different versions of Visual Studio since VB4 (1994?) and had never the need to call the compiler or debugger on a command line. For what? I am sure you are able to do that, but there is no need for. Normally you do not have to configure anything, just install, write your code, click run and done.
Ok, if you want to use other compilers with VS you might need to do some configuration, but else it is right there, out of the box.
Eclipse is a bit different, since it wants to be a wonder warthog supporting ALL possible languages (theoretically), so you have a lot of configuration to do to get it running.
@ersmith,
In my opinion there is no need for a build in editor or IDE here for the SpinConverter.
I really like the idea to make some 'FastSpin' supporting most of the same switches as OpenSpin does and giving the same listings for easier integration into existing tools already using OpenSpin.
As for having Spin Code larger the 32k in PropTool compiled to LMM: That will need external memory, I think that is a lot of work duplicated. Better to transpile to C/C++ and then use PropGCC with all the existing infrastructure.
But maybe you can use the memory drivers of PropGCC, then things are different.
Back on topic. I installed spin2cpp for linux, and was testing the --binary part. I believe this is supposed to be the way you would get an LMM of a Spin program if you were not using the new GUI program.
./spin2cpp.linux --asm --binary led.spin, does not work, it just comes up with the notice as to the correct way of using spn2cpp.
./spin2cpp.linux --binary led.spin, produces -> led.cpp and led.h, plus "sh: 1: propeller-elf-gcc: not found".
I downloaded the latest spin2cpp version 3 package. Using the command line also grates on my nerves, even after a short time.
Comments
Thanks Dennis. spin2cpp can handle abort in C and C++ code, but it looks like I missed it in the PASM code (d'oh!). I'll look into it -- thanks for catching this.
Development has moved back to the master branch, so opening issues on that branch of spin2cpp would work (no need to open an issue for this one).
Eric
I think the code is now stable enough for real use, and so in the github project I've moved it back to the "master" branch and tagged it with v3.0.0. There are new binary downloads for spincvt.zip (the GUI) and spin2cpp.zip (the command line tools). The GUI version has everything you need to compile Spin to PASM and then binary. If you want to convert to C and then compile that, you'll need a C compiler. PropGCC is probably the best choice there, since spin2cpp is tested with that; Catalina did work to compile spin2cpp output at one point in the not too distant past, and probably still works, but I haven't tested it lately.
Eric
I finally had chance to play with this today, very impressive.
I tried compiling some of the library demos with varying results.
The Graphics Demo for example shows the following errors:-
./bin/spin2cpp --noheader -g --asm --code=cog --data=hub -o {C:/Users/Graham/Desktop/GFX Demo/TV.pasm} {C:/Users/Graham/Desktop/GFX Demo/Graphics_Demo.spin}
error: Array does not reference memory
error: Array does not reference memory
error: Array does not reference memory
When I tried to compile some other source I noticed it doesn't parse the Reboot command
error: Symbol reboot is of a type not handled by PASM output yet
Yes I think it's the beta version, I will DL the latest and re-test. Thanks!
There is no definition, array, etc...
I did a conversion of led.spin -> pasm and lmm, and then changed the the created led.pasm file to led.spin and ran it in Propeller IDE, I get:
Ray
This is the code that spincvt created.
openspin (the compiler used by Propeller IDE) doesn't support the @@@ operator, so it won't be able to compile the LMM output even if you do add a PUB. bstc and homespun could though. I don't recall whether they support compiling without a PUB. If not then you'd have to add: to the program to make it work there. I guess I should have spinconvert output that by default, although that wouldn't help with the @@@ problem. That one needs better documentation.
Thanks for trying it out and reporting your experience,
Eric
Pub xyz
To prevent errors in homespun. Presume others may do likewise.
The only problem with the LMM effort is that you have a very very limited amount of programs that can work with that. Just making a couple of observations, I do not want to divert or hijack this thread.
How far are you planing to expand spinconvert.exe? Maybe a built in editor, propeller-loader, ..., etc?
Ray
I just cloned spin2cpp. It builds and runs on my Debian x86_64 box just fine.
Great job.
Ah, I see -- I haven't used Propeller IDE myself, I tend to stick to the command line. For Linux I would recommend producing a binary with spinconvert, and then using the command line propeller-load tool to run it:
For Windows, the Propeller Tool can load binaries.
I don't know -- there are already a lot of IDEs for the Propeller, I'm not sure I need to add another one. I guess a simple "Run" option to spinconvert might be useful, but where does one draw the line? What do you think?
Another option I had thought of was making an openspin compatible front end (maybe called "fastspin"), which could then be used in PropellerIDE.
Thanks,
Eric
That's its "native" environment (I use Debian x86_64 as my primary development system), so I'm not too surprised
Thanks for the kind words,
Eric
The existing IDEs that are available are starting to look like niche programs, none of which are able to work with the new tools that are available, especially the ones that you have created. And the existing IDEs are in a state of sleep, the best word that I can use here without being kicked off the forum.
Since the P2 is not going to be available for quite some time yet, I think the LMM feature makes the use of the P1 that much more compelling. It would be nice if there was a tool, yes, I like the GUI stuff, that you could use your tools in a GUI setting. It seems right now you have to develop the original Spin program in one environment, then you to go to another environment to use your tools, and then you have to find another environment to use the new Spin program. It would be nice to have a minimal amount of steps involved to produce and run that new Spin program. Oh, and it would be nice to be able to take some exiting Object code, from the OBEX, produce a PASM program and then somehow be able to implement that within PropGCC, in a simple manner.
So, yes, another IDE, built around the use of your new tools would be helpful. Since it is your time and effort, you will have to decide what is in your best interests. Thanks again for your tools.
Ray
Is using ${insert_your_favourite_editor_here}, a propeller loader and make (or some glue scripts in your favourite scripting language) really too complicated?
Right now, PropWare only supports Spin2cpp's Spin -> C++ and Spin -> dat features. However, if you think it would satisfy your requirements, I would happily add Spin -> binary (which implies Spin -> PASM -> binary too). Since PropWare is built with CMake, you would then have access to IDEs such as Eclipse, Code::Blocks, QtCreator, and CLion.
This is a whole different world in terms of complexity under the hood, so I certainly understand if it's not what you're looking for. But it would be many times easier to implement than another IDE.
In fact I just downloaded PropWare to my Ubuntu setup, honest opinion, it just does not feel right for me. Not being negative, but that is my first impression. I had a similar impression with Catalina, after the Code::Blocks feature was added, not for me.
In fact, I went so far, the other day, to see how VIM would work out... lets just leave it at that. Just cannot get the right tool in my hands, either you end up with something that is just too much, or something that is just not enough.
Ray
I certainly don't want to hijack this thread, but I'd love it if you dropped your opinions either in my inbox or on the PropWare thread. I don't have many (vocal) users so every bit of negative feedback is quite appreciated.
Don't get me wrong, there is nothing wrong with an IDE. I like syntax highlighting, linting, auto-completion, push button compile/download, debugging as much as anyone.
But, I believe the tools at the bottom of all this should be independent, stand alone, usable from the command line. Separation of concerns and all that, as software architects like to say.
Meanwhile a GUI IDE should be configurable, or be able to use plugins, to use whatever compilers and loaders etc are appropriate.
Of course that idea leads to monstrosities like Eclipse or on a small scale the mess that is SimpleIDE/PropellerIDE. It takes a lot of resources to keep such an IDE working with everything that comes along.
Vim is of course great
How is vim not an IDE? It has syntax highlighting, auto-completion, and build system integration. Ever try ":make"? It runs "make" and then brings you the first line with an error or warning. Just type ":cn" or ":cp" to scroll to the next or previous error. It's great for fixing problems after doing major refactoring via macros or /search/replace. There is a plugin that adds gdb integration, but I've never really tried it. There's a vim plugin called easytags that adds better (contextual) syntax highlighting. Gvim, which you probably have already installed if you have vim, has a GUI.
Ray
Like many terms in the computing world it seems to have been bent an twisted to mean whatever. Far away from any original understanding of the term.
It used to be that an IDE was everything you needed to develop software integrated into a single program or package. Canonical examples of "IDE" are the old Turbo Pascal, MS Visual Studio, or the Arduino system, or the XMOS system, or MPLAB or .... many others. An IDE included the editor, yes with syntax highlighting, auto-completion etc. It also included the compiler and debugger for whatever language you were using. And in the embedded world the tools required to program your target device. And so on. One never had to leave a running IDE to get the job done.
Given all the above is Vim and IDE?
I say no. I can install Vim and get no compiler/interpreter for any language. Even syntax highlighting is no enabled by default. Vim brings no debuggers or loaders or other tools with it.
Yes, with enough tweaking I can use it as a development environment. I have Vim here with syntax highlighting for Spin for example. With a bit of work I could get it to run OpenSpin and load binaries to a Prop.
Certainly not "integrated".
So I would say, despite what the acronym may stand for, it's colloquial definition is now: a program that has the potential (given enough configuration) to act like a single program or package with everything you need to develop software.
This basically opens up any text editor with an interface to the command line or ability to invoke external commands. Which means the term "IDE" isn't very useful anymore.
That confusion between what is the language and what is the editor/IDE makes me cringe every time it comes up.
I can go with your modern definition of "IDE". My Debian Linux install is a full integrated development environment straight out of the box. Great!
"IDE", "OS", "DB", it's all the same....
I was thinking that as I typed my previous response
First you say:
Then you say:
Exactly what plain English does or SimpleIDE or PropellerIDE or the PropTool, or BST. Having one install and no need leave the IDE. (theoretically)
Then you say:
Now I give up. What exactly do you want. Command line tools, a GUI, fully integrated or configurable, what exactly are you proposing?
To me this sounds all like "wash me but do not get me wet".
As I was programming Mainframes in COBOL and Assembler I sure needed JCL to run jobs and had to configure environment stuff. But there was no IDE as such to use.
As I was programming the TRS80 I also needed a command line. Even them 8-bit Commodores or Atari's needed the command line. But already the 32 bit versions of Commodore and Atari and Acorn did away with that. The IBM PC was a step back.
I am programming in different versions of Visual Studio since VB4 (1994?) and had never the need to call the compiler or debugger on a command line. For what? I am sure you are able to do that, but there is no need for. Normally you do not have to configure anything, just install, write your code, click run and done.
Ok, if you want to use other compilers with VS you might need to do some configuration, but else it is right there, out of the box.
Eclipse is a bit different, since it wants to be a wonder warthog supporting ALL possible languages (theoretically), so you have a lot of configuration to do to get it running.
@ersmith,
In my opinion there is no need for a build in editor or IDE here for the SpinConverter.
I really like the idea to make some 'FastSpin' supporting most of the same switches as OpenSpin does and giving the same listings for easier integration into existing tools already using OpenSpin.
As for having Spin Code larger the 32k in PropTool compiled to LMM: That will need external memory, I think that is a lot of work duplicated. Better to transpile to C/C++ and then use PropGCC with all the existing infrastructure.
But maybe you can use the memory drivers of PropGCC, then things are different.
Anyways, great work.
Enjoy!
Mike
./spin2cpp.linux --asm --binary led.spin, does not work, it just comes up with the notice as to the correct way of using spn2cpp.
./spin2cpp.linux --binary led.spin, produces -> led.cpp and led.h, plus "sh: 1: propeller-elf-gcc: not found".
I downloaded the latest spin2cpp version 3 package. Using the command line also grates on my nerves, even after a short time.
Ray