Spin as a PC Programming Language
![hippy](https://forums.parallax.com/uploads/userpics/339/nR1DFKQUWXIHE.jpg)
Good Idea ? Stupid ? Pointless ? Ridiculous ?
You have to throw away the notion that Spin is a language for an embedded processor but once that's done it's just a language like any other. C is nothing without its STDIO library etc, Spin's no different ...
Through the 'pc' object there would be access to keyboard, screen, files, serial port and any other physical PC hardware. Objects like 'tv', 'fswr' etc could all be abstraction layers to the 'pc' object; just change tv : "TV_Text" to tv : "PC TV_Text" and existing programs will run as expected.
Development would currently have to be done using the PropTool with its 32KB program limit but, with a different compiler, programs can be of almost any size (4GB).
Multiple Cogs can be used just as they are with the Propeller but don't have to be as limited in number. There's a question as to whether PASM would need to be supported but no reason it couldn't be. It wouldn't be deterministic but then we're not talking about precise bit-banging on a PC under windows anyway. There'd be no actual I/O but that's not really important on a PC either. Think of it as a programming language not a micro controller language.
You have to throw away the notion that Spin is a language for an embedded processor but once that's done it's just a language like any other. C is nothing without its STDIO library etc, Spin's no different ...
OBJ pc : "PC" VAR long fileHandle long i PUB Main fileHandle := pc.OpenFile( String("C:\TMP\SQUARES.TXT") ) repeat i from 0 to 10 pc.Dec( fileHandle, i ) pc.Out( fileHandle, " " ) pc.Dec( fileHandle, i * i ) pc.Out( fileHandle, $0D ) pc.Close( fileHandle )
Through the 'pc' object there would be access to keyboard, screen, files, serial port and any other physical PC hardware. Objects like 'tv', 'fswr' etc could all be abstraction layers to the 'pc' object; just change tv : "TV_Text" to tv : "PC TV_Text" and existing programs will run as expected.
Development would currently have to be done using the PropTool with its 32KB program limit but, with a different compiler, programs can be of almost any size (4GB).
Multiple Cogs can be used just as they are with the Propeller but don't have to be as limited in number. There's a question as to whether PASM would need to be supported but no reason it couldn't be. It wouldn't be deterministic but then we're not talking about precise bit-banging on a PC under windows anyway. There'd be no actual I/O but that's not really important on a PC either. Think of it as a programming language not a micro controller language.
Comments
Seriously I do, and I'm thick skinned enough to take the harshest criticism people can throw at me without falling out - as long as there's a decent rationale and it doesn't come down to "you're an idiot"
I think it's at the 'good idea' end of the spectrum but don't want to waste my time on that if it is a dead-end project, so I'm open to being convinced otherwise.
I'm not sure that this need be a true statement. There remain serial, parallel, USB, and backplane hardware options for I/O. Wouldn't these just become wrapped objects. I do understand that some (much?) determinism would be lost.
Have you distinguished this from just another Python, Java, C, Pascal, etc. on the PC?
On the other hand, it is your idea--run with it.
Daniel
Love the idea...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
The Spin language syntax and PASM syntax need to be expressed in BNF format or equivalent syntax. This would facilitate the expression in the formal syntax of well known tools and methods used for detailed implementation. The problem then becomes a classical computer science 202 (second year) college level exercise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
Yes, that was my sloppy terminology. I meant I/O as in connected to OUTA/OUTB, no physical leg connections ( though one could theoretically route them out to LPT / Game Port etc pins ).
It is "just another language" as I see it, competing amongst all the others. It's USP is that anyone who's programmed a Propeller in Spin could move their skills to PC programming even if they've never done that before, although I admit that's more marketing claim than any real justification.
The way I was going to do it was to interpret the actual .eeprom file ( leave compiler writing for others to solve ). The abstraction layer objects would have lightweight interfaces or only the method headers which the interpreter would recognise and handle, enough to shift interpreting to 'do something special' and it has full access to what's on the stack ...
In theory, it would be possible to take the PC object and turn that into something which would run on the Propeller itself ! A sort of BIOS/STDIO wrapper in its own right.
it can even have >32K using the proptool, because buffers like screen buffers etc, can be at >32K because registers and pointers are 32bit. yeah, I can see this being rather cool, so yeah Go for it [noparse]:D[/noparse]
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
On the other hand...
Why do we need a PC object? If my little Propeller project uses FullDuplexSerial or TVtext or such then it should compile and run unchanged on my PC mapping serial on to USB ports or TV into a window or whatever.
As it stands Spin is not "just another language". It has the whole idea of parallelism built in from the beginning. Can't think of any others that have apart from Ada and Occam just now.
So the challenge would be to map Cogs onto the cores of my dual, quad whatever comes next PC processor whilst kicking the host OS off of those.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The price entry point for getting involved with the Prop is so low that almost anyone with a PC and a interest in microcontrollers can have one.
Though it would be interesting intellectual exercise to see if a Spin compiler could be built to do SMP and hyperthreading on multi-core platforms.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
@ waltc : Rather than this being a replacement for a Propeller ( everyone should have at least one ), it was more to bring the advantages of Spin to the PC environment. I don't know what exactly it is with Spin but I've found it to be very efficient as a rapid development environment, although I don't know how that would fare as a PC programming language. It can be used as a Propeller Spin Simulator / Debugger but that wasn't the primary intent.
@heater, waltc : I wish I knew enough about multi-core PC's to even contemplate running Spin/PASM code across multiple cores. I'm intending it to be single core, at the moment single threaded with my own time-slice handling but I could go multi-threaded later.
Anyway, almost finished
Well, about 75% there. I guess that when you've written one Spin Interpreter every next one gets easier. I've got it printing to the screen so proof of concept is okay, now to fill in the code for the other bytecode handlers.
You might consider using the "B" I/O "pins" for system calls, like to Windows.· You could even use DIRB and OUTB for two separate 32 bit parameters and INB to read the result of a Windows call.· The actual registers are not used currently, yet are accessible using both Spin and assembly.· Part of either DIRB or OUTB could be used for a "Windows call" index.· Just a thought.
An alternative, if you're not doing it already, would be to use specific hub memory locations above $FFFF since these are accessible both in Spin and assembly, yet not implemented in the current Propeller chip.
Post Edited (Mike Green) : 7/29/2008 11:09:30 PM GMT
Have a look at inpout32.dll not as easy as it was on dos or win98 machines ... win2K and above needed the likes of this.
logix4u.net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html
and
logix4u.net/
also 64bit version ..
simple to use .. very much like QB !
e.g. out 888,255 ' (address,data)
where out 888,255 is D0 to D7 all high
out 888,0 D0 to D7 all low
and obviously all values inbetween to set one or more high etc..
Might be of some help if you decide to roll with actual I/O's..
Regards,
John Twomey
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 7/30/2008 12:12:48 AM GMT
By the way, the mini was RISC, no registers as such, all memory to memory, (but decimal!!) much like the Prop. I had it validated, and it ran 3 times faster.
By placing a "DAT long $5C7C3C00, <id>,<version>" at the start of an object it's possible to identify what an object is ( it's not valid Spin, very unlikely PASM and only a one in 2^32 chance of being actual data ). Access to FullSerialDuplex etc could be caught this way but there's no standard so it only works for trapping the PC object.
@ QuattroRS4 : It's something which I will consider as it would be nice to control physical PC I/O lines.
@ Cluso99 : Thanks for the offer but I think I'm doing okay as it is. I'll get Spin emulation working first and then consider PASM and more complex emulations. As its usefulness is less than clear I'll get the basics working then see where that and feedback leads to. Source code will be included so people can add their own extensions to PC Object.
There didn't seem to be support either way. Still, it's something I'd like to see.
And yes, absolutely I would entertain this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Seems we all kind of wandered away from the main idea of your original post.
I suppose .spin for PC programming makes sense with a good and transparent
COM interface (whatever the object model is called today). I'll try almost anything
once and if it's easier to use than C#, I might continue using it. My main concern
would be with whatever changes Microshaft might make to break things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
What's ultimately available would really depend upon what language was used to implement the PC Spin interpreter, all its interfaces to an OS would be available for access via Spin. I was looking to develop something which worked at the command line and showed the possibilities which others could pursue rather than take that to an all-singing-and-dancing level. Apologies if I've misled anyone into thinking I was planning more than I am.
Now, on the original concept, I love the idea.. even if only from an academic perspective. It depends on how far you want to take the emulation I guess, but as a quick and dirty PC language it's got a bit going for it. I'd probably use it just to knock up quick control based thingos.. and a cross platform interface to a real propeller for hard I/O (although not at all fast).
I can't off the top of my head think of real world uses.. but then I can't think of a good reason to climb a mountain either.. it's there [noparse]:)[/noparse]
Perhaps a simple stepping debugger/emulator like mplab does to make it _easy_ for absolute beginners to see why what they want and what they are getting are two completely different things [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net