> Incredibly useful advice, thank you. You're welcome Now, if I can just find some way to get up and running, I might be able to help implement that!
> You look at Espruino’s compiler, and it was clearly written in > a swashbuckling style: Thanks for the links. At this point though my C knowledge isn't sufficient to comment either way. However, I will share that I have a class of 3-6 graders (22 kids aged 8-11 years), who are all quite happily coding on the Espruino platform (actually a port of the Espruino platform to the ESP8266), without any problems. This is just a regular class of kids, only 2 are what I'd call geeks. (I'm a volunteer parent at the school). And, we're using real hardware, on breadboards, not plastic toy parts. I don't know of any other embedded platform capable of supporting that use case, or that abuse, do you? I mean, that's literally the ultimate newbie scenario - completely new to programming! So, personally, I'd look to Gordon's work as an good example of trade-offs that work, from an end-user perspective, just saying. i.e: if he's not doing it the way others are, and his way works, then it's probably worth pausing to consider, no? that's my gut feel, I could be wrong. Have you taken a look at the other JS engines: V7, KinomaJS, Duktape, Tiny-JS? > The other, being that you want to dynamically recompile Javascript on a > device over a WebSocket. But when that happens, I’ll know it’s time to > leave embedded for some other line of work. :-) Not sure how to read that comment because (and I hate to be the one to break this to you), that's how Webpack interacts with the chrome browser engine to provide hot-reloading, time-travel-debugging, and other functionality. i.e: to my previous comment, there is already a whole ecosystem of tools that will be able to operate with the other end of a websocket connection capable of consuming ES5 compliant js sourcecode! But note: you don't have to recompile (or even compile) the JS, you just need to be able to 'emit and consume ES5 compliant javascript', i.e: my point #1. And, importantly, there is no requirement for any byte-code at all, that's just one potential implementation, which ultimately depends on the trade-offs, no? I think Espruino actually offers 3 options: a) run-time source code parsing, b) transpilation to c, c) pre-compilation, I've only tried (a). Dave On Sat, May 28, 2016 at 12:16 PM, Sterling Hughes <[email protected]> wrote: >> >> >> Basically these ecosystems treat ES5 Javascript like the 'byte code' >> of the Java world!! >> (btw, Espruino team found that ES5 source code is more compact than >> the byte-code created by any Javascript engine, so there are >> surprising tradeoffs in memory constrained devices!). >> >> To play in that ecosystem, you basically need: >> >> 1) to emit and consume ES5 compliant Javascript. >> 2) implement perfect JSON parsing and stringification. >> 3) support http and websocket protocols. >> 4) support the CommonJS module standard which NodeJS uses. >> >> Optionally: >> 6) a babel plugin to support real-time transpilation to other js >> flavors (e.g. ES-6, or Typescript). >> 7) a webpack plugin to support 'hot redeploy', remote debugging, and >> other niceties of that platform. >> > > Incredibly useful advice, thank you. > > Btw, you mention Espruino, I think it’s a very interesting contrast between > Jerryscript. You look at Espruino’s compiler, and it was clearly written in > a swashbuckling style: > > https://github.com/espruino/Espruino/blob/master/src/jsparse.c > > With parsing and lexing going straight to three address code and even > executing while being parsed. While the coding style may not be ours, this > is a very efficient way to write things if you want to compile on the > device, and he’s clearly lived & breathed this stuff for 4 years. > > As opposed to Jerryscript, which has a standard two-stage compilation > process (parse tree->tac). They have also written a good compiler, and > clearly have experience. > > https://github.com/Samsung/jerryscript/tree/master/jerry-core/parser/js > > but it is not optimized to compile on these small environments. It’s VM > however, is very optimized: > > https://github.com/Samsung/jerryscript/tree/master/jerry-core/vm > > So, you could easily take this, and pre-compile just byte-code to run on the > device. While the byte-code might take more flash than ES5 source code, it > will certainly take drastically less RAM to run (precious.) > > I think the compiler that will win here will depend on what is the broadest > use-case. If you can afford to compile prior to running on the device, than > the Jerryscript compiler has the advantage of being simpler and more > complete. If you need to parse & run on the device (or you want to), then > the Espruino compiler is highly optimized for that. The only use-case I can > currently think of for such a thing is a Javascript console on the device, > but you could always compile that in for debug mode only with Jerryscript. > > The other, being that you want to dynamically recompile Javascript on a > device over a WebSocket. But when that happens, I’ll know it’s time to > leave embedded for some other line of work. :-) > > Sterling
