Inferno is a portable environment, encompassing operating system, languages, virtual machine and the tools required to build it. This section briefly summarises the state of the ports and compilers included in this release. Directory names are relative to the root of the Inferno release tree, unless otherwise specified by the context.
All components are built using the program mk, based on `make'-like recipes found in the mkfile in each source directory throughout the Inferno tree. Mk is described by the manual page mk(10.1) in Volume 1; a more tutorial discussion, including a summary of differences with Unix make, can be found in Maintaining Files on Plan 9 with Mk by Hume and Flandrena, reprinted in this volume. The source for mk itself is included in utils/mk. (It must be compiled manually on the initial port to a new host environment.)
An unusual property of the compiler suites used to compile native Inferno is that there is no difference in configuration or content between a `compiler' (compiling on the same system and processor type as the target) and a `cross compiler' (compiling on a host that differs from the target), even when the host operating systems are quite different. Indeed, in their ancestral home, Plan 9, it is the default action to compile instances of all compilers for all possible target architectures, as a matter of course.
The main difference between this suite and the original Plan 9 suite is that all Plan 9 C extensions have been eliminated from the compiler's own source, allowing it to be compiled on environments that accurately support ANSI C and a few necessary Posix functions.
The source for the compilers is found in subdirectories of utils. The compilers are named as follows:
With the exception of the 68000 compiler, all the compilers have been used extensively to compile Inferno, and most have been used to compile Plan 9 and all its applications; and we have found them solid. The 68000 compiler was used to attempt a port of Inferno to the Motorola Dragonball (in the Palm Pilot). It is included here in case someone wishes to have another go. We have no experience with it.
The ARM compiler does not support the Thumb instruction set; it has been used to generate code for the StrongARM SA110 and SA1100 processors (the primary targets for native Inferno for many years). The code generated was greatly improved by Richard Miller. The floating-point support is adequate for C programs: the compiler generates ARM floating-point instructions, as implemented on the ARM7500 but not on the Strongarm, where they must be emulated.
The PowerPC compiler supports the 32-bit PowerPC architecture only; it does not support either the 64-bit extensions or the POWER compatibility instructions. It has been used for production operating system work on the 603, 603e, 821, 823, and 860. On the 8xx floating-point instructions must be emulated. Instruction scheduling is not implemented; otherwise the code generated is similar to that for the other load-store architectures. The compiler makes little or no use of unusual PowerPC features such as the counter register, several condition code registers, and multiply-accumulate instructions, but they are sometimes used by assembly language routines in the libraries.
Dis object files are portable across all variants of Inferno, hosted and native. There need be only one copy of the Dis files to serve many different versions of Inferno; they need not be rebuilt for each platform and can be shared by different types of host. Limbo insulates the programmer from all details of the particular processor, including byte-ordering, and consequently the applications themselves are portable.
The source for the applications is found in subdirectories of appl: appl/cmd holds the source for most command line applications (that use no graphics); appl/wm contains the source for most applications that run under wm(1); appl/svc contains the source for various system services and file servers; appl/mux, the source for the interactive television demo mux(1); appl/charon, the source for the Charon web browser; and appl/acme the source for Acme written in Limbo.
The mkfile in each directory can currently only be used by an instance of mk running outside the Inferno environment, under the host operating system. This complicates its use with acme(1), normally requiring the use of the os(1) command. In some cases, but not all, there is a mashfile that can be used by mask-make(1) to build a Limbo application from within Inferno (native or hosted). A consistent approach to building applications both inside and outside Inferno is being developed. In any case, the resulting Dis files are portable once produced.
There are currently three main variants of hosted Inferno: Plan 9, Unix and Windows. The source is held in emu, but like the native kernels it relies on several auxiliary libraries (the source of which it shares with the native kernels). Emu itself is built by the mkfile in the emu directory, but each library has its own mkfile; the various components are made in the right order by the mkfile at the root of the Inferno tree.
The Unix emu variant generally is covered by `POSIX' (with common extensions) but each Unix port has one file that differs considerably for each port, namely os-os.c, the differences corresponding to the different ways under Unix of implementing kernel-scheduled threads efficiently.
There are working emu versions for FreeBSD/386, Linux/386, Plan 9, Solaris/sparc, and Windows (9x, NT and 2000). The Plan 9, Windows and Solaris versions have been used more intensively than the others. The FreeBSD port is the most recent and could use more work, in particular it will probably be more efficient to replace the use of POSIX threads by FreeBSD's Plan9-like rfork. Meanwhile, it serves as a useful example of a working hosted port that uses POSIX threads. The remainder all use mechanisms specific to the host operating system; see kproc in emu/os-*.c.
Source is included for ports to HP/UX (S800 architecture), SGI Irix 5.3, Solaris/386, and Unixware, in case someone wishes to take them up now, but we have not yet investigated their fitness.
The Plan 9 hosted implementation is unusual in that it supports several processor types: 386, mips, powerpc and sparc. Furthermore, all versions of emu can be built on any processor type, in the usual way for Plan 9.
Otherwise, as distributed, emu for a platform can only be built when running on that platform.
As with the different versions of emu, once the native kernel is running, all applications work straight away; the same applications are used in native and emulated mode, subject to suitable devices being available. Because the portable compiler suite is used to compile native kernels, and those compilers are automatically cross-compilers, all native Inferno implementations can be built on any host platform. Furthermore, the build procedures and resulting object files are the same.
Early ports in 1996 were made by Bell Labs to an internal device based on the AMD 29000, an early ARM-based `network computer', and Intel-based PCs. Between 1997 and 1999, Lucent concentrated mainly on the Strongarm platform (SA1100), for various Digital/Intel development boards, and especially several `web phones', including the Sword Webphone Reference Design. It also undertook ports to other devices for experiment, or under contract.
Vita Nuova Limited also ported the system, both for its own purposes and under contract to Lucent. Targets included a small 386-based Internet device, a set top Internet box using the PowerPC 603e, a digital television set top box with a Strongarm SA110 and a Teralogic TL750 graphics chip, the USR/3Com Edgeserver (in a chassis containing various types of line card), various boards based on the PowerPC 823/821/860, many different configurations of IBM PC, and a Ziatech Pentium-based VME crate.
Distribution of most previous and existing ports is restricted by the terms on which they were undertaken, or because they were ports of older Inferno releases and not kept up to date. We have included the following as examples in this distribution.
The source for the StrongARM kernels is os/sa1100. The Webphone ports are tied to hardware that is not generally obtainable (for instance, the Sword Reference Design is no longer sold). Furthermore, the ports to those platforms included some software (notably modem software) that cannot generally be distributed. The components included here are therefore only those for a port to the Digital (now Intel) `Brutus' development board. That too might be unobtainable, but provides a less peculiar model than the others for ports to other StrongARM hardware. Those that have got Sword boards are welcome to write to support@vitanuova.com to ask about obtaining a copy of the code for that. The Brutus code does include the touch panel and flash drivers.
The bootstrap for the SA1100 is built in os/boot/sa1100 but uses code from os/boot/net, os/boot/port and os/boot/styxmon.
The directory os/mpc contains the port of Inferno to the MPC8xx FADS development board. It has been used with the MPC821, MPC823 and MPC860 processors. The interface to the CPM is provided by cpm.c. There are drivers for the real time clock, flash devices (including a Flash Translation Layer driver), and communications controllers in Ethernet, UART, and IrDA mode (see etherscc.c and devuart.c). The IrDA has been used for Styx transport between a FADS board and an IBM Thinkpad 560. The file screen.c drives an 8-bit per pixel LCD (TFT) display panel. A sample interface to the on-chip video device of the MPC823 (only) as wired on the FADS board using auxiliary chips can be found in devvid.c. The York Electronics Centre developed a touch panel for us, connected using SPI; the driver is devtouch.c, and could be adapted for similar devices.
The bootstrap program is in os/boot/mpc, loosely derived from an older version of os/boot/pc. It is initially converted to S records that are loaded into flash by MPC8BUG from a PC, and thereafter the images of the boot and kernel images can be updated using the flash devices provided by the system itself, and the utility programs qconfig.b and qflash.b in appl/cmd/mpc.
The os/pc directory contains the components for ports to 386, 486 and Pentium class machines. The main difficulty is device support: in particular only a limited set of Ethernet and graphics cards is supported. We have used mainly the 3Com and Intel 82557 drivers. A `generic' PC port is included that has a graphics driver that should run on systems that provide a VESA BIOS mode.
We have a (slow) floating-point emulator for the 386 that is available on request.
The source for the PC bootstrap program l.com is in os/boot/pc. It is derived from a mid-life version of the Plan 9 PC bootstrap program b.com, with the addition of a small configuration file that lists the device drivers to link into it (see the file pc for instance).
The directory os/js has the first port to the Sun Javastation 1. It was done by Tad Hunt and Eric Van Hensbergen in a matter of days to demonstrate Inferno at Java One in 1997. It boots over the net using TFTP. Javastations being a bit thin on the ground now, it is unlikely to be directly usable unless you can find one second hand (you might find a Javastation 2 coffee pot, but that is slightly different again). That is a pity, because the machine was quite usable running Inferno and Limbo applications, often surprising those used to the Java-based offering on the same platform. It is included as an example of a micro-SPARC port.
The utils directory also contains ANSI C versions of other components of the Plan 9 development suite, such as nm, ksize, ar, and of course the acid debugger. Most rely on libmach, a suite of functions forming a library to handle the various object and executable files in one place.
Some other utilities give a portable way to express some of the kernel build scripts: sed, test, rm, and mkdir. On Plan 9, mk and kernel build scripts use Plan 9's own shell, rc. On Unix systems, they use sh. On Windows, a version of Plan 9's rc has been ported to reduce the number of variations to two, and keep the system self-contained; its source is in utils/rc.