Spin2 vs MicroPython - might MicroPython be a better solution for P2?
Cluso99
Posts: 18,069
Eric has done a splendid job with his compilers for P2 and has baked MicroPython as well.
I've been doing some work in Python for work. The Python language has a lot of niceties that is in spin, like no { and } as in C. There are a few gotchas wrt spin, like the ":" after an if/elif/else clause.
Everything in Python is an object. Any python program can automatically become an object for a subsequent python program - just declare it as "import xxx" which is just like OBJ in Spin.
Python is also interactive, so you can just type in a single liner and it will be run - just like Basic used to be.
So, question is this....
Would MicroPython (which is MIT open sourced) be a better alternative than developing Spin2 for P2 ???
I know Spin2 is close, but this might just be a totally better option.
I've been doing some work in Python for work. The Python language has a lot of niceties that is in spin, like no { and } as in C. There are a few gotchas wrt spin, like the ":" after an if/elif/else clause.
Everything in Python is an object. Any python program can automatically become an object for a subsequent python program - just declare it as "import xxx" which is just like OBJ in Spin.
Python is also interactive, so you can just type in a single liner and it will be run - just like Basic used to be.
So, question is this....
Would MicroPython (which is MIT open sourced) be a better alternative than developing Spin2 for P2 ???
I know Spin2 is close, but this might just be a totally better option.
Comments
I do love Python but I can't yet see myself using MicroPython. MicroPython will only hint at what is possible using Spin2. If I have the picture right, MicroPython will need in line assembly in order to approach the speed of what Spin2 can do natively.
Other than that I only have questions.
1. Spin2 will be really fast. How does MicroPython compare?
2. (As of not too long ago) MicroPython didn't support multi-threading.
a. How do we get compiled assembly code into a cog?
or b. Do we launch multiple copies of MicroPython and live with multiple interpreters? Is that even possible?
3. Can MicroPython and Spin2 share a P2? Can I call Spin2 from MicroPython or vice versa?
Thanks
There are multiple Forth on the P1, multiple Basic's, multiple C's and multiple spin's. The problem of the P1 was that it had JUST Spin at the beginning.
On the P2 the situation is quite different, there are just about 100 P2's out in the world and we have already support for two Forth (ROM and Tachyon), erics compiler collection with Basic, C and Spin, Catalina C as full blown C and Prop1Gcc conversion working already.
The RiscV emulation does not just support MicroPython, if I am not misinformed it supports everything gcc can throw at it so we basically even have C++ support. (Fortran anyone?)
I think this is pretty impressive for a chip not even available in production amounts.
Enjoy!
Mike
Spin 2 can compile to byte codes, and can compile to PASM .
If anything, this reinforces the push to continue to make Spin2 simpler, and more Python-like so that users do not have to plow thru manuals...
I think most of the `unexpected conflicts` have already gone, so a Python student can be fluent in a subset of Spin2 fairly quickly ?
I'm not sure this is nor should be the goal of spin2. Spin2 is spin2 and any resemblances to python is a coincidence (and solely based on the way block statements are handled, i.e. indented instead of with a begin/end indicator)
I thought my thread was quite reasonable considering where we are in 2019.
MicroPython seems to have quite a good following. Anything that can kick-start the P2 should be considered. There are lots of libraries (ie code) that should work as-is now that the micropython interpreter is in place (thanks especially to Eric).
Spin for P1 came out some 13 years ago. Thing were way different back then. Over the years, tons of spin objects have been built, and posted in obex.
Today, things are very different. I would expect that P2 could benefit way more by supporting micropython. Ken has already said as much on the micropython thread.
However, with sooo many options seeming to be available for P2, but with so few actually doing anything productive, I would hate to see P2 fail because development is too splintered to gain any reasonable traction.
I am quite sure that the micropython interpreter can be P2-used to get quite reasonable performance. And if it takes off, i’d be reasonably confident that a compiler could be done.
BTW micropython already supports dual core operation on the ESP.
And self hosting is already a reality, but limited atm, on P2!
Both Micropython and Pasm2 cog types can talk with smartpins. But the big micropython heap in hub memory really means you really just want that single micropython core. Its hard to see how to get micropython running in multiple cores, unless we divvy up hub ram.
There's no question Spin2 that should be finished. It's going to be super lean and 'in tune' with the hardware architecture, doesn't have garbage collection going on. Its just a case of the right code type for the job, the same way we split some P1 code into Pasm1 and some in Spin1.
What aspects of self hosted micropython do you regard as 'limited' ?
And now we have Tachyon. I'm not working on real problems with Tachyon up to now (as I started early, there were the pitfalls of a non stable system) and I for sure will do a lot of work in the future using Tachyon. Because the concept of a stack machine is well known to me since HP35 and I know, that will carry us to the future. It's a pity, that Peter is not seen as a evangelist, but as christ. Otherwise many would follow him and help to spread the power. I feel we all just say: Wonderful Church service at Camp Peter. Thank you! Hope to be able to come back to work soon.
So, Cluso99, there are no issues if (as I think Mike and jmg suggested) we simply leave room for a selection of languages to choose from. I don't see that as splintering. If Spin were to be thrown out and replaced with MicroPython.. I'm out of here.
Even though I speak PASM2 fluently I really could have used Spin2 many times.
I can see applications for all. (Spin2,PASM2 and micropython).
P2 has been designed for hard and fast realtime control, something that mainstream "microcontrollers" do not do well. Well, they do kinda, but they try to do that with whole subsystems that may do the job and if they don't, then tough. P2 does not compete with an ARM in the same price range when it comes to memory and executing mainstream languages. I don't mean samples and games and benchmark programs, I mean 24/7 blackbox grunt firmware that just works. So the language is just a means to an end, and that end has to do more than say hello world and blink an LED (as delightful as that is).
That's my 2 cents worth.
One issue with the way Micropython works is how it gobbles up memory. (Granted, garbage collection releases it again). OzProp made a neat whole-of-hub live viewer that shows what happens when you type a memory hungry comment. The standard demo command is "fact(800)" which calculates 800 factorial and prints the result out a few seconds later. That single command consumes most available of memory during its internal machinations, which makes it good for demo purposes.
On PC python, you hardly notice this stuff. I wonder whether similar python memory visualisation tools exist for PC based Python. But of course with micros things are tight.
I throw this idea out there here, because I've been thinking about it, but we really need a new thread for it. What would a Micropython system look like, if the heap was located in a large external serial memory, rather than hub? There would be more room, and you could have muiltiple cogs running Micropython if you wanted to (each with its own serial memory), and hub would be freed up for inter-cog interactions like its best suited to. Would it be horribly slow? Does the speed really matter? (it hasn't for what we have done with Micropython so far)
Don't take it too negative. I'm with @msrobots, @@ozpropdev,....: love micropython, but love spin/pasm aswell. Heck I dabble(d) in many programming languages, which we may never see on the prop2. I think it is healthy to have a choice.
And I'm in awe with people like @"Peter Jakacki" and @ersmith and yourself , who show the rest of us what can be done. Don't know where you all get the time
For what I am using Python for at work, there are no speed issues because in the end, I don't care how long it takes to do its job. I think it's well known that Python is not fast - it's a means to an end. From that perspective, I would think the same applies to micropython.
For spin, again we aren't really concerned with speed - we use pasm for that. But spin on P1 was seriously slow, and it had to be to work. We all would have liked it to be faster, but it just worked.
On P2, yes, spin2 will be much faster. While much of the code we will use spin2 for, the speed will not matter. But I am sure we will make spin2 do a lot more than we did on P1. So I guess I am ok with having spin2 as well as micropython.
What I would like to see is the spin language "merf" into a more general use language, and python/micropython seems to fit that bill quite nicely. If that could be the case, of course with a few caveats, we could have the best of both worlds. The compiler could take the same code and output either spin2 or micropython, or indeed pasm2. That would be a big bonus for P2 and its users. Indeed, if we get here, I would think we could probably target much of the micropython "REPL" code (ie the interpreter) into spin2 bytecode. Now, that would be something!
I agree uPython would and should be advertised along with C ahead of any mention of Spin.
The congnesceti here understand Spin and all its capable of, however to the wider world it YAFPLA.
No reason both can't be continued, however Python is most certainly going to get the attention of /edu decision makers and loads of others a lot more than Spin.
I understand some may not like that fact, however it doesn't preclude Spin in any way, and only helps Parallax.
Like with the P1, hand in hand. And it is good like that. Parallax education stuff switched barely from Spin to C to Blockly producing C,
my guess is that getting Blockly on the P2, via Catalina C, FastSpin C or P2gcc is more important then Python.
All those nay-sayers make me uneasy.
We have Forth in ROM but should not mention it. We have Basic and Spin working and should not mention it, we should just talk C an promote Python, because the RasPi uses Python, this is all complete BS, sorry.
We should EMBRACE the ability of using different languages for different projects.
Anyways, Enjoy!
Mike
Parallax should leverage all the languages you mentioned.
However, C is a natural in the professional world, and is expected by such.
Python is far more popular than any of the others you mentioned, so why would one logically try to push another niche of a niche programming language at the outset of a new product launch?
I don't think its any stretch of the imagination to posit that trying to push an unknown language on to potential interested parties of an unknown new processor isn't and shouldn't be expected to fair any better this decade than last.
Is Parallax trying to sell Spin or Prop's?
If a microPython demo is used to show off the P2, then it won't. It will be too slow and too limited. If a C demo is used perhaps it will run fast but how do we go with larger programs? Will we start running out of memory?
However Spin2 is designed for speed and compactness because we don't want to use up all the memory just for code unless we never display anything but lores or text.
What I can never understand is what has happened to education. When I was a kid they employed learning by rote which is entirely frowned upon and condemned these enlightened days, yet I can perform many simple and even complex maths operations in my head, so it can't be that bad. Education today is supposed to teach kids "not how to do it " but "how to think" or something like that. But has that worked? First off, they can't even add a list of simple numbers in their head and barely with pen and paper, and secondly, they can't seem to "think".
I say this because it seems that if they have been taught C, then they can never seem to think out of the C box and learn different ways of doing things. Why is learning Spin such a big problem? Well it isn't if you are used to learning "how to think". I know I picked up the basics of it immediately and finer points over the next few days and weeks. Sure, I seem to use Forth on the Prop more but that's because I like the speed and interactiveness of it as well as the fact that it does so much with so little (look at my Mandelbrot plot) and I use it as it is meant to be used in that you make it an "application specific language" rather than trying to write C code in Forth. (that's probably why it is too hard to teach)
But I digress as the main point I am trying to make is that I don't see Parallax as trying to "sell" Spin or Props because as you may have noticed, Chip has not designed a mainstream CPU to sell to the unwashed masses, and so Spin2 is designed to go hand in hand with the P2. Funny thing is that poor Ken has to figure out how to "sell" P2s to an increasingly lego block app generator (de)generation
Over the last 3-4 decades I have not found ONE customer using Linux as Desktop for the Company and none using Python at all.
I am just a Code Monkey programming for my whole life, mostly on big iron, lately bound to switch to PC hardware, so maybe my experience is different from others.
In theory I am language agnostic, I program in whatever language the customer/client/employer uses. I also had to adapt to coding/naming styles every time, and I have not really a problem with it. I usually just need to solve the problem in my head, once the solution is there it does not really matter in what language I write it down, finally.
I see languages come and go, and I find it interesting to play with them, a lot are short lived, some survive. And with survive I am talking about Systems designed to run over decades not just the kickstarter/VC financed startup period.
I am, on the other hand, the guy who turned down the offer to write software for some guys trying to make a flee market on the internet, telling them this is a complete stupid idea. They later got bought and renamed to EBAY. So I know that I don't know.
Currently most of the code running worldwide is still running in COBOL. Nobody believes that, usually, but it is so. It is just that Banks, Insurances, the Post office, the IRS and other big iron users do not allow there programmers to share things over the net. So the internet does not know/care about it. But most of that code has thousands of man-years of code in it and often those guys who wrote that code are retired or simply dead by now.
But you can be rest assured that NO Python program on NO pc hardware is able to print the phone bills for AT&T. And it will not happen in the future.
OK, we are talking about Micro controller, but like @"Peter Jakacki" said they need firmware (grunt ware he said) just doing the job, and once finished, never updated, never changed, running for years.
How often one 'updates' his thermostat for A/C and Heating?
But sometimes you need to change things , years or decades later. If it is COBOL - no problem, backwards compatible in 99% of the code.
Running Python 2.7 under 3.x? not so good, and we are talking about just a couple of years.
C is different there, it found its place and I agree that it is a good choice. But Python, Php, Erlang, Go, Modula2, REBOL, gosh the list is way longer, are languages not even stable over month of a time, and definitely not over decades.
Interestingly most code running outside of our planet, on rovers, explorers, satellites is written in FORTH.
Anyways, rant over,
Mike
So, yes the "new generation" cannot add or subtract, and good heavens they certainly cannot multiply and divide. But they have calculators phones for that, and the cash register / computers do the change for them. They wouldn't know if they were short-changed. But that is just the way it is, and no amount of discussion will change that now
Now to correct a few myths.
Cobol might still be running on big-iron. But those numbers are now miniscule compared to the servers, PCs and tablets/phones around the world. Notice how IBM is almost unheard of today??? They may make the biggest and most powerful, but they are now far and few by comparison. So, Cobol isn't mainstream and mostly relegated to maintenance, so no need here to keep advancing the goal-posts. But I have to take my hat off that Cobol lasted - I guess Mike is right, too much old code running on monsters. Cobol wasn't all that efficient compared to assembler, but my guess it's still much closer to the iron than any of the newer languages. Cobol was more of a batch language when I wrote Cobol code, and certainly no GUI, just plain text out.
Python is being used for AI and in lots of data intensive areas. It's well removed from the iron, and since it's interpretive, its normally slow compared to other languages. But hey, the AI stuff is quite advanced, running on GPUs and Tensa cores. now, I for one can attest for it being used commercially. You see, the company I now work for does indeed use Python for quite a bit of its mainstream work. I might add, this section is not speed dependent.
So Python speed is not that important. In the education department, that is probably even more so. The big thing about Python is that it is often run line by line which again makes speed unimportant. It certainly makes debugging easy. Each line you type in and execute gives a result so its debug as you go. Yes, you can execute a routine (in Python, this is just another Python program). i can certainly see the attractiveness of it to education. And, it's self-hosted, so its cheap - another boost for education.
On to C. C was said "to be a language developed by those who feared they were going to lose their programming jobs, so better make is complex". To me, this is precisely what it does. Most C programmers doesn't even understand (nowadays) just what C does under the hood. They need a fast processor to get the job done because they lack the understanding of how it runs on the iron. BTW I am biased - I'm glad I never really learnt C.
Where does that leave us...
Well, it's the customer. It doesn't matter what any of us think. It's the customer that counts.
And it seems the customer wants C and Python/MicroPython.
Now, Python (I am going to combine Python and MicroPython here) has an interpreter. This interpreter is reasonably large on a micro. So here's the rub. The language is similar in many respects to spin/spin2 (referred now as spin). So Eric's compiler can take spin and convert to PASM but that is large too. What if it targeted spin bytecode? We expect great things with P2 spin bytecode. So, what if the Python Interpreter was tweeked into spin bytecode, perhaps with a bit of PASM in just the right places. This may just get the size down to a reasonable level, and the speed up to a reasonable level.
I have to do this sometimes to combine stuff written in C with stuff written in COBOL. It is doable, one need to compile link libraries, .o or .so files, use and write make files, care about call conventions, yes it works but is a PITA.
With fastspin on the other hand you just include a object written in whatever seamlessly into any other supported language. This is HUGE.
I do know that I sound like a @ersmith fan club and I am considering of setting one up, we all should cheer him on and support his work.
I do not really like C# and the net framework, but programming it for some years now. Then I had a short job for CISCO replacing some VB6 code by - guess - Visual Basic Net, not C#. Took me two days to switch the language and coding convention, (1 day maybe just READING all the coding convention documents and memorizing them. Cisco is pretty strict with naming conventions).
If you really want to educate people, you need to teach them to think, like @"Peter Jakacki" said. Teaching them Python, or C or Spin is - hmm - irrelevant. One has to teach them how to make a algorithm out of a vague Problem description of some non programmer who has a problem to be solved, no clue how to do so and no overview over the complexity of the complete System he is working with.
What language you use makes no difference. Like you I never learned C, but just because I had no employer/client demanding it. I DO use that language sometimes but I am pretty sure that If the existence of your boat would depend on you to fix some C code in two weeks, you will program in C pretty fast.
So, again, REPLACING Spin by Python is a no-go, HAVING python self hosted on the P2 is absolutely cool.
And Ken will need Blockly running to market the P2 in his current educational environment, that puts C on the front.
But when you get your OS running on the P2 one can run Python created binaries or Spin ones as well as - hopefully - COBOL-Z80 ones under CP/M.
Enjoy!
Mike
But I would counsel that spin where possible looks like python because that’s (python) what the customers want. What it ultimately compiles to is basically hidden, so if spin2 looks like (micro)python and runs like it, then it might pass as python. So hopefully this can be achieved.
FWIW as soon as I get a chance I want to complete my spin1 interpreter. I was quite a long way along and had some P1 spin bytecode running (ie a P1 compiled bytecode program). That will get my OS running. Then I can get CPM going. I am not expecting either to be difficult. It’s just a time problem. Maybe I’ll get time on our UK trip next month.
Mike
Still is with MM BASIC.
Sitting on a factory floor right now, debugging and developing code for a machine-tool.
This is directly on the PIC32MX470 and it's absolute child's play. :cool:
Yep, just turned the clock back 40 years. Now just need peek and poke
So much so, in fact that some are changing the name in order to drop the "Beginner's" bit.
What's it called now, Baython? Pysic? Oh, that's right...Python
I'd bet that once matured, the micropython on P2 will outperform Spin2 (the interpreter running bytecode).
I'll be using C++ on P2, so I guess I don't really care about all these other languages other than it's cool to support as many as feasible.
I like both BASIC and Python, but they're very different languages. Python is entirely object oriented, which has its good and bad points. Some modern BASICs have objects, but they don't pervade the language the way they do in Python. Which again has its good and bad points (Python may be more consistent, but BASIC is simpler and clearer in some ways).
Objects are very clever tho, as they are just other python programs. Thus, any python program can instantly become an object of any other program where some or all of its functions are callable. Its very similar to spin objects.
In spin
OBJ
fds = ‘fullduplexserial’
ch = fds.rxchar
In python
import fullduplexserial as fds
ch = fds.rxchar()
Regex - regular expressions parser for replacing and manipulating strings. Regex is used in lots of languages etc including Notepad++
BeautifulSoup - and html parser, decoder, builder etc. Again, extremely powerful. Can decde html web pages simply. Also does xml.
CSV and Excel and SQL read/write/append files.
Time/Date/TimeDate routines
OS for file access
Pandas for database and dataframe manipulation including the various joins. Extremely powerful SQL like statements/functions
Numpy for statistical analysis - havent used this yet but its on the agenda.
These and many others are widely used. From what ive seen, its all/mostly open sourced. IIRC Python is MIT.
There is an extremely active forum on StackOverflow. I received answers - yes multiple - with a couple of hours. Extremely active and helpful. Can you believe it is better than this forum was in its hey days!! Never though i would ever say that. But it’s Q &A only, no discussions.
All these fantastic libraries will be available to us on P2 if we can support python. I am not sure how much micropython limits us.
Maybe we are going to need those HyperRAM boards after all