Interactive Spin to Pasm or C converter

Comments

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.

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?

@ 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:

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.

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!

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.

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

I am just another Code Monkey.
A determined coder can write COBOL programs in any language. -- Author unknown.
Press any key to continue, any other key to quit

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.

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.