xspin

Dave Hein

After working with Spin for a few months I've come up with a list of features that would be nice to have.· I realized that these features could be added by defining an extended version of spin, which I call xspin.· Some of the features on my list are as follow:

1. Macros
2. Conditional compile
3. Include files
4. Native floating point support
5. Remove the need for the String and Constant intrinsics
6. Generate assembly code from Spin

I started work on a utility for item #6 about a month ago.· It still has a ways to go, but it does generate useable assembly code.· I have a C preprocessor that I wrote for another utility, and I integrated that in a couple of hours.· It provide the C macros, conditional compile and include functionality.

It should be pretty easy to incorporate the string intrinsic.· I get a little tired of typing things like
print(string("Hello World")) when it would be easy to automatically generate it from print("Hello Wordl").

I think native floating point support would be extemely useful.· This way the programmer could type statements like x := cos(angle) * y, and the pre-processor would automatically generate the proper floating point function calls.· As long as there is at least one floating point function or constant in the expression the pre-processor would treat everything as floating point.· We could introduce a floating point type , but that may be a bit controversial for spin programmers.

Eventually, the pre-processor could be integrated into an IDE, which would generate spin bytes, but that would be a long ways off.

What do people think about this idea?· Are there any other features that would be nice to have in xspin?

Dave

Phil Pilgrim (PhiPi)

Dave,

Most of those items, along with a few others, have been on a lot of wish lists for a long time. Since they haven't been forthcoming for the Prop I IDE, I'm hoping that they will be included in the dev tools for the Prop II and that those dev tools will also be capable of supporting the Prop I. Chip has been very generous in sharing his hardware plans for the Prop II. Perhaps Jeff could weigh in a little on what new software features are afoot. Jeff?

-Phil

Cluso99

We already have item #2 in bst and homespun.

Item #5 would be really nice and probably simple to add to bst and homespun, but could also be added with a pre-processor.

Likewise, #1 & #3 could be added with a pre-processor. I have often missed the Include Files.

So, maybe you could write a pre-processor for #1, #3 & #5 for starters and then maybe Brad & Michael might integrate it into their compilers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

Leon

Just get the m4 macro-processor, and pass your code through that before compiling it. It will handle the first three items on that wishlist. A SNOBOL pre-processor could do everything apart from floating-point:

en.wikipedia.org/wiki/SNOBOL

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Post Edited (Leon) : 3/2/2010 8:23:03 AM GMT

Dave Hein

Thanks for the suggestions.· I'll look into the m4 macro processor.· The C macros will work for single lines, but I will have to modify it a bit to handle spin indentation for multiple lines.

SNOBOL?· I Remember people using that back in the 70's.· Does anybody actually use SNOBOL anymore?· I have a library of C string routines that I use that work pretty well.

I would be interested in looking at previous threads that discussed Spin enhancements.· Does anybody have pointers to some good threads?

Another feature that I want to add is function pointers.· There is a current thread on function pointers and callbacks that reminded me about that.· Another thing that would be useful is type-declaration for local variables, like the ones used in VAR sections.· This could be inline with the PUB/PRI statement or they could immediately follow it.· It would look something like this:

PUB MyMethod(x, float y) | a, word b, byte c[noparse][[/noparse]10], d
· word e, f, g
· float z
· ...

x, a and d would be longs.· b, e, f and g would be words and c would be a byte array.

Dave

Post Edited (Dave Hein) : 3/2/2010 9:16:13 PM GMT

Leon

I first came across SNOBOL in the 1970s. I was working for Xerox Research (UK) and used one of the Xerox Corp. XDS Sigma computers in Rochester via a very slow cross-Atlantic link. I found that it had SNOBOL on it and used to go in to work early so that I could play with it. It's possible to write a compiler in one page of SNOBOL, and an assembler in half a page. Catspaw is now giving away their full implementation for the PC. I remember meeting Mr Catspaw at a computer show in London, once.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Mike Green

Leon,
Once upon a time I had a pseudo-code description of the SNOBOL II pattern matching algorithm, but I've lost it and don't remember it well enough to reconstruct it. Might you have something like that or a link to a description. It's much different from later SNOBOLs' pattern match and simpler. The "back-matching" part was also simpler than more recent pattern matchers.

Leon

You might find it here:

www.snobol4.com/

There is plenty of source code there. anyway.

It was Mark Emmer of Catspaw who I met, that's his web site. He might be able to help you find it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM