Thoughtophone

I've got a reasonably small date-time library working in Picobit. I started off with SRFI-19 , but found it's reference implementation used floating point numbers for Julian day, and used Julian day to calculate conversions between UTC and the Gregorian calendar. Trying to figure out if I could change this to integer arithmetic didn't seem that easy. Instead, I found a ground up integer method in Joda-time, and used that instead. It's calculation is incredibly easy to understand, once you get over the fact that it's pulled to pieces into several subclasses and helpers, to the extent that you wonder why everyone doesn't do it the same way. I got to simplify it even more, because Picobit gives you more latitude with arbitrary precision. The result is fairly like SRFI-19 but ignores leap seconds, and therefore the distinction between TAI and UTC , replacing them with time-real. This makes all the more sense given that most microcontroller projects will probably

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

A college pointed out Picolisp  because of my work on Picobit. The paper  mentions Picobit and discounts it because a foreign function interface would be difficult to implement. This isn't exactly true: I've been linking Picobit programs into ARM executables, and that certainly means I could link actual function addresses should I want to: I could generate C code containing a vector of the foreign function references, and link this into the resulting program. Once I have done this, I can define a foreign function primitive that uses the vector to call them. This will certainly be some work, but not as much work as writing Picolisp! That isn't what I'm currently planning to do, however. I plan to copy Unix and define a limited set of operations for IO, define device numbers and route these calls to an appropriate driver according to the device number. One of the calls will be ioctl, which will allow arbitrary scheme data structures. I could use python's approac