You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • The time will come when interpreting code in ROM has to be implemented

    eval(E.memoryArea(...)) works right now, as does E.setBootCode(...). I believe you can even hack in ROM-based function code with:

    function a() {
    };
    a["\xFFcod"] = E.memoryArea(...);
    

    But I don't get why you need to execute from ROM - the problems you're talking about with runtime RAM usage won't be fixed by that... Sure, you'll be able to handle more concurrent requests (or whatever you're doing) but at some point you'll still run out of RAM - not because of allocated program code, but because of data that needs to be allocated at runtime.

    Right now, in Espruino boards, ROM is more scarce than RAM. So much so that the contents of RAM actually has to be compressed before writing it into ROM. So despite the fact that Espruino can execute from ROM, there's very little point in doing so because you'd have to store your code uncompressed, so would actually get LESS available code space.

    When you have more than enough flash memory there's actually a branch of code here that will execute everything from ROM (using RAM as a cache), including variables that aren't modified. Sadly nobody else seems bothered to do anything with it and it's been basically ignored since I did it at the end of last year.

    With getters/setters - yes, potentially that could be added by adding a new variable type in Espruino. It's not high on my priority list though :)

About

Avatar for Gordon @Gordon started