Spin as a PC Programming Language

hippy

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 ...

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.

Rayman

You don't want to know what I think about this idea! [noparse]:)[/noparse]

hippy

You don't want to know what I think about this idea! [noparse]:)[/noparse]

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.

daniel

hippy said...
There'd be no actual I/O...

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

Oldbitcollector (Jeff)

I'd use it...


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

Mike Huselton

I see no problem with the concept of abstracting the state machine model and implementing this state machine in C#, Python, (C)Lisp, etc.

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

hippy

@ daniel : There'd be no actual I/O... I'm not sure that this need be a true statement.

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 ...

{ PC.Spin }
DAT
  byte "My Magic Marker"
PUB FileOpen( strPtr )
PUB FileClose( fileHandle )
PUB Hex( fileHandle, value, width )
etc

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.

Baggers

Hippy, honestly mate, I think that's a FANTASTIC idea, for beginners to program on PC, especially if it has many tv display modes, like text or bitmap and sprites for mouse etc. keyboard and mouse objects and file handling etc. I'd say go for it. it'll also give people insite to prop coding, and bring more into it too, once they see how easy it is, you could even have LED objects and 7seg LED displays, and even oLED style drivers. so yeah I think it's a really good idea [noparse]:D[/noparse]
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

·

heater

Hippy: I think you are losing your mind.

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.

waltc

Pointless.

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.

Beanie2k

I would like it. One of the factors that has kept me from learning spin is that I don't want to learn a whole new language just to program one chip. If I could also use spin to program a PC, my interest level would go up a lot. Besides, there are many places where I have a PC, but not a Prop (here at work for example).

Rayman

Well, maybe it could be useful as a Prop emulator...· Might· be useful to test out programming ideas on the PC if no Prop were handy...

Baggers

Exactly Rayman, I say Hippy should go for it, I know there it will have many good uses.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

hippy

@ heater : The problem with trying to run a .eeprom as is on the PC is that there's not enough information in the image to say that something is a call to a serial object etc. There aren't any kernel calls or hardware specific register access to trap. It is however possible to change FullDuplexSerial to PC_FullDuplexSerial which abstracts the PC object re-compile and that will do what's required when run on the PC.

@ 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.

Mike Green

hippy,

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

QuattroRS4

Also to be able to physically change the I/O of the parallel port (D0 .. D7) i.e. pins 2 to 9
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

Cluso99

@Hippy - if you want to run in ASM on the PC, I wrote a minicomputer emulater in the late 80's / early 90's using 486 33MHz specifically targetted to the faster instructions. The mini I emulated had 20 timesliced processors and I emulated this. I could probably dig the code out (need some time -it is at home 700km away). However, I may be able to help you.

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.

hippy

@ Mike : That's a good idea and how I'd probably do it if the Propeller Images were different. As it is it is possible to identify which is my PC Object and therefore trap calls to it at a much higher level, plus the advantage that the user has ready to go PUB DoThis(...) functions to call without having to worry about what to poke and where.

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.

MarkS

I brought this very topic up in February: http://forums.parallax.com/forums/default.aspx?f=25&m=253792

There didn't seem to be support either way. Still, it's something I'd like to see.

potatohead

Brilliant!

And yes, absolutely I would entertain this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

jazzed

Mark.
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.

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

hippy

My intention is to deliver something which is more comparable to QBasic-level programming ( Perl-level if one takes offence at Basic ) in so much as I was looking more at console rather than GUI programming. As with C, there's no implicit interface to the real world at all until libraries are included and run-time support is provided so whatever libraries and run-time are available a PC Spin language could use.

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.

Pavel

In my opinion this is a worthy project. I too find Spin really easy to use for quick development, the objects are well encapsulated and easily reusable. I'd definitely use it (most likely in connection with a real Propeller project).

BradC

Not to take anything away from the original concept, but if you can program in spin you are about half a step away from Pascal.

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!

potatohead

Heck, use PERL to write it. PERL can be compiled down to binaries, and there are a ton of modules already done. What does exposing those to SPIN look like?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net