Shop OBEX P1 Docs P2 Docs Learn Events
OpenSpin Spin/PASM compiler in C/C++ — Parallax Forums

OpenSpin Spin/PASM compiler in C/C++

Roy ElthamRoy Eltham Posts: 3,000
edited 2014-11-10 10:57 in Propeller 1
Updated: 10/13/2014

To report issues, browse the documentation, or access the latest source, go here: https://github.com/reltham/OpenSpin

Windows binary builds are provided by me, you'll need to build binaries yourself for other platforms. It's recommended that you build from the latest release version of the source instead of using the head revision, unless something in a pre-release source update fixes an issue you are having.

Releases are at: https://github.com/reltham/OpenSpin/releases

You can browse the changes I've made in the source commits at github. In the future, I'll list significant changes/fixes in the release descriptions.
«134567…13

Comments

  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-01-23 11:26
    Awesome Roy!

    Any chance it'll compile in GCC on the Prop itself in the future?

    OBC
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-23 11:27
    Roy,

    Could you also include a downloadable zip of the source so that lurkers like me don't have to go through the subversion stuff just to look at it?

    Thanks,
    -Phil
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-23 11:40
    Jeff,
    The propgcc guys have already brought that up as a possibility using one of the XMM models. I think it would be awesome, and I'll help make it happen if it can.

    Phil,
    I'll do that tonight when I get home (will be late, so check back in the morning).
  • Heater.Heater. Posts: 21,230
    edited 2012-01-23 12:16
    Oh yeah. Spin/PASM development on the Prop itself is not far away. What are we going to use as an editor?
  • jazzedjazzed Posts: 11,803
    edited 2012-01-23 13:16
    Phil Pilgrim (PhiPi) wrote: »
    Roy,

    Could you also include a downloadable zip of the source so that lurkers like me don't have to go through the subversion stuff just to look at it?

    Thanks,
    -Phil

    It's here (in case you haven't found it yet):

    http://code.google.com/p/open-source-spin-compiler/source/browse/
  • RossHRossH Posts: 5,462
    edited 2012-01-23 14:08
    Roy Eltham wrote: »
    Hello everyone,

    The porting of Chip's x86 assembly code for the Spin/PASM compiler is nearly complete. We have created a Google Code repository for it here: http://code.google.com/p/open-source-spin-compiler/

    ...

    Anyway, go download the code! Build it, run it, jump up and down on it, do whatever you want! It's all open source (MIT license), and you are free to do whatever you want with it.

    Roy

    Fantastic work, Roy - another missing piece of the puzzle falls into place!

    Will you be doing the Prop 2 version? Any date for release of that yet?

    Thanks,

    Ross.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-23 14:14
    RossH,
    I believe I will be involved with the Prop2 version. I don't have any information on any release dates, sorry.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2012-01-23 14:20
    This looks rather clever - well done.

    Thinking ahead about self compilation on the propeller, boot into a command line operating system like kyedos, run a text editor (there are a few possibilities), save the file, go back to the operating system, run a precompiled GCC program to process the file and produce a .binary output, rename that .binary as a .exe and then run it.

    Any idea (roughly) how long it would take to compile a 1000 line program on the propeller itself?
  • Cluso99Cluso99 Posts: 18,069
    edited 2012-01-23 14:50
    Great new Roy. Been waiting for this.

    re Compiling on the prop...
    For now, we can use wordstar under ZiCog & CPM. I am working on file transfer between cpm and the prop FAT16/32 using Kyes SD driver. I am well on the way with this and hope to have the cpm->FAT working in the next day or two. Currently I am limited to 4KB transfers (1 block) and am testing up to 32KB (8 block) which is 1 directory entry on cpm. Then I have to check multiple Dir entries that larger files use. I can detect eof with text files but not with binaries so I am presuming that it really does not matter on the FAT side. Time will tell.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-23 14:53
    jazzed wrote:
    It's here (in case you haven't found it yet):
    Got it! Thanks! And, Roy, thanks for undertaking this very important project. Who knows? I might even learn to like C++. :)

    -Phil
  • RossHRossH Posts: 5,462
    edited 2012-01-23 14:56
    Phil Pilgrim (PhiPi) wrote: »
    Who knows? I might even learn to like C++. :)

    Phil! Noooo.... Just walk away! ... Walk away NOW! ....
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-23 14:58
    RossH wrote:
    Phil! Noooo.... Just walk away! ... Walk away NOW! ....
    Well, okay, maybe I can learn just enough to translate the compiler into Perl. :)

    -Phil
  • Heater.Heater. Posts: 21,230
    edited 2012-01-23 15:04
    Roy has been very sparing in his use of C++ features in this compiler. No templates or stl for example. So you should be safe.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-23 15:06
    Phil,
    Be aware, that this codebase is not the best representation of C++ (yet). It's really more like C with a few classes sprinkled in. Plus I take advantage of a few C++ features like references.
    Over time, I plan to do more cleanup that will reduce the amount of globals, and likely increase the amount of classes and C++ features. I will NOT be using STL.

    Of course, nothing is stopping anyone from taking this code and converting it to plain old C, Java, C#, or any other language really. At least nothing but time and effort. :)

    Roy
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-23 15:14
    Roy,

    Did you or Chip ever produce a formal grammar for Spin syntax? If not, is there any plan to? Just curious ...

    Thanks,
    -Phil
  • Heater.Heater. Posts: 21,230
    edited 2012-01-23 15:32
    Strangely this threads page includes a "similar threads" link to a posting by a TonyZ from 2007 where he is requesting a open source IDE and even volunteering to incorporate a Spin compiler dll into Eclipse. He did not even get one reply!!
    It's been a long road....
  • pedwardpedward Posts: 1,642
    edited 2012-01-23 16:01
    I noticed the floating point code file is just a commented copy of the x86ASM and doesn't have any functions. Does that mean the FP portion of the SPIN compiler is not yet implemented? I also learned there are many more operators available in the SPIN compiler for floating point, than are documented. There appears to be support for all standard operators and square root!.

    The ASM appears to be decently documented, is there any chance we will see the source of that?

    The port appears to be exactly that, was there consideration given to writing it as a LEX/YACC proper grammar compiler, or was porting the only desired option?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-23 16:07
    pedward,

    Floating point in Spin is implemented via method calls. The floating point methods are written in Spin and PASM. Overloading the standard operators to perform floating-point arithmetic would require a FLOAT type, which Spin does not have. Floating point numbers are stored as longs and how they are treated is specific to whether the FP methods are invoked overtly in the Spin source or not.

    -Phil
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-23 16:19
    pedward:
    That floating point code is only used at compile time for float constants. I implemented most of the via just using C/C++'s build in float support. That is one area where this compiler might not being 100% binary matching with the x86 code, because occasionally the lowest bit(s) of precision in a float number might differ. We opted to go with standard C/C++ float support because it follows the IEEE standard.

    I actually had not intended to include that file, and it'll be taken down when I get home, since it's not needed. I have removed the contents already since I could do that easily from here.
  • pedwardpedward Posts: 1,642
    edited 2012-01-23 16:27
    Perhaps I wasn't clear that I was referring to compile time floating point. The reference to FP in the manual is very sparse, so seeing the breadth of operators that the compiler will handle at compile time was interesting.

    What determined the decision to do a port versus rewriting it and using the original code as a guide?

    Is there a chance we will see the original x86 code?

    EDIT: The manual would seem to suggest that FLOAT was originally intended to be implemented as part of SPIN, but left out due to size constraints? You can do a 32bit single precision float, and having FLOAT in SPIN would potentially eliminate the need for a dedicated COG for that. With an LMM model, SPIN could do float natively I would think.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-23 23:06
    Hey everyone,
    I updated the executable download to a new version that should not have any external dependencies. This was build with VS2008 in release mode and static linking of the runtimes.

    I also added a zip containing the source code as of r24, so you can download it without having to install svn.

    pedward:
    Sorry for my confusion. Yeah, float support in spin would be really nice. However, with the Prop 1, the spin interpreter is in the rom. Yes, there are tricks to work around that and get custom ones running, but I can't imagine one doing float plus everything else without using 2 cogs (at least). On the Prop 2, I think it should be quite reasonable to do though.
  • RossHRossH Posts: 5,462
    edited 2012-01-23 23:39
    Roy Eltham wrote: »
    Hey everyone,
    I updated the executable download to a new version that should not have any external dependencies. This was build with VS2008 in release mode and static linking of the runtimes.

    I also added a zip containing the source code as of r24, so you can download it without having to install svn.
    Thanks Roy!
    Roy Eltham wrote: »
    pedward:
    Sorry for my confusion. Yeah, float support in spin would be really nice. However, with the Prop 1, the spin interpreter is in the rom. Yes, there are tricks to work around that and get custom ones running, but I can't imagine one doing float plus everything else without using 2 cogs (at least). On the Prop 2, I think it should be quite reasonable to do though.

    Just have to point out here :) that Catalina supports basic FP operations (add, sub, mul, div) as fast implementations within the LMM kernel cog. This makes it the fastest floating point programming option available for the Propeller. You don't need any external cogs (i.e. the the whole standard C FP library is emulated in software) but if that's not fast enough for you you can add either one external cog (i.e. simple FP library functions done in a fast cog implementation, complex FP functions emulated in software) or two external cogs (all FP functions done in two fast cog implementations) depending on your speed and space requirements.

    And the next version of Catalina will be even faster!

    Ross.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-23 23:47
    Ross,
    I was speaking only of Spin when I was talking about requiring more than one cog for FP.
  • RossHRossH Posts: 5,462
    edited 2012-01-23 23:51
    Roy Eltham wrote: »
    Ross,
    I was speaking only of Spin when I was talking about requiring more than one cog for FP.

    Yes, I know ... but it never hurts to advertise!

    Ross.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-24 00:02
    I think it's entirely reasonable to incorporate floating-point processing into Spin run-time expressions in the Prop1, using the current interpreter. Having to use a separate PASM cog to do the actual computations is in keeping with the Prop's soft-peripheral philosophy. In this case, the peripheral is an FPU. By adding a FLOAT modifier to long variable declarations, expressions can be parsed with reference to the type of each value on the stack, with longs promoted to float for mixed-mode operations, and method calls inserted to perform the FP operations.

    The tricky part will be parameter passing, since all parameters are assumed to be longs. This could be accommodated by allowing a method's formal parameters to be declared with the FLOAT modifier. It would then be up to the compiler to apply float or int to the results of any expressions passed as parameter values, depending upon the target method's formal parameter declarations. The same would also have to apply to any values returned, where the method could apply the FLOAT modifier to its result variable.

    I've used the word "modifier" instead of "type" because Spin is an inherently typeless language and, IMO, should stay that way. That may be a distinction without a difference, though, except that the default "type" for all longs, including formal parameters and local variables, will still be integer unless modified. The modifier could be as simple as a trailing decimal point in the variable name where it's declared, in order to avoid syntactic clutter.

    -Phil
  • Dave HeinDave Hein Posts: 6,347
    edited 2012-01-24 07:11
    Phil, the type specifier (uh, I mean "modifier") is a great idea. I would suggest adding a "pointer" modifier, and maybe a "string" modifier as well. I realize the "string" keyword is already defined, but its use could be made context sensitive. The biggest pitfall that newbies run into is the correct use of pointers, strings and floating point values. The modifiers would be optional, but when they are used it would allow for type-checking (err, I mean modifier-checking).
  • tdlivingstdlivings Posts: 437
    edited 2012-01-24 09:19
    Roy
    In the role of ginny pig I tried executing spin.exe and got a missing dll message.
    What are the minimum things that need to be installed on a PC to run the program.

    Tom

    MissingDll.png
    MissingDll.png
    551 x 249 - 29K
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-24 09:29
    tdlivings,
    That was the issue where the previous version required MinGW. I updated it last night. If you get spin-r24.zip it should not need anything else installed to work.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2012-01-26 02:57
    I have updated the project in google code to version r25. It now has CompileDoc translated from x86 to C/C++. This means the translation is complete.
    I added a -d option to spin.exe that will dump out the results of CompileDoc (it's the same is documentation mode in the Prop Tool).

    Now it's just any bugs that our found, and then on to new features and changes. :)
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2012-01-26 08:18
    Roy,

    Can we talk about Spin/PASM language extensions here, or would you prefer devoting a different thread to that?

    -Phil
Sign In or Register to comment.