Has anyone ever thought about porting SPIN to the PC?

MarkS

I know that this is a very strange question, but after playing around with this language I find that I REALLY like it! I understand that its current implementation is limited by the Prop, but that wouldn't be an issue in Windows. I think it would be a fun and rather easy OOP language to work with outside the Prop, with suitable expansions and features necessary for Windows.

Anyway, enough crazy rambling.

mosquito56

··· Not sure about crazy. In some computer science degrees one class is totally devoted to writing a language from scratch. This is considered an advanced class maybe graduate level but since I graduated so many years ago and only taught high school math and basic computers it may be an undergraduate requirement now.

·With vbasic, C, C++ available free it may be a fun project but not alot of need out there.

·If it floats your boat, go for it...


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·······

······· "What do you mean, it doesn't have any tubes?"
······· "No such thing as a dumb question" unless it's on the internet
········

StefanL38

Hello Mark,

did you ever take a look at Delphi ?

c++ is more cryptic to read than Delphi. Compared to SPIN Delphi has much more OOP Opportunities !

What's better in SPIN than in Delphi is the effective way of creating blocks of code by indenting

Here SPIN forces everybody to write in a good formatted way

In Delphi you have to write
begin .... end for every block

So a Delphi derivate with indenting instead of begin ... end would be my absolute favorite for programming on PCs !

greetings

Stefan

MikeK

If you like indenting without begin/end, check out Python. www.python.org.

hippy

I've thought about porting Spin to PC; after all it's just writing another VM. The issue though is to what intent ?

Spin is entirely self-contained. Its only I/O through the Special Purpose Registers and limited Cog peripherals. Any complex I/O implemented by bit-banging the very same where timing is everything.

How and what to map to the outside PC environment is key to purpose and I personally couldn't see it.

Spin on another microcontroller, that I can see as having a use.

MarkS

I guess what I'm getting at is a language reminiscent of SPIN but with the features C++. I like the way the code in SPIN is structured. The use of tabs instead of "{}" or similar is really nice not to mention the lack of a need for ";" at the end of every line. Programs in it are easier to write and read than C++. They seem to make more sense. Anyway, like I said, crazy idea.

jazzed

Well you could develop your spin app without needing a Prop ... of course you would need some kind of hardware IO emulator.

Given the right kind of tools, one could design and test their entire system in the virtual world of the PC without having hardware. If a generic hardware solution like a boe-bot or something more robust is physically available with net access for example you or anyone else could test the design a world away. May need constraint, a web cam, and a battery charger.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley

Traffic is slow at times, but Parallax orders·always get here fast 8)

Paul Baker

hippy said...

Spin on another microcontroller, that I can see as having a use.

Now that's an idea; now the code is out, why not port it. Would be interesting to see how many extra instructions are required for other microntrollers to implement it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Phil Pilgrim (PhiPi)

It amuses me a little, this sudden burst of energy for Spin compilers and interpreters, apparently spawned by Chip's release of the Spin bytecode interpreter. It's almost as if the clouds have parted, and the angels are singing. And while I'm very grateful for Chip's generosity in revealing his code and allowing us to witness the interpreter's inner workings, I have to wonder: how has that changed the landscape for compiler and interpreter writers, really? Well, not that all that much if you think about it. The real sea change occurred months ago, resulting from the work of Cliff, GEAR, and Hippy in decoding the bytecodes themselves. Those, along with some header and pointer details, are really all one needs to know to write a compiler, or as Hippy has already demonstrated, another interpreter. What's happening now could have happened back then. But I guess the more recent surge of activity just demonstrates a fundamental fact of human nature: the imprimatur of our host is still important!

-Phil

cgracey

Phil Pilgrim (PhiPi) said...
It amuses me a little, this sudden burst of energy for Spin compilers and interpreters, apparently spawned by Chip's release of the Spin bytecode interpreter. It's almost as if the clouds have parted, and the angels are singing. And while I'm very grateful for Chip's generosity in revealing his code and allowing us to witness the interpreter's inner workings, I have to wonder: how has that changed the landscape for compiler and interpreter writers, really? Well, not that all that much if you think about it. The real sea change occurred months ago, resulting from the work of Cliff, GEAR, and Hippy in decoding the bytecodes themselves. Those, along with some header and pointer details, are really all one needs to know to write a compiler, or as Hippy has already demonstrated, another interpreter. What's happening now could have happened back then. But I guess the more recent surge of activity just demonstrates a fundamental fact of human nature: the imprimatur of our host is still important!

-Phil

Funny you should bring this up, Phil. I wrote a similar post earlier, but then hit 'cancel' instead of 'submit'.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Chuck McManis

So one of the tools that I use is called "Proteus VSM" which is sold by Lab Center Electronics in the UK. They offer as part of the package a full chip simulator for PIC and AVR chips. Tney also offer VSM for the BASIC Stamp so presumably they could code up a SPIN VSM module for folks designing with the Propeller chip.
--Chuck

Chuck McManis

And for MarkS, if you like SPIN you really should check out Python. There is a wonderful environment for the PC and it has many of the things you find so enjoyable about the SPIN language but with the extensions you need when you move from an embedded environment to a workstation environment. (not to say Python isn't at home in an embedded environment too, just that most people use it on Windows or Linux)

--Chuck

hippy

Paul Baker (Parallax) said...

hippy said...


Spin on another microcontroller, that I can see as having a use.

Now that's an idea; now the code is out, why not port it. Would be interesting to see how many extra instructions are required for other microntrollers to implement it.

Quite a few I would expect for an 8-bit but others may fare better. The advantage of most modern micros is that that they have quite large memories these days so interpreter code size isn't that much of a problem.

Execution time is a different matter.

Most micros are single-core so while Spin-only is perfectly feasible and useful in many circumstances ( probably no worse than PBasic performance - gut feeling ), the real power of Spin comes with the Propeller itself. Multiple Spin Cogs can be emulated but that impacts performance although it still has its advantages. CogNew provides a very easy and easy to understand means of enabling multi-tasking.

Whether to also emulate PASM ( not the existing ROM interpreter written in PASM unless one wants a slow system ! ) is a debatable issue as I don't see it would deliver anything useful; most PASM is for specific purposes and requires the timing a Propeller gives. Allowing multiple Cog emulation with native assembler could have some purpose but would still have limited use. Something like the Virtual Peripheral approach of Javelin may be an alternative there. Both would be a deviation form Spin as we know it.

Another issue is RAM, but there's no reason Spin bytecode could not be executed directly from external Eeprom albeit relatively slowly. Real RAM can be virtually mapped to where it would be above the bytecode image. As self-modifying of Spin bytecode is a very rare case it wouldn't be necessary to have 32KB of RAM, but the more the better. A purpose built downloader could copy an .eeprom file straight to target Eeprom via the target.

A few simple mods to the PropTool or a third party compiler would allow bytecode to be generated to suit any particular target, set constraints and flag when capacity is exceeded. Even without that, the PropTool can still be used for program writing.

Ultimately there's no reason a network of cheap micros could not be used to give true multi-Cog emulation as fast as they can ( high-speed comms and a common I/O block ), nor any reason that FPGA could not be used ( that could emulate PASM and even run the ROM Interpreter ) but that's moving towards being more of academic interest where a genuine Propeller would better fit the bill for most people.

It's not really about competing with the Propeller though - it has its own USP's which would be hard to match - but about leveraging what Spin gives more than anything else.

crgwbr

MikeK said...
If you like indenting without begin/end, check out Python. www.python.org.

I'd second that. Python, IMHO, is is about as similar to SPIN as you'd want on a computer. Anything more, and I think you'd be kinda limited.

Regards,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My system: 1.6 GHz AMD Turion64 X2, 4GB DDR2, 256MB ATI Radeon Graphics card, 15.4" Widescreen HD Screen

I have a duel boot of Ubuntu Linux and Windows Vista. Vista, because it came with the PC, Ubuntu because I like software that works.

"Failure is not an option -- it comes bundled with Windows."

Use The Best...
Linux for Servers
Mac for Graphics
Palm for Mobility
Windows for Solitaire