Installing OBC release 3.1
Release 3.1 provides a native JIT for the amd64 architecture.
There is an alpha release: https://Bitbucket.org/Spivey/obc/downloads/obc-3.1alpha-amd64.deb. Though it passes all the usual acceptance tests, there may still be places where the JIT encounters unimplemented operations at runtime.
To install the release, copy the above file to your machine, then issue the command,
$ sudo dpkg -i obc_3.1alpha_amd64.deb
Doing this may produce a message about unmet dependencies, and you can resolve them with the command
$ sudo apt-get -f install
Like most compilers on amd64, OBC implements the INTEGER type with 32 bits, and there is a LONGINT type that provides 64 bits, with arithmetic implemented using machine instrictions on amd64. Pointers continue to occupy 32 bits on amd64, because the runtime system takes care to request memory in the lowest 4GB of the address space. This means that the amd64 implementation of OBC is compatible at the bytecode level with implementations on 32 bit machines, and Oberon programs do not need to be recompiled when they are moved from one architecture to the other.
The JIT makes use of an additional 4 registers, R8 to R11, in addition to the 8 registers used on i386. The remaining registers, R12 to R15, are callee-save, so they incur the cost of pushing them on entry and popping them on exit, without any guarantee that using them will result in code that is, practically speaking, any better than it would be without them.
On 32-bit x86 systems, there is little difference between releases 3.0 and 3.1.
Version 3.1 on the Pi is virtually identical to version 3.0, except that a few internal interfaces have been adjusted to allow the possibility of working on amd64, usually with no performance penalty on 32-bit systems. There's no need to upgrade.
Windows and Mac
I'm not planning to supply a 64-bit build for Windows or Mac, since both of these platforms appear to continue supporting 32-bit applications well.
- The usual advantage of a 64-bit userland – the larger register set – doesn't really apply to OBC, because the simple JIT translator doesn't generate enough demand for registers to take advantage of it. Evidence for this is that, though spills of registers to memory are implemented, they are very rare even on x86.
- Making a port to Windows or Mac depends on two things: devising a means to allocate storage in the bottom 4GB of the address space, analogous to
MAP_32BITSflag on Linux; and verifying that the calling convention used (by Mac GCC or by GCC under Cygwin) is the same as on Linux/amd64, or adjusting it to suit.