APL\3000: Difference between revisions

The system implemented [[Phil Abrams]]' [[subscript calculus]] by storing the [[rank]] and [[shape]] of an array, along with delta and offset vectors, separately from its data—that is, the [[ravel]], but not necessarily in [[ravel order]]. This system allowed [[Take]], [[Drop]], [[Reverse]], [[Transpose]], and [[Reshape]] to be implemented only by manipulating the shape and other fields, not the data itself. In combination with APL\3000's [[reference count]]ing system, this allowed even arrays with different shapes to share the same data. Arrays whose data was a linear function of the index were stored as [[arithmetic progression vector]]s, omitting the data entirely.

APL\3000's unlimited [[workspace]] size was implemented using a [[wikipedia:virtual memory|virtual memory]] system capable of paging parts of the workspace to disk. The least recently accessed page was always chosen to be paged out. To implement the required flat 32-bit address space on a minicomputer with a segmented, stack-oriented architecture, where a process could normally only address up to 64KiB of memory, they developed ten new CPU instructions whose microcode was included with the purchase of APL\3000 as a set of PROM chips that would be installed in the host HP-3000 Series II or III by an HP Customer Engineer. These instructions included virtual load and store between the 16-bit stack and 32-bit virtual addresses of 16-bit words and 8-bit bytes, as well as word and byte moves between virtual and stack addresses. There was also a virtual to virtual move, and two special instructions to support the "emachine" virtual machine execution engine, a fetch-and-dispatch for the 8-bit ecode instructions, and a single word load that allowed unaligned addresses relative to the current ecode program pointer, which was used by the virtual machine to load ecode parameters and immediates. The virtual memory instructions operated by searching a list of VM pages (typically 24 pages of 512 or 1,024 bytes each) that were stored at a known location in the APL process stack. If the target address was not found, control was passed to a fault handler provided by the APL system. To resolve faults, the appropriate page would be read from the on-disk workspace file into the least-recently-accessed stack page. A []VM system variable was provided that allowed user code to access and dynamically reconfigure the paging scheme and page-search mechanism.

The following [[control structure]]s were provided in APLGOL:

== Publications ==