A Scripting Language for the SPIN2 - Interpreter? - Thoughts?
Christof Eb.
Posts: 1,590
Hi,
this is just an idea at this moment. Perhaps you would like to comment?
The basic idea is, that Chip's SPIN2 interpreter is a stack based machine, which interprets a very compact type of bytecode using the fast XBYTE mechanism of P2. I cannot say, that I do fully understand how it works. :-) But I do have the impression, that a Forth interpreter/compiler could be written for this machine. Yes, I know, that not everybody loves Forth, but it's simply rather simpel to write a Forth interpreter/compiler. Much simpler, than writing any other compiler. As it is simple, it can be rather compact. There is one bigger hurdle however: SPIN2 uses a single stack, while Forth needs a second stack. Forth consists of many small procedures, called "words", so it needs a fast way to call subroutines and return from them. SPIN2's calling mechanism is too complicated, I think. I have a vague idea, how to implement the second stack....
This would use a SD-card for a file system.
There should be an interface to call SPIN2-routines from Forth and also to call Forth routines from SPIN2.
It would be nice, if the multitasking of SPIN2 could be used, it's rather Forth-like anyways....
Suggestions, comments?
Christof
Comments
@"Christof Eb."
Forth has intrigued me in the past BUT if I can't grasp something, relatively easily, it's of no use to me. As more of an integrator, I just need stuff to work.
Despite the snobbery in the MCU world, BASIC is still growing.....because it's child's play. In the PLC world, we now have ST (structured text) that is arguably BASIC that has been modified to avoid using the B-word.
I started building industrial controllers using QuickBasic and to be able to make quick modifications without having to reset the entire process was a huge advantage. Everything I do has a BASIC interpreter on the front end. Why waste precious Prop resources on mundane tasks.
Here is an example of a multitasking BASIC on a high-end controller:
The calling convention in Spin2 is a bit more complicated than it would be if it used separate 'return' and 'data' stacks. Instead, it uses a single stack for both functions and this requires a bit of fancy footwork. I wonder, if I had used separate stacks, could calls and returns run much faster? It might make things 5 to 10% quicker. I didn't want to burden the user with having to pick out separate stack areas. One was already too many.
Hm, yes, these are nice looking tools. It's hard for me to recognise BASIC in the text though?!? And their controller https://www.triomotion.com/public/products/p660-p665.php has 1.2 GHz, 64 Bit Dual Core ARM Cortex A55 Processor, 1 GBit DDR3 Memory. = 256*P2 That's a very very different world to P2. How many man-years to develop such software?
What language do you actually use for P2? FlexBasic?
In my experience the choice of language for a microcontroller is not so important in relation to the availability of libraries to access hardware, sensors, smartpins. (The code snippet for "BASIC-R" above does not show any BASIC but mostly special commands to access hardware. They even use := ) To use the original SPIN2 interpreter or a slightly modified one, still working for SPIN, would enable to use OBEX library, that's the idea here. Also the combination should be compact.
I do like the possibility to try out things, which bring the interpreter languages Forth, BASIC, Lua, Python.
Recently I was having a look at UCSD-P system. While you can find the source code for an early PASCAL compiler for it, I did not see the source of a BASIC for it. It might be possible to adapt such compiler for the SPIN2 interpreter. For me structured BASIC would be more attractive than PASCAL. I don't think, that anyone is longing for GOTO and GOSUB.
The orange words are the Basic statements. Yes, the shown statements are particular to the Trio because they are dealing with the specialised hardware. The regular Basic statements like PRINT/GOSUB/GOTO/FOR/NEXT/WHILE/WEND/DO/UNTIL/IF/OR/AND/LEN$/MID$/... they all still exist too.
There is a function declaration mechanism that's also very useful. It's almost like an object in that a group of functions have to have their own locality and are stored in a separate .BAL program file. While the regular Basic programs are stored in .BAS files.
It has a nice simple way of doing multitasking too. Each program file is launched as a task with priority according to the task number. There is one large global shared variable array that can be accessed as both symbolised and by array look up. This same array is where remote devices like Modbus/Ethercat also have their mailboxes located.
The Trio's aren't great with strings but then a motion control system isn't going to be used for heavy string processing.
My one niggle is it doesn't support symbolised bit memory.