Don't we already use two languages on the P1 and probably will also on the P2? We write high-level program logic in Spin or maybe C/C++ and then time-critical stuff in PASM. What's the difference if the high-level language is Javascript instead of Spin?
P2 will be much more C-Centric than P1, and the C tools can generate a variety of code Size/Speed choices, as well as allow in-line assembly, plus there will be Debug support in C.
Even Heater admits above that three languages will be needed JS + C + PASM .
That's fine by me, if someone really wants to juggle three languages, I'm not going to stop them, but smarter to get PASM and C working properly first, before getting distracted into the JS sandpit.
That's fine by me, if someone really wants to juggle three languages, I'm not going to stop them, but smarter to get PASM and C working properly first, before getting distracted into the JS sandpit.
As far as I know, every Javascript implementation is written in C or C++ so it won't even be possible to get Javascript working without a working C/C++ compiler.
Is anyone working on C for the P2? I know Dave Hein was working on a compiler a while back but I think he's abandoned that effort. Also, some people have mentioned wanting to use LLVM. Is any of that work underway? It would be too bad to end up with multiple C compilers especially if an LLVM one is being worked on and would have better performance than one based on GCC.
So, what are the options for using JavaScript on an embedded board where node.js/Johnny Five (whatever) runs the connected hardware, and a Webkit-based browser displays the user interface on a connected screen?
Is anyone working on C for the P2? I know Dave Hein was working on a compiler a while back but I think he's abandoned that effort. Also, some people have mentioned wanting to use LLVM. Is any of that work underway? It would be too bad to end up with multiple C compilers especially if an LLVM one is being worked on and would have better performance than one based on GCC.
I was impressed by the fastspin compiler for P2 (& p1) by @ersmith
I think it is waiting on Chip's Doc's, but seems advanced, and supports in-line ASM.
Given Spin is somewhere between Pascal (or Oberon) and Python, it may be possible to vary the front end to support those two languages in a subset form, that may be more portable than Spin.
Now PropBASIC has gained an IDE, what about PropBASIC for P2 as well ?
So, what are the options for using JavaScript on an embedded board where node.js/Johnny Five (whatever) runs the connected hardware, and
a Webkit-based browser displays the user interface on a connected screen?
I'm not sure what you are fishing for there Gordon.
Espruino is a tint JS engine that runs on the tiny Espruino boards, of course, but can also be used on other hardware. I run it on an STM32F4
Discovery board for example. The latest "official" Espruino board is a Nordic Semiconductors Bluetooth chip. http://www.espruino.com/Reference
Of course Espruino can be built for any Linux running system easily, like the Raspberry Pi or those routers running OpenWRT. https://github.com/espruino/Espruino
2) Tessel
Stepping it up a bit there is the Tessel https://tessel.io/. The Tessel was it's own JS engine at one point but is now using node.js on an ARM running OpenWrt. That's nice and all but at this point I'd go for a Raspi or whatever Linux running ARM board to run node.js
3) Node.js.
The big one. Googles V8 JS engine. Runs on Windows, Mac, Linux. Runs great on the Pi or any Linux running ARm board.
Node.js is quite cabable of serving whatever web content you like, that's what it's for. There are many modules available to deal with serial ports, GPIO, PWN, etc, etc.
Not se easy options are to grab a tiny JS engine source and get it running on whatever MCU you have in mind. Like Samsung's Jerry script: https://github.com/Samsung/jerryscript
I have no idea what Jonny Five is. Seems to be a protocol and libs for talking to little embedded boards like Arduino. Never looked into it.
Now, where do you wantto run that browser? On the same embedded machine? If so then you need node.js and a Pi like machine.
I seem to have missed one of your posts here on my frantic recent travels...
That sweeping claim [getting rid of types] depends very much on your host...
Sweeping yes. It's nothing to do with the host. It's to do with the programmers. Specifically beginner, part-time, casual programmers who want to get something done without getting bogged down in technical details. For them numbers will do. They don't want to know or care about signed/unsigned, byte, word, double, etc. It's just a technical detail they have to worry about and will trip them up when they get it wrong.
Umm, lets try those embedded fundamentals of Speed and Size ?
I think I said already that if it fits and it's fast enough there is no problem with speed and size.
A bold claim [one dollar controllers can handle this stuff well enough], any links to what that 'well enough' escape clause means, or any $1 chips that have
64b FPU ?
"Well enough" is all the things people are enabled to do by the Espruino, for example, http://www.espruino.com/
I don't know any cheap MCU's with 64 bit FPUs. I think I mentioned somewhere, the little JS engines don't use the FPUs on MCUs. 32 bits is not enough.
One dollar may be pushing the point a bit but STM32 is very cheap I'm sure we are near the 1$ price point.
Now, don't get me wrong. I love languages with types. C, C++ and so on. I'm arguing for a different programmer audience, like Bill Gates and his BASIC on micro-processors in times gone by. We need C/C++ to create JS and other tools for those guys after all
Sorry if I'm repeating myself. I have been travelling so much this past week I don't know what I said to whom or where!
... Specifically beginner, part-time, casual programmers who want to get something done without getting bogged down in technical details. For them numbers will do. They don't want to know or care about signed/unsigned, byte, word, double, etc. It's just a technical detail they have to worry about and will trip them up when they get it wrong.
...
I don't know any cheap MCU's with 64 bit FPUs. I think I mentioned somewhere, the little JS engines don't use the FPUs on MCUs. 32 bits is not enough.
If these beginners believe "numbers will do" as you claim, then 32 bits will be enough.
Of course absolute novices can use Float right now on small MCU, and sometimes, some even do use float almost everywhere.
It is usually quite soon after they ask "Why is my code so slow" ?
Seems those claims of not caring about size and/or speed, have already been novice-tested, and failed. The pool of even novices/beginners who really do not care, is simply too small.
For those handful, there is the PiZero.
JS use 64 bit floats. Often that is used to hold integers up to 53 bit precisely. Chopping the numbers now to 32 bits means the integers top out at 24 bits. No good. Breaks lots of stuff.
It's not all about floats when it comes to novice/casual programmers, its the whole language and the infrastructure.
Seems those claims of not caring about size and/or speed, have already been novice-tested, and failed. The pool of even novices/beginners who really do not care, is simply too small.
At that point I thought your were going to link us to some article about how this was tested and how it failed. Or how the pool of novices is too small.
The ESP WIFI devices are immensely popular. They use Lua. Much like JS. Speed is not the issue.
The Epruino just Kickstarted a whole new JS micro-controller platform. Met its target in one day and is now more than 3 times over it's initial goal.
Then there is the MicroPython, not JS but a very similar concept and motivation.
All this suggests this novice testing has been successful and the pool is quite big enough.
Here's another survey worth looking at. As it's IEEE, this is probably better aligned with the market(s) that the Propeller would be used in. There's much less insight as to what these numbers represent, but still worth taking note of. It certainly backs up the argument for needing C/C++ support. If you filter it to only "Embedded", JavaScript is nowhere to be seen. And Forth still makes the list!
One can always pick holes in such language rankings but really I expect more from the smart folks who are members of the esteemed IEEE:
1) "Arduino" is not a programming language. It's a hardware/software platform. It should not even be on the list or perhaps whatever points it accrued should go towards C++.
2) "HTML" is not a programming language. It's a document mark up language.
3) I'm not even sure VHDL and Verilog belong on a programming language ranking.
4) Labview is not a language used on embedded systems. Sure Labview is used with embedded systems on PC's.
5) Javascript could not appear in embedded because they have excluded it. As they say 'We take a pragmatic approach to how we classify languages into types like “embedded” or “Web.” Placement is based on typical use: For example, we are very impressed by those brave souls who have written Web servers completely in assembly code, but we don't categorize Assembly as a Web development language'.
6) JS has a totally misleading, or at least incomplete, description pop up if you hover you mouse over it.
7) Same as 5) but for Java and Python.
8 ) No idea why TCL is included in embedded.
Anyway, glad to see C/C++ where they should be and Ada is still holding up.
I would venture to say there is more JS being written for embedded systems today than Forth. I'm doing so as we speak
Meanwhile, over on another famous language ranking, the TIOBE index, this month sees assembly language break into the top 10 ! http://www.tiobe.com/tiobe-index/
Meanwhile, over on another famous language ranking, the TIOBE index, this month sees assembly language break into the top 10 ! http://www.tiobe.com/tiobe-index/
Interesting link. Go Assembler !
hehe, even COBOL improved too...
I see Delphi improves, to move ahead of Visual Basic, & Python moves ahead of C#
In tracking those smallest chips, that target 'your tooth brush or coffee machine', the 'forced to use Assembler' factor is quietly going away.
Last year, the cost-performance-leader was SiLabs EFM8BB1, with 2K of Flash (31.1c/1k), so that does strongly infer Assembler.
However, this year we see n79e715as16 with 16k of flash, (lower MHz, relaxed ADC) come in at 28c/1k
That's enough code space to run HLL and some Floating point.
Whilst we debate the pros and cons of getting Javascript running on the P2 something amazing has happened to add some validity to the whole crazy idea.
You can now program your Pebble smartwatch in Javascript:
The Pebble has even less memory available than the P2. Only 128 KB RAM. But they do have 512 KiB FLASH and huge amounts of what I assume is SPI FLASH attached.
Pebble has used the JerryScript engine. Pretty amazing.
It doesn't seem to be. Since you've "unsunk" the thread...
In the "Python on Propeller" thread, there was a somewhat similar observation about the RAM vs. flash requirements. Obviously, the P2 won't have flash, but is that a problem? Or just an inconvenience? Put another way, is the lack of onboard flash going to effectively deter these languages from being ported to the P2?
In the "Python on Propeller" thread, there was a somewhat similar observation about the RAM vs. flash requirements. Obviously, the P2 won't have flash, but is that a problem? Or just an inconvenience? Put another way, is the lack of onboard flash going to effectively deter these languages from being ported to the P2?
Yes and no.
If that on-board flash is large, and code can execute from it with just a couple of wait-states, then that memory becomes part of the code-pool, so should be counted in comparisons.
Serial Flash can 'sort-of' compensate, especially if you can load it fast enough, or even better reach XIP speeds via HyperFLASH or QuadSPI_DDR for example.
Also the playing field is not quite level, as a Prop2 user with 16 cores, is going to expect more usable memory left over, than someone using a single core part.
ie a useful target would be less than 50% of the 512k needed for Favourite Script Language.
As far as I can tell 512K RAM is enough for Micro Python and Javascript.
External FLASH for program storage would be fine.
MicroPython on ESP8266 runs "frozen modules" from flash.
That makes sense. We could do the same with P2 since I assume both MicroPython and JavaScript will be interpreted from some sort of bytecode. As long as the compiler and runtime fit in the P2 512K of RAM then we should be okay.
The Espruino JS engine does not use byte code. It interprets the good old fashioned way straight from the source text. Apparently that is because there is not enough room on the devices it runs on to fit a compiler. Besides the idea is to provide an interactive REPL. However Esprunio also provides a means compiling a subset of JS to machine code for when you need the speed. Integer only, some dynamic features of JS not included.
The JerryScript engine does compile to byte code I believe. But it lack the REPL as far as I can tell.
Esprunio works with as little as 48K RAM. It needs 256K for the engine itself though. Which I can imagine being twice as big compiled to Propeller code.
The Espruino JS engine does not use byte code. It interprets the good old fashioned way straight from the source text. Apparently that is because there is not enough room on the devices it runs on to fit a compiler. Besides the idea is to provide an interactive REPL. However Esprunio also provides a means compiling a subset of JS to machine code for when you need the speed. Integer only, some dynamic features of JS not included.
The JerryScript engine does compile to byte code I believe. But it lack the REPL as far as I can tell.
Esprunio works with as little as 48K RAM. It needs 256K for the engine itself though. Which I can imagine being twice as big compiled to Propeller code.
Compiling to bytecode does not mean you can't have an interactive REPL. As far as memory requirements go, it sounds like Espruino will be a tight fit on P2 since 256K * 2 + 48K is larger than the 512K available on the P2. However, it might still be possible with some sort of overlay scheme.
I have a hard time understanding what it means to compile JS to byte code. For example, if my program using the number X is compiled to byte code presumably the generated byte code handles X as a number. But my program can change the type of X at anytime, X = {}. Then what?
Or do they Just In Time compile to byte code such that the byte code can be regenerated on the fly when a type changes like that?
Or is it so that one can design a byte code that handles all this without recompilation? Perhaps with enough indirection anything is possible.
Comments
Even Heater admits above that three languages will be needed JS + C + PASM .
That's fine by me, if someone really wants to juggle three languages, I'm not going to stop them, but smarter to get PASM and C working properly first, before getting distracted into the JS sandpit.
-Phil
Pasm is rather obvious that it will come first
Spin might make sense as a second [high level] language if its interpreter is written in C or C++ instead of raw pasm
What I meant was that we need a C/C++ first in order to compile a JS engine for the Prop. I don't know any JS engines not written in C/C++.
I'm sure Spin will be around for the P2 soon enough.
I was impressed by the fastspin compiler for P2 (& p1) by @ersmith
http://forums.parallax.com/discussion/comment/1374633/#Comment_1374633
I think it is waiting on Chip's Doc's, but seems advanced, and supports in-line ASM.
Given Spin is somewhere between Pascal (or Oberon) and Python, it may be possible to vary the front end to support those two languages in a subset form, that may be more portable than Spin.
Now PropBASIC has gained an IDE, what about PropBASIC for P2 as well ?
Current easy options are:
1) Esprunino. http://www.espruino.com/
Espruino is a tint JS engine that runs on the tiny Espruino boards, of course, but can also be used on other hardware. I run it on an STM32F4
Discovery board for example. The latest "official" Espruino board is a Nordic Semiconductors Bluetooth chip. http://www.espruino.com/Reference
These Espruino solutions can server up web pages with a suitable WIFI module http://www.espruino.com/ESP8266
Of course Espruino can be built for any Linux running system easily, like the Raspberry Pi or those routers running OpenWRT.
https://github.com/espruino/Espruino
2) Tessel
Stepping it up a bit there is the Tessel https://tessel.io/. The Tessel was it's own JS engine at one point but is now using node.js on an ARM running OpenWrt. That's nice and all but at this point I'd go for a Raspi or whatever Linux running ARM board to run node.js
3) Node.js.
The big one. Googles V8 JS engine. Runs on Windows, Mac, Linux. Runs great on the Pi or any Linux running ARm board.
Node.js is quite cabable of serving whatever web content you like, that's what it's for. There are many modules available to deal with serial ports, GPIO, PWN, etc, etc.
Not se easy options are to grab a tiny JS engine source and get it running on whatever MCU you have in mind. Like Samsung's Jerry script: https://github.com/Samsung/jerryscript
I have no idea what Jonny Five is. Seems to be a protocol and libs for talking to little embedded boards like Arduino. Never looked into it.
Now, where do you wantto run that browser? On the same embedded machine? If so then you need node.js and a Pi like machine.
What's the thing with webkit?
I seem to have missed one of your posts here on my frantic recent travels... Sweeping yes. It's nothing to do with the host. It's to do with the programmers. Specifically beginner, part-time, casual programmers who want to get something done without getting bogged down in technical details. For them numbers will do. They don't want to know or care about signed/unsigned, byte, word, double, etc. It's just a technical detail they have to worry about and will trip them up when they get it wrong. I think I said already that if it fits and it's fast enough there is no problem with speed and size. "Well enough" is all the things people are enabled to do by the Espruino, for example, http://www.espruino.com/
I don't know any cheap MCU's with 64 bit FPUs. I think I mentioned somewhere, the little JS engines don't use the FPUs on MCUs. 32 bits is not enough.
One dollar may be pushing the point a bit but STM32 is very cheap I'm sure we are near the 1$ price point.
Now, don't get me wrong. I love languages with types. C, C++ and so on. I'm arguing for a different programmer audience, like Bill Gates and his BASIC on micro-processors in times gone by. We need C/C++ to create JS and other tools for those guys after all
Sorry if I'm repeating myself. I have been travelling so much this past week I don't know what I said to whom or where!
Of course absolute novices can use Float right now on small MCU, and sometimes, some even do use float almost everywhere.
It is usually quite soon after they ask "Why is my code so slow" ?
Seems those claims of not caring about size and/or speed, have already been novice-tested, and failed. The pool of even novices/beginners who really do not care, is simply too small.
For those handful, there is the PiZero.
JS use 64 bit floats. Often that is used to hold integers up to 53 bit precisely. Chopping the numbers now to 32 bits means the integers top out at 24 bits. No good. Breaks lots of stuff.
It's not all about floats when it comes to novice/casual programmers, its the whole language and the infrastructure. At that point I thought your were going to link us to some article about how this was tested and how it failed. Or how the pool of novices is too small.
The ESP WIFI devices are immensely popular. They use Lua. Much like JS. Speed is not the issue.
The Epruino just Kickstarted a whole new JS micro-controller platform. Met its target in one day and is now more than 3 times over it's initial goal.
Then there is the MicroPython, not JS but a very similar concept and motivation.
All this suggests this novice testing has been successful and the pool is quite big enough.
http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2016
1) "Arduino" is not a programming language. It's a hardware/software platform. It should not even be on the list or perhaps whatever points it accrued should go towards C++.
2) "HTML" is not a programming language. It's a document mark up language.
3) I'm not even sure VHDL and Verilog belong on a programming language ranking.
4) Labview is not a language used on embedded systems. Sure Labview is used with embedded systems on PC's.
5) Javascript could not appear in embedded because they have excluded it. As they say 'We take a pragmatic approach to how we classify languages into types like “embedded” or “Web.” Placement is based on typical use: For example, we are very impressed by those brave souls who have written Web servers completely in assembly code, but we don't categorize Assembly as a Web development language'.
6) JS has a totally misleading, or at least incomplete, description pop up if you hover you mouse over it.
7) Same as 5) but for Java and Python.
8 ) No idea why TCL is included in embedded.
Anyway, glad to see C/C++ where they should be and Ada is still holding up.
I would venture to say there is more JS being written for embedded systems today than Forth. I'm doing so as we speak
Interesting link. Go Assembler !
hehe, even COBOL improved too...
I see Delphi improves, to move ahead of Visual Basic, & Python moves ahead of C#
In tracking those smallest chips, that target 'your tooth brush or coffee machine', the 'forced to use Assembler' factor is quietly going away.
Last year, the cost-performance-leader was SiLabs EFM8BB1, with 2K of Flash (31.1c/1k), so that does strongly infer Assembler.
However, this year we see n79e715as16 with 16k of flash, (lower MHz, relaxed ADC) come in at 28c/1k
That's enough code space to run HLL and some Floating point.
http://alpha.trycarbide.com/
It looks interesting, but that main pages causes the fan in my laptop to ramp up!
You can now program your Pebble smartwatch in Javascript:
Devkit here: https://developer.pebble.com/guides/communication/using-pebblekit-js/
The Pebble has even less memory available than the P2. Only 128 KB RAM. But they do have 512 KiB FLASH and huge amounts of what I assume is SPI FLASH attached.
Pebble has used the JerryScript engine. Pretty amazing.
In the "Python on Propeller" thread, there was a somewhat similar observation about the RAM vs. flash requirements. Obviously, the P2 won't have flash, but is that a problem? Or just an inconvenience? Put another way, is the lack of onboard flash going to effectively deter these languages from being ported to the P2?
As far as I can tell 512K RAM is enough for Micro Python and Javascript.
External FLASH for program storage would be fine.
Yes and no.
If that on-board flash is large, and code can execute from it with just a couple of wait-states, then that memory becomes part of the code-pool, so should be counted in comparisons.
Serial Flash can 'sort-of' compensate, especially if you can load it fast enough, or even better reach XIP speeds via HyperFLASH or QuadSPI_DDR for example.
Also the playing field is not quite level, as a Prop2 user with 16 cores, is going to expect more usable memory left over, than someone using a single core part.
ie a useful target would be less than 50% of the 512k needed for Favourite Script Language.
The Espruino JS engine does not use byte code. It interprets the good old fashioned way straight from the source text. Apparently that is because there is not enough room on the devices it runs on to fit a compiler. Besides the idea is to provide an interactive REPL. However Esprunio also provides a means compiling a subset of JS to machine code for when you need the speed. Integer only, some dynamic features of JS not included.
The JerryScript engine does compile to byte code I believe. But it lack the REPL as far as I can tell.
Esprunio works with as little as 48K RAM. It needs 256K for the engine itself though. Which I can imagine being twice as big compiled to Propeller code.
I have a hard time understanding what it means to compile JS to byte code. For example, if my program using the number X is compiled to byte code presumably the generated byte code handles X as a number. But my program can change the type of X at anytime, X = {}. Then what?
Or do they Just In Time compile to byte code such that the byte code can be regenerated on the fly when a type changes like that?
Or is it so that one can design a byte code that handles all this without recompilation? Perhaps with enough indirection anything is possible.