Espruino 32 bit int switch

Hi,

I've just committed some code that swaps Espruino's internal number representation to 32 bit ints - it makes Espruino behave more like standard JavaScript, as well as managing to speed it up a bit and reduce flash usage. Hopefully eventually it'll help to make Espruino even more memory efficient too.

This is quite a big change, so before I roll out 1v65 with it in it'd be great if some of you could help to test it... There are a few other tweaks and fixes too:

http://www.espruino.com/binaries/git/com­mits/fa0350695317506ea36b312bdb6db1d23ae­fb093 ... and the ChangeLog

To use it, click on the link above, then right-click on the file called espruino_1v65_espruino_1r3.bin and click Copy link address. Open the Web IDE, click Settings, then Flasher, then paste the link into the text box and click Advanced Flash Firmware.

Thanks!

Woot! Cool stuff!

And we get exceptions now too? Wonderful!

I'll try this out tonight or tomorrow.

Yes! I don't promise that exceptions will work perfectly right now, but it's better than nothing... I've still got a bit of work to do to switch all the existing errors over to throw catchable exceptions though...

Fantastic progress Gordon!

Just tested with some of my moduls. Everything works fine.
Try.... Catch is a big step forward.
Could you name some places where it should work already ?

Just updated mine. Its only running a simple thermistor temp sensor with a PCD8544 to display the temperature but it appears to still be running okay.

That's looking promising then!

@JumJum try..catch should work ok anywhere you want to try it.

However the console won't tell you if there's an uncaught exception, and the Espruino functions (eg. SPI stuff) don't produce catchable exceptions.

I've just made a few more changes. There were some regressions to do with setInterval (and keeping time in general) but I believe I've fixed those now, and I also managed to get a few small speed improvements.

There's also (finally) an Array.reverse (which works on ArrayBuffers too).

Latest at: http://www.espruino.com/binaries/git/com­mits/29adf8a0a5c494b581d6fcbf7ae299a66e5­ebf54/

Definitively a good step to have 32-bit compatibility. Easy to trip over it when you start with the "easy Javascript-based microcontroller" and to get demotivated if you just want to use a lib that then just won't do the right bitshifts. Not always to easy to make complex library calculations 32bit-compatible by hand without missing one piece or another.

I had the problem with that md5 lib early on and fixed with some hacks but I could imagine beginners getting hit harder by a similar obstacle.

So. Cool.

Best
-Stev

BTW: I found a problem with chained bit shifts and minification back then. Only one of x minifyers would create the bracketed code that Espruino would need to work. Don't know if you changed something there, too (since 1v58). I could look it up, if it's of any use.

@Stev, if you could find out some code that gave the problem it'd be really handy. It's possible that the operator precedence is a bit off, so it groups unbracketed stuff the wrong way.

@Gordon, I think it was a >>> followed by a << without bracketing that was problematic. Maybe typing some example using those might already show the problem.

I'll see if I can find the correct line and the minification (which might had a problem with it itself). Won't be able to look it up today, though, as I am away from my Espruino gear... (Edit: Now that a local make on OS X is so straight forward, lack of HW is not that much of a problem as ./espruino is quickly built...)

@Gordon

>(7 >>> 2) << 1    
=2
>7 >>> 2 << 1  
ERROR: Got << expected EOF at line 1 col 8
7 >>> 2 << 1
        ^
>

Works fine in node ;) So, for lib compatibility...

Cheers
-Stev

Great! Thanks for the info. I'll see what I can do to fix it

I still haven't had a chance to play with this, but I will have such a chance this weekend. The changelog keeps getting more and more exciting.

BTW this change (in latest github builds, not the one linked above):
Increase event buffer size to 128 (from 64)

will break my DHT11/22 modules, I think. I'm going to be using the DHTs with the Espruino this weekend - my father found our real humidity measuring tool (a self-contained wet-bulb dry-bulb setup), so we're going to be comparing the DHT's to that, to see just how accurate or inaccurate they are.

As part of that project, I'll update the DHT modules to work with this change - which should make it possible to use the checksum that the DHT's return. Maybe with the full 40 bits to look at, it will even become obvious why the DHT11's don't seem to report sane numbers for humidity.

That's be great - thanks! I'll only publish the new modules when I put out the updated firmware, so it won't matter if any changes cause problems. I actually just tested and it seems that on the DHT11 the humidity isn't reported now - but temperature still seems to work.

I'm afraid that my build/test PC has just broken (I think it got fed up doing so many builds!) so you won't get updated images in http://www.espruino.com/binaries/git until I fix it, and you'll have to build your own.

Ah, so it's not returning humidity at all, instead of returning wrong numbers like before? Interesting.

With your build system down, are updated changelogs still being posted under http://www.espruino.com/binaries/git/... or do I need to check the changelog in the repo?

Check the repo. However I think I've just fixed the build system - if the hash shown on the Espruino site matches github then you're sorted.

Just checked and the build system is still broken. Sorry about that...

Not yet tested

http://drazzy.com/espruino/espruino_1v65­_6-21_espruino_1r3_bigram.bin

http://drazzy.com/espruino/espruino_1v65­_6-21_espruino_1r3_bigram_wiznet.bin

Tested - the firmwares I posted above work (note - these also use the extra ram and flash, so you have 2600 jsvars. That's not related to any of the changes in v65)

Fixing the DHT module is tricky!

Before, I used an integer to store the data received, and since I had 64 bit ints and 32 bits of data, that was all fine and dandy. But now I have only 32 bit ints - which would still be okay, except that now I'm getting all 40 bits!

I can't do the bitshift to store each bit like I did before at all can I? Hmmm....

@Gordon: Will we get a standard 64-bit int/uint in addition to the standard type? Handy these days. Not that you hadn't enough cool features to fill the remaining ROM, just asking.

Or should we do our own classes, a module, is there anything to use?

Nite
Stev

@DrAzzy, you're probably best off using a Uint8Array and wasting 7 out of the 8 bits.

@Stev, not at the moment I'm afraid. It could be an idea though. Someone could make a module based on Java's BigInteger class that used Uint32Array for the data. It should be relatively speedy for simple operations.

I'd wanted to make a UintNArray class that would use arbitrarily-sized integers - for instance I know 1 bit, 4 bit, and 24 bit would be handy. A Uint64Array wouldn't be much use because there'd be no way to get data in or out of it though :(

@DrAzzy - thanks for doing the builds too! I'll try and get my system sorted today.

Just a thought, but for storing the data, what about:

var bits = [0,0];
if (bit_is_set)
 bits[bit_number>>5] |= 1<<(bit_number&5);

It should be relatively efficient. It's just slightly harder to get the data out at the other end if it crosses the boundary between two ints.

Ok, builds should be back up now - just no benchmarking for now as the benchmark board seems to be objecting to having been re-flashed 1000s of times :)

Updated DHT modules and submitted pull request.