"compiled" js - what's the current state of this?

Posted on
  • Is there a page listing what does and doesn't work with compiled js?

    I know that method calls aren't supported, but loops and if/then are, but right now the specifics are scattered among a bunch of threads. I'm wondering if there's a page that

    I've been making another push on the 433 mhz communication with those cheap modules, and this is going to inevitably bring me back to receiving on an Espruino.

    Also, what is the current situation w/regards to using compiled JS for IRQ?

    This is the function that I was using as the watch before, and which I was hoping could be made faster, as an example of what I'd like to compile.

    
    function sigOff(e) {
      var d=e.time-e.lastTime;
      if (d>0.0005 && d<0.0013) n+=d>0.0008?1:0;
      else{
        n="";
      }
      if (n.length==z)  parseRx(n);
    }
    
    
  • Well, there's http://www.espruino.com/Compilation - I guess I should add a section to that for what's supported - actually I've just done this on GitHub : https://github.com/espruino/EspruinoDocsĀ­/blob/master/info/Compilation.md

    Feel free to issue pull requests there if you find something else or have other things to add.

    On the whole it's approaching usability, even with the currently published (non-GitHub) WebIDE and firmware.

    Having said that I just tried your code and == is missing - doh! I'll quickly fix that though.

  • So it sounds like it's not quiite usable, yet, based on that list?

    I think the critical ones are &&, ||, ==, and ++/+=

    Also, are >> and << supported?

  • Well, shifts aren't, but could be quite easily. ++ and += work.

    But yes, trying that code I'm hitting loads of issues. So I guess it's not usable quite yet :)

  • Right, I give up for the day - it's still not going.

    It's really surprising what works though - like the Mandelbrot calculations. There are just a few bits that aren't in there yet.

  • Just a quick update on this - I'm not convinced this is the way forward.

    It's hard work, and extremely difficult to debug and test. After all that, while it'll be a lot faster than normal Espruino code it's not going to be speed or size optimised without a lot of work.

    I'm experimenting with something different - running a service on Espruino.com that will take the JavaScript code, translate it to C++, run it through GCC, and send back the result.

    It's a lot simpler, and it should result in much faster code. Hopefully there will be some updates soon.

  • Clever! Sounds like this is something I could run on my own machine if I want to do things from the terminal, right?

  • Yes - although it's going to be just as painful (probably more painful!) than the toolchain you need to build the Espruino firmware...

  • Sad to hear that the compiled JS isn't going smoothly. Good luck on the C front.

    The toolchain to compile the Espruino firmware is not painful at all, though (I barely swore at all while setting it up) - so I think almost anything would be more painful to set up ;-)

  • :) To be fair to it, with a few bugs fixed the all-JS compiler would be pretty usable - it's just that there turns out to be quite a lot of complexity involved in producing Thumb instructions, and I'm very conscious that it's all work that's already been done by GCC - and has been done better :)

    By removing that complexity, I can focus on working out when variables are integers - which means the compiled Espruino code can suddenly get really fast.

    Also it's a very long way towards compiling C code straight into a dynaimcally loadable module, which is something I'd also really like to see. When I get some time I'll try and make a script for it.

  • Ok, new compiler online now.

    It still needs a bit of work (for some unknown reason function parameters don't seem to be handled right, despite the generated code looking fine).

    I've had to include two 'fake' parameters at the front, but the following does work though:

    function f(x,xx,e) {
      "compiled";
      var d=e.time-e.lastTime;
      if (d>0.0005 && d<0.0013) n+=d>0.0008?1:0;
      else{
        n="";
      }
      if (n.length==10) print(n);
    }
    
    n="";
    f(0,0,{"time":0.0006, "lastTime":0});
    f(0,0,{"time":0.001, "lastTime":0});
    f(0,0,{"time":0.0006, "lastTime":0});
    f(0,0,{"time":0.001, "lastTime":0});
    f(0,0,{"time":0.0006, "lastTime":0});
    f(0,0,{"time":0.001, "lastTime":0});
    f(0,0,{"time":0.0006, "lastTime":0});
    f(0,0,{"time":0.001, "lastTime":0});
    f(0,0,{"time":0.0006, "lastTime":0});
    f(0,0,{"time":0.001, "lastTime":0});
    // prints 0101010101
    

    So there is some hope for your radio receiver :)

    If anyone is interested in diving in the source code is here. It should be significantly easier to work on and debug now - the C++ it generates is much more readable than Thumb assembly!

  • I'm taking another look at 433mhz RF - do I still need fake parameters at the front to make it work, or has that been sorted out now?

  • Noticed the root post just now that asks about how to make things faster 'beyond what compiled can do'...

    I understant that it is a bit late in the life cycle of the event object, but I'd like still to know how came the decision to store the lasttime in it vs the time ago value (e.time-e.lastTime). Most of the time - and especially in this one - the ago is of interest... and if lasttime is needed, it can be derived.

    May be it is a mute (muet) pong, since in a compiled mode the calculation is not a big deal...

    @DrAzzy, regarding a higher level of communication - detect the begin of a packet and wether the node address is a match - and especially to unburded the application MPU from that low level job, I 'm thinking a bit in a different direction:

    A 'large' shiftregister with some 'comparison logic' - a FPA or dedicated satellite mPU - triggering an IRQ - like a signal processor. Large means 4+ number of the bits involved and a the comparison logic is a fast, 'hardware' based, somehwat fuzzy comparator to detect a proper packet header - pre-amble with address and some CRC. The 'bit' - noise - is sampled and streamed through the device with 5+ the defined baud rate. Since the signal processor is so fast, is able to go for every fast cycle through all 5+ and consider it a hit or fail, and trigger the flag. The large array can then switch over for the reception of the package to be the fifo and give the host MPU enough time to respond to the IRQ. The 'modulation' or coding would be like a '5 com bit per 1 data bit' communiction, where the first one is always the start bit and more so - a pulse, and the 3rd and 4th bits define the actual data bit - the 2nd and 5th are always idle (an 1 data-bit is a 10100 singnal sequence and a 0 bit is a 10010 sequence). The baud rate for the payload goes down, but pattern is combnatin af asynchronous and synchronous and triggered, detection is state and transition based, and only 2 out of 32 make it to be a valid bit.

  • I already have a solution with a second MCU dedicated to this task (a 1634 with transmitter and receiver integrated on board), and I have espruino code to interface with it as well.

    I'm just interested in what is now possible to do WITH Espruino doing the transmitting and receiving, and whether I still need those dummy variables or not if I want to use compiled JS here.

  • I'm taking another look at 433mhz RF - do I still need fake parameters at the front to make it work, or has that been sorted out now?

    No, it works much better now. It even works with bind, which is pretty handy for even more speed.

    I actually added some code up yesterday for a workshop I did: http://www.espruino.com/433Mhz

    The module itself doesn't work well for receive as-is because the Web IDE doesn't compile code, but if you take the module code for rx and put it in the Web IDE, then uncomment "compiled", it works pretty well.

    The only gotcha (and there's no way to really test this at the moment short of running EspruinoCompiler yourself and checking the output) is that when Espruino has to deal with floats or variables it doesn't know the type of it's much slower, so you need to get it to work with ints whenever possible.

  • @Gordon that new module looks really good - nicely abstracted - much easier to use.

    I've been following this thread as I didn't know about the compiled statement and have been trying to optimise some 433Mhz code I've been working on - when you say does not work in the Web IDE, do you mean the Chrome IDE? Though I could still could not get my code to run properly, Espruino did appear to be responding in the terminal as if it was the compiler was working, and threw errors if I tried to use "compiled" in ways it said had not been implemented? I assumed it was doing its stuff just fine?

  • Oh yes, the compiler works fine.

    The problem is when you have "compiled" written in a module (like 433). At the moment the Web IDE doesn't handle that (it's more difficult, because with minified modules, "compiled" gets moved around!).

    Once you move the code out of the module into the Web IDE itself it works fine though

  • Got it, thanks!

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

"compiled" js - what's the current state of this?

Posted by Avatar for DrAzzy @DrAzzy

Actions