Picobit native endian

If I'd been paying attention, I'd have noticed that Picobit's memory access primitives emulate big-endian byte ordering. This sort of makes sense in the case of constants and the byte code: It makes picobit's images portable. I'm not actually interested in this, however: I build binaries for specific platforms. Even if I was, it's preferable not to do this for RAM.

After a bit of hacking and debugging I've made RAM access native endian. Actually I've only tested it on little endian systems: X64 and ARM in little endian mode (which is the default for Chibios). I have a very limited performance test: 11 queens. The difference this makes varies depending on the optimisation settings. Picobit suggests -Os. I've also tried -O2. These are the results for amd64:




 -O2

-Os



Size Time Size Time
Native-endian 53040 3.119 49864 6.340
Big-endian 56848 3.733 50192 7.908


-3800 -16% -328 -19%

You get a lot of bang for your buck with -02 vs -Os. I guess the main thing here is that code size differs much less between -O2  and -Os using native endian. There's a big performance benefit. It does seem like if I converted ROM access to native endian, the code size difference between -Os and -O2 might almost disappear.

I think this is just because -O2 in-lines the memory access primitives, and for big-endian emulation, each of those in-lines are bigger.

I haven't got a sensible way of timing this on a micro controller yet, but this result is enough to merge this, and continue on to add an endian-ness flag to the compiler so I can switch constant access to use native endian-ness, because this should further shrink the executable, even if it doesn't have much effect on performance. I don't think there's any point changing the bytecode though: not many instructions include full word values.

Popular posts from this blog

3D Printer ramblings

 I have a Prusa i3 mk2.5 in storage. I used to use it in my shed I used not to worry about it's harmful emissions: I just didn't share the space with it. I had, however, added an enclosure, and was planning to add a HEPA filter too it. Once it's in an enclosure, it's massive. Even if I had added the filter, there's no where to put it. I'd like a small printer that has an enclosure or is easy to enclose. I figure I could get by with 150x150x150 build area: I was rarely patient enough to wait for my i3 to print bigger models. 200x200x200 would probably actually replace my current printer, so that would be a bonus. Not many printers have HEPA filters, which is really a shame. It seems just to be the result of a misconception about HEPA filters, and about filtration in general. Read this . E.g. I was looking at a used Lulzbot mini, and there are ready made enclosure s for it, however . In this particular case, it's no big deal: opportunities to buy a Lulzbot min
Read more

Balance Bot V2

Image
My current balance bot sort of works, but it's surprising it does: it's centre of gravity is actually only about 60mm above the motor axis. The whole thing ways 320g. The 6 AAA batteries only weigh 70g, so despite being right at the top, the don't affect the centre of gravity much. 6 AA batteries would weigh about 180g. That would add a 34% to the overall weight, and move the centre of gravity much higher. Seems like a dramatic increase in weight: it would be nice to be a bit more incremental. More AAA batteries isn't really worth considering: they only weight 12g, vs 30g for an AA. 4 AA would deliver much less power/torque, so that's no good. There's no middle ground, in other words. I'm also going to make the whole thing a bit taller: I need more space to add more sensors in any case. Last time I made the frame, I needed an elaborate jig to get it square and it actually didn't work that well. This time, I decided to use some short bits of a
Read more

Robot arm

Image
I 3d printed this robot arm I original found on Thingiverse, but the Instructable is recommended. There's a MK2, and also a delta style arm, both of which look like good alternatives, but this will do for now. Here's a video of it moving: I've attached it to an STM32F4 Nucleo board, via a prototype shield: In the video, I'm sending commands from a python script that runs on my desktop, communicating via USB serial. I've written an implementation of canonical s-expressions in c++ that doesn't require memory allocation, as well as a python version to talk to it. It's the main reason I haven't posted for so long, and of course overkill for just controlling some servos, but should prove more generally useful. Here's the code . It uses platformio for the build, and mbed rtos.
Read more