4 ms·

Is this really a good idea? Yes, JavaScript is popular but if you're running on a microcontroller and already short of resources, is it really worth it to spend

by exDM69 13y ago

Is this really a good idea? Yes, JavaScript is popular but if you're running on a microcontroller and already short of resources, is it really worth it to spend a lot of your cycles interpreting JavaScript? A lot of microcontroller code has some real time requirements. Even some of the simplest Arduino code out there. Even in beginner projects, it is rather common to do something like software debouncing for pushbuttons or multiplexing for led matrices, both of which require millisecond resolution timing precision. A garbage collector pause in the middle of it would ruin everything. And a noob wouldn't understand why. Also, isn't JavaScript already running on the new ARM Cortex M3 -based Arduino board? To say something positive, I think the Google Blockly visual programming language is a very good idea for something like this, especially if targeted at noobs and/or kids. If you're unfamiliar with it, the picture with the puzzle pieces tells it all. There are puzzle pieces of different shapes for different syntactic structures (you can see expression and statement pieces), and the colors of the pieces are different types (in the picture, green is a boolean, I think).

outside1234 13y ago
Most JavaScript runtimes no longer interpret JavaScript. It is compiled to bitcode and some subsets(see asm.js) can run within reach of native code.
- exDM69 13y ago
  > Most JavaScript runtimes no longer interpret JavaScript. Yes, JavaScript implementations have been more or less JIT-compiler based for quite some time now. But they are still quite far behind in performance and this does not address the real time requirements at all (in fact, it makes it worse). There's also a significant memory hit from having the JIT compiler around. Asm.js is cool because it can be compiled to native code ahead of time (addresses the performance gap at the expense of startup time), but this project isn't talking about Asm.js at all. It's about running human-written JavaScript as opposed to Asm.js which is intended to be emitted by compilers.
  - dubcanada 13y ago
    I would personally have preferred Lua via eLua or LuaJIT over Javascript. And I don't know where he got his stat about "Most JavaScript runtimes no longer interpret JavaScript". And I don't see a single thing backing that up.
  - oso2k 13y ago
    This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast. Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system. Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms." A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities. Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure). Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4]. [1] http://en.wikipedia.org/wiki/External_Data_Representation http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts https://developers.google.com/v8/embed#contexts [4]This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast. Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system. Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms." A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities. Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native code for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure). Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4]. [1] http://en.wikipedia.org/wiki/External_Data_Representation http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts https://developers.google.com/v8/embed#contexts [4]https://code.google.com/p/tiny-js/ https://code.google.com/p/tiny-js/
hershel 13y ago
some of the JavaScript engines, most notably MicroSoft's JavaScript Engine, use reference counting for determining when memory can be freed.[1]. Some implementations of reference counting work well in hard real time systems[2]. So it's too early to tell if espruino would fit real time systems. And regarding wasted cycles: for this project, it doesn't matter much. Unless you make stuff in volume ,micro controllers are cheap. [1]http://www.fasterj.com/articles/javascript.shtml http://www.fasterj.com/articles/javascript.shtml [2]http://liu.diva-portal.org/smash/record.jsf?pid=diva2:20899 http://liu.diva-portal.org/smash/record.jsf?pid=diva2:20899
- exDM69 13y ago
  > some of the JavaScript engines, most notably MicroSoft's JavaScript Engine, use reference counting for determining when memory can be freed.[1] Interesting, I was unaware of this. How does Microsoft's JavaScript engine deal with cyclic data structures, which reference counting can't deal with? The best I understood from your link is that it just leaks cyclic structures? Does the JS spec really allow this? > So it's too early to tell if espruino would fit real time systems. It's too early to tell but IMO it's a critical aspect of microcontrollers. Many if not most microcontroller applications have some degree of real time requirements, which limits your choices for software runtime systems.
  - hershel 13y ago
    I don't know how MS does solve the cycle problem. Many data structures don't have cycles. I believe it's pretty true for many embedded systems.
- gfwilliams 13y ago
  Espruino does use reference counting, and currently falls back to proper Garbage Collection if available memory gets filled with cyclic datastructures. Responding to IO is handled and timestamped using interrupts, so if you write your code such that you use the timestamp, you can actually do some very accurate timing. One other good point is (strangely) power usage. As there's an interpreter, it can very easily detect when it isn't doing anything and can go into low power sleep modes - it's something that you can do with another MCU and a lot of effort, but that you get for free with Espruino. There are things it's good for and things it isn't - but for the majority of projects people do with Arduino I think it really does provide value.

by exDM69 13y ago

outside1234 13y ago

Most JavaScript runtimes no longer interpret JavaScript. It is compiled to bitcode and some subsets(see asm.js) can run within reach of native code.

exDM69 13y ago
> Most JavaScript runtimes no longer interpret JavaScript. Yes, JavaScript implementations have been more or less JIT-compiler based for quite some time now. But they are still quite far behind in performance and this does not address the real time requirements at all (in fact, it makes it worse). There's also a significant memory hit from having the JIT compiler around. Asm.js is cool because it can be compiled to native code ahead of time (addresses the performance gap at the expense of startup time), but this project isn't talking about Asm.js at all. It's about running human-written JavaScript as opposed to Asm.js which is intended to be emitted by compilers.
- dubcanada 13y ago
  I would personally have preferred Lua via eLua or LuaJIT over Javascript. And I don't know where he got his stat about "Most JavaScript runtimes no longer interpret JavaScript". And I don't see a single thing backing that up.
- oso2k 13y ago
  This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast. Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system. Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms." A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities. Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure). Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4]. [1] http://en.wikipedia.org/wiki/External_Data_Representation http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts https://developers.google.com/v8/embed#contexts [4]This post and its parent make a lot of bad assumptions. For one, performance is not the same thing as real-time nor is performance the same thing as fast. Real-time means that a given system has verifiable (and often guaranteed) run time qualities. Time being the keyword. Saying "System X's slowest operation completes in 500ms" is a definition of a real-time system. Performance is a system's ability to complete a certain task in a certain amount of time. "System X can toggle an I/O pin in 10ms." A good analogy is the comparison of a high-end sports car (Porsche 911) and a Big Rig. Unloaded, the sports car can travel 140MPH (fast!), while the Big Rig can travel 75MPH. Fully loaded, the Porsche can carry 800 lbs and travel at 90MPH, while the Big Rig can carry 12,000 lbs and travel at 75MPH. If you system's goal is to move 12,000 lbs of cargo 75 miles, the Big Rig would have higher performance and better real-time qualities (more cargo transferred per hour and a consistent time of 1 hours) while the Porsche would have poorer performance and real-time qualities. Secondly, asm.js is not compiled to native code ahead-of-time (yet). No compiler (that I'm aware of) generates native code for a JavaScript input. SpiderMonkey previously supported XDR[1], Rhino supports compiling to Java class files for most JS[2], and Google V8 supports compiling to "snapshots"[3] (a sort of pre-parsed, semi-compiled form, with the heap linked into the data structure). Thirdly, Espruino is written by Gordon Williams and based on the things he learned while developing Tiny-JS[4]. [1] http://en.wikipedia.org/wiki/External_Data_Representation http://en.wikipedia.org/wiki/External_Data_Representation [2]http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 http://en.wikipedia.org/wiki/Rhino_%28JavaScript_engine%29 [3]https://developers.google.com/v8/embed#contexts https://developers.google.com/v8/embed#contexts [4]https://code.google.com/p/tiny-js/ https://code.google.com/p/tiny-js/

hershel 13y ago

some of the JavaScript engines, most notably MicroSoft's JavaScript Engine, use reference counting for determining when memory can be freed.[1]. Some implementations of reference counting work well in hard real time systems[2]. So it's too early to tell if espruino would fit real time systems. And regarding wasted cycles: for this project, it doesn't matter much. Unless you make stuff in volume ,micro controllers are cheap. [1]http://www.fasterj.com/articles/javascript.shtml http://www.fasterj.com/articles/javascript.shtml [2]http://liu.diva-portal.org/smash/record.jsf?pid=diva2:20899 http://liu.diva-portal.org/smash/record.jsf?pid=diva2:20899

exDM69 13y ago
> some of the JavaScript engines, most notably MicroSoft's JavaScript Engine, use reference counting for determining when memory can be freed.[1] Interesting, I was unaware of this. How does Microsoft's JavaScript engine deal with cyclic data structures, which reference counting can't deal with? The best I understood from your link is that it just leaks cyclic structures? Does the JS spec really allow this? > So it's too early to tell if espruino would fit real time systems. It's too early to tell but IMO it's a critical aspect of microcontrollers. Many if not most microcontroller applications have some degree of real time requirements, which limits your choices for software runtime systems.
- hershel 13y ago
  I don't know how MS does solve the cycle problem. Many data structures don't have cycles. I believe it's pretty true for many embedded systems.
gfwilliams 13y ago
Espruino does use reference counting, and currently falls back to proper Garbage Collection if available memory gets filled with cyclic datastructures. Responding to IO is handled and timestamped using interrupts, so if you write your code such that you use the timestamp, you can actually do some very accurate timing. One other good point is (strangely) power usage. As there's an interpreter, it can very easily detect when it isn't doing anything and can go into low power sleep modes - it's something that you can do with another MCU and a lot of effort, but that you get for free with Espruino. There are things it's good for and things it isn't - but for the majority of projects people do with Arduino I think it really does provide value.