johnl@ima.UUCP (01/26/86)
To: info-ibmpc*usc-isib.arpa at CCA, net.micro.pc
--------
First, let me explain how I know about the RT PC. I used to work for
Interactive Systems until August 1984, and while I was there, I was the
software architect for the port of Unix to the RT PC. I don't work for
Interactive any longer and can't predict what will happen to the RT PC in
the future, but I did have a lot do with the design of AIX. The report
below is my own opinion and recollection, and not the formal position of
anyone including myself. So much for disclaimers.
Hardware
The RT PC uses the IBM ROMP chip, a more or less reduced instruction set
chip that has been in the works for a long time. It is a fully 32-bit
big-endian byte addressed machine. It is not particularly RISC-y in that
its register architecture is just like the 360's (16 general purpose
registers) and there are no interlocks that the software has to take into
account like the MIPS chip has. It does have branch-with-execute and the
only memory reference instructions are load and store and load-multiple
and store-multiple. Halfword and fullword operands are forcibly aligned
on natural boundaries by ignoring the low bit or two of the address.
This is a major performance win. Sorry, Vax and 80286 fans.
The address architecture is more interesting. All virtual addresses are
32 bits. The high order 4 bits of an address are a "segment register
number" and the low order 28 bits are the offset into the segment. The
4-bit segment register number is immediately looked up and translated into
a 12-bit segment number (the current hardware only supports 12-bit segment
numbers, but there's room in the architecture for 15.) The 12-bit segment
number plus 28-bit offset together determine a virtual address which is
translated by the segmentation hardware. The page tables are inverse
mapped in the manner of the System/38 or an Apollo -- there is a page
frame for every page of real memory and the logical page and segment
tables exist only in software. The page size is 2K and a segment can grow
either up or down. Segment registers 14 and 15 are reserved by the
hardware for I/O stuff, but the other 14 registers are available to
software. This scheme allows fast context switches because the real page
tables and TLB keep track of the 12-bit segment numbers; only the 16
segment registers need be changed for a context switch and no TLB flush is
needed. Up to 4K segments can be simultaneously defined, which is enough
for all of the processes under a typical AIX.
Floating point support is provided by a coprocessor board with the
National Semi floating point chip. If the coprocessor is not present,
floating point is simulated in software. If you're writing in assembler
it's up to you to address the coprocessor board (special addresses in
segment 15) and to call simulation routines if it's not present; higher
level languages such as C handle it for you automatically. Note that
unlike the 8087, the National chip supports only the most basic floating
point functions and NANs and gradual underflow are done in software in any
event. The National chip does do what it does very fast, so that floating
arithmetic that doesn't generate a lot of exceptions should run fast.
Software architecture
The RT PC has a three-level software architecture somewhat like that of
VM/370. At the lowest level is the Virtual Resource Manager, the VRM,
which provides a virtual machine with segmented virtual memory to the next
level. The second level is the Unix kernel, and the third level is Unix
user processes. The virtual machine provided by the VRM is somewhat
specialized to support the Unix kernel. For example, it can create a
logical copy of a segment where the new and old segment share common pages
but whenever one or the other changes a page, it gets its own copy of that
page. This primitive is very handy for efficient implementation of the
Unix fork() primitive. The VRM also handles low-level disk I/O and error
recovery, and also provides most of the support for the screen windowing
(unless they changed it since I left, which they might have.)
The AIX system is a port of AT&T System V with a lot of upwards compatible
extensions. Where it made sense, we borrowed stuff from 4.2, for example
the improved signal handling calls. Where there were de-facto standards
that made sense we followed them, such as the /usr/group file locking
primitives. Other stuff we had to invent ourselves, most notably
primitives which map files into segments, useful for code sharing and for
data base stuff. The C compiler is a straightforward port of PCC, much of
which I did. It produces code that is about as good as any other PCC
compiler's, although it must be admitted that PCC does not take very good
advantage of large numbers of registers. None the less, I believe you'll
find that if you compare C programs on a Vax 780 under 4.2 or SystemV and
on a RT PC under AIX, you'll find the RT PC to be somewhat faster. Friends
have run dhrystones but I'll let them report their own results.
Adding your own hardware devices
Go right ahead. It can be a little more complicated than on other Unix
systems since you need both a VRM driver and a Unix driver unless it's
something like a disk where your VRM driver can present an interface that
the Unix kernel already understands. Facilities are provided to add new
drivers to both the VRM and Unix in binary-only systems.
The external I/O bus is a PC/AT bus and most of the peripherals, other
than the new screens, are PC AT peripherals. I don't know how IBM feels
about attaching stuff to the internal 32-bit bus, but unless your device
is extremely fast, I don't know why you'd need to.
Interactive Systems DOS
There are two entirely separate DOS environments on the RT PC. One is the
PC AT coprocessor board which not surprisingly acts very much like a PC
AT. The other is a DOS compatibility package which runs under AIX. It
consists of a library of routines which faithfully simulate the various
documented DOS calls along with reimplementations of most of the commonly
used DOS commands and the DOS command processor. This means that if you
have a DOS program written in something other than 8088 assembler, in
principal you recompile it under IS-DOS and it should work. Of course in
practice the fact the the ROMP has 32-bit big-endian linear addressing
rather than 16+16=20 little-endian segmented addressing will cause
trouble, as will the fact that practically every useful DOS program
diddles the interrupts and directly addresses the screen and other
hardware. Even so, I gather that the IS-DOS environment feels comfortable
and familar to DOS users and that porting from PC-DOS to IS-DOS is notably
easier than going all the way to native AIX and besides, most of your
familiar batch scripts and function keys still work. Unix programs can
call DOS programs and vice-versa, since it's still Unix underneath, so
that mixed environments are workable. IS-DOS can read and write PC-DOS
floppies directly and if you open A:FOO.BAR from your IS-DOS program, by
golly it'll read your PC-DOS floppy, unless of course you logically
redirected A: somewhere else.
Networking
Beats me. AIX supports what you get with System V, i.e. uucp. We
physically plugged in 3Com Ethernet cards and got them to work under AIX in
a primitive way that was adequate for transferring files from our Vax and a
lot faster than floppies. IBM is not dumb and I expect they'll have some
sort of network out eventually, but I do not know what kind or what
functions it will support. As noted elsewhere, the ACIS port of 4.2BSD
(which was an almost entirely separate effort from AIX) gives you the
TCP/IP support that 4.2 provides.
John Levine, Javelin Software, Cambridge MA 617-494-1400
{ decvax | harvard | think | ihnp4 | cbosgd }!ima!johnl, Levine@YALE.ARPA
The opinions above are solely those of a 12 year old hacker who has broken
into my account, and not those of my employer or any other organization.
--------