spin2cpp next generation

ersmith · 2014-09-01 12:31

I'm slowly working on spin2cpp 2.0. Spin2cpp is a tool to convert Spin code to C++ (or C) code. The 2.0 release will provide much better translation (the output C++ code will be more "natural" and readable) and will work better with more compilers. I'm not there yet, but there's a "preview" release 1.91 available now at:

https://github.com/totalspectrum/spin2cpp/releases/tag/v1.91

The main change is that comments are now copied from the Spin code to the C++ code, but there are also lots of other smaller bug fixes and output tweaks.

Note that since Google Code no longer allows binary downloads, I'm moving development of spin2cpp over there. The main web page for spin2cpp will henceforth be:

https://github.com/totalspectrum/spin2cpp

Please let me know of any problems you find with this release!

Thanks,
Eric

Rayman · 2014-09-01 16:32

Thanks Eric. Spin2Cpp is a great tool and I'm glad you're still working on perfecting it.
It's great that you can start out with Spin code when developing assembly routines and then run Spin2Cpp on it and have C++ code that you can give to people for further development.

SRLM · 2014-09-01 18:21

It's been a while since I've had a need for spin2cpp, but working off my memory the main feature that I would like to see would be better PASM handling. First, I'd prefer if it kept all PASM as PASM and not a binary blob. Second, there are some Spin programs that "inject" values into the PASM before launch. It would be nice if the C++ code did something similar but with the GAS PASM.

Like I said, it's been a while so maybe these aren't issues anymore. And I agree with Rayman: spin2cpp is a great tool.

jazzed · 2014-09-01 19:40

Rayman wrote: »

... then run Spin2Cpp on it and have C++ code that you can give to people for further development.

I hate to bring it up, but it seems to me at least that this is the wrong use of the tool.

Don't get me wrong. I applaud Eric's efforts, but the usage model needs to be better defined.

In my mind the usage should be:

Spin as the source with binary as the end result, and the intermediate C++ code is just a temporary step to a binary that should be ignored.

The generated code (in the past at least) is not maintainable as source code. The output in many cases created array indexed variables that are difficult to understand much less change by hand from one revision to the next.

Does this make any sense?

Electrodude · 2014-09-01 19:53

jazzed wrote: »

I hate to bring it up, but it seems to me at least that this is the wrong use of the tool.

Don't get me wrong. I applaud Eric's efforts, but the usage model needs to be better defined.

In my mind the usage should be:

Spin as the source with binary as the end result, and the intermediate C++ code is just a temporary step to a binary that should be ignored.

The generated code (in the past at least) is not maintainable as source code. The output in many cases created array indexed variables that are difficult to understand much less change by hand from one revision to the next.

Does this make any sense?

Then why don't you just use a spin compiler?

David Betz · 2014-09-01 19:59

Electrodude wrote: »

Then why don't you just use a spin compiler?

Because Spin code translated to C++ and then compiled with PropGCC runs faster than code compiled with the Spin compiler?

Phil Pilgrim (PhiPi) · 2014-09-01 20:13

Sometimes it's just easier to translate to another language whose compiler has a decent optimizer, rather than starting from scratch and writing your own full compiler/optimizer.

-Phil

SRLM · 2014-09-02 01:34

jazzed wrote: »

Spin as the source with binary as the end result, and the intermediate C++ code is just a temporary step to a binary that should be ignored.

Fair point. My perspective is that spin2cpp should be used to convert spin objects to C++ in order to build a library of C++ code. That's what I've used it for, and I like that usage. But they are two considerably different use cases.

Is there a strong case against doing both? It seems to me that the main difference between both is that for the binary case spin2cpp will have to generate a bit of boiler plate to get things started.

Rayman · 2014-09-02 03:12

What I meant to say is that people can develop C++ code using assembly drivers developed with Spin. I don't think there's a whole lot of people who would care if the assembly driver is a binary blob or assembly code.
And, anyone who did would probably be just fine with the Spin version of that assembly code...

ersmith · 2014-09-02 06:23

Thanks to all for the comments!

SRLM:

Improving the PASM support is something I'm still working on; I agree it's a priority for readable code. The --gas option converts the PASM to inline assembly, but local symbols and the like still aren't really working.

Jazzed:

I agree that spin2cpp 1.x is really best used as a compiler from Spin to machine code (with the .spin file as the primary source code). My goal with spin2cpp 2.x is to make the output C++ code more useful in itself. It may never be quite as natural as hand written C++, but it can certainly be better than it is now (as you've noted!)

DavidZemon · 2014-09-02 13:58

SRLM wrote: »

My perspective is that spin2cpp should be used to convert spin objects to C++ in order to build a library of C++ code. That's what I've used it for, and I like that usage. But they are two considerably different use cases.

I'll second this opinion. I plan to add Spin support to PropWare via spin2cpp. If any Spin files are added to the project, they'll be translated via spin2cpp to C++ source and then compiled (and linked with) PropGCC. I haven't looked into the details of this yet, but it should make mixed Spin and C/C++ projects pretty easy.

spin2cpp next generation

Comments