lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/10/89)
With the recent discussion on Forth implementations in hardware,
I was pleasantly shock the other day while reading through the
_The_SBus_Specification_ manual for the SPARCstation I.
On page 87, the begin to describe the device driver interface to the
SBus. Instead of a machine language interface, they use something
called the "FCode Language." To quote the first paragraph of section
3.4.4:
"The FCode programming language is closely related to the
Forth 83 programming language. FCode is essentially Forth
83 with extensions appropriate to its use for device
identification and boot drivers. Additionally, FCode has a
well-specified binary format, where Forth 83 specifies only
the source format. In contrast to Forth 83, FCode is based
upon a 32-bit stack width and 32-bit arithmetic."
Appendix B gives an overview of Forth, and provides a sample FCode
driver for a single-bit deep frame buffer.
I think I'll retire cforth now ... :-)
--
Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University
{alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA
"I think every man should have a wife. You can't blame
everything on the government." -- Jed Clampettwmb@SUN.COM (Mitch Bradley) (10/11/89)
> I was pleasantly shock the other day while reading through the > _The_SBus_Specification_ manual for the SPARCstation 1. > On page 87, the begin to describe the device driver interface to the > SBus. Instead of a machine language interface, they use something > called the "FCode Language." To quote the first paragraph of section 3.4.4: > > "The FCode programming language is closely related to the > Forth 83 programming language. FCode is essentially Forth > 83 with extensions appropriate to its use for device > identification and boot drivers. Additionally, FCode has a > well-specified binary format, where Forth 83 specifies only > the source format. Now that the SBus spec is public, I guess I can talk about this topic. I am the architect and implementor of FCode, and the author of the quoted text from the SBus spec. The SPARCstation 1 is the most popular machine in Sun's current product line. It offers 11 MIPS performance for $9000. It is expandable via a new open bus called "SBus" The boot PROM on the Sun SPARCstation 1 is written in Forth. When you power-on the machine, if you don't touch it, it will perform some selftests and then automatically boot Unix. If you abort the selftests or the Unix load sequence, then you will get a monitor prompt which looks like ">". At this prompt, you have exactly 3 options: "b" for boot, "c" for continue (as if the abort had not happened, and "n" for "new command mode". "n" is the one you want. That switches the prompt to "ok " and you're in Forth. It's a real Forth, with all the usual stuff plus a lot of extensions: pretty-printing decompiler disassembler symbolic debugger for C programs (e.g the Unix kernel) configuration manager FCode interpreter boot protocols "canned" hardware diagnostics All of these extensions are just Forth words, so you can use them inside colon definitions. For instance, the symbolic debugger is a set of stack-oriented words to set breakpoints, display various registers, single-step, etc (as opposed to some Forth debuggers I have seen, where you have to get into a special "debug mode" and the rest of the Forth interpreter is temporarily unavailable). Configuration Manager The configuration manager is a halfway object-oriented package for dealing with machine configuration data stored in non-volatile RAM. Each configuration option is a multiple-code-field word which implements operations for storing and fetching the item's value into the NVRAM chip, and encoding and decoding that value to and from human-readable form. Each item has both a current value and a default value, and the boot PROM can automatically re-establish a complete default state in the event of a failure which trashes the NVRAM contents. The user can get a symbolic listing of any or all of the configuration options, and can alter any option at will, using the symbolic name and a human-understandable representation of the value. For example, one of the options is named "input-device". Its value is either "ttya", "ttyb", or "keyboard". Internally, the value is stored in the NVRAM as a single byte containing either 0, 1, or 2. The user doesn't know or care about the encoding, though. The "printenv" command, which shows all the options at once, would display this options as: Parameter Name Value Default Value ... input-device ttya keyboard ... To change the value, the casual user would type: setenv input-device keyboard There are many other option data types, for example text strings, binary data arrays, true/false flags, and numbers. The casual user doesn't worry about the representation of the data type. The configuration options are real Forth words too. If you type just "input-device", or compile it into a colon definition, the value is left on the stack where you can use it for whatever purpose. FCode Interpreter The SPARCstation 1 has an expansion bus called "SBus". It is Sun's intention to promote SBus as a standard for use both on Sun and non-Sun machines. SBus was designed for low-cost and high performance. SBus cards are cheaper to build than other 32-bit buses, yet the data transfer rate is faster than VMEbus, MicroChannel, or NuBus. The SBus spec has been released to the public, and SBus interface chips are already available from one outside vendor. One of the problems with open buses is booting. Traditionally, there were 3 options for booting from a third-party device: a) The card emulates some device already supported by the computer manufacturer. b) The third-party device comes with special ROMs for the supported computer. c) The computer supports plug-in boot devices, with external boot ROMs. The external boot ROMs are encoded in the machine language for the particular computer. Approach (c) works reasonably well for PC add-in, where you know that the processor is going to be 8086 compatible, and for Mac II NuBus cards, because NuBus is used on few machines other than Mac IIs. However, we did not wish to restrict the use of SBus to SPARC processors. Sun itself supports 3 processor families (SPARC, 680x0, 80x86), and we would like to see SBus used on other machines as well. Consequently, we chose to encode our boot drivers in a machine-independent language, Forth was the obvious (to me at least) choice. (Texas Instruments originally specified a machine-independent stack-oriented language for NuBus, but Apple chose not to use it). SBus drivers are encoded in FCode, which is related to Forth in the following way. Take the Forth 83 standard words, throw out a few which are obviously not useful in the booting environment, and add some necessary ones, such as portable addressing words and application hooks (memory allocation, boot application interfaces). This gives you a finite set of words which forms a functionally complete programming language. There are about 200 primitive words in this set, and something like 150 system "library" words. Assign a unique integer to each of these words. Now, to write an FCode program, you just write a Forth program. Then you pass the Forth source code through a "tokenizer" program which replaces each word name with the associated binary integer. The resulting array of integers is an FCode program. It is semantically equivalent to the Forth source code, but it takes up less space and can be interpreted/compiled more quickly, because indexing into a table is faster than a dictionary search. That is FCode. It is used for SBus drivers, both for boot devices such as disk controllers and network interfaces, and also for display devices such as frame buffers and graphics boards. These FCode drivers are primarily used during the boot process. Once Unix is up and running, Unix uses its own drivers. The Unix drivers are much more complicated, and usually higher performance, since they often go to great lengths to optimize sequences of requests, overlap operations, etc. Devices which are not needed during the boot process (e.g. printer interface) have FCode PROMs too. In this case, the FCode PROM serves to identify the device and to report some of its characteristics to Unix. To this end, FCode has commands for exporting name/value pairs to Unix, along with a machine-independent representation for structured data. Forth/FCode on Other Sun Machines The Forth PROMs (the official name is "Open Boot PROM") are being designed-in to some future Sun machines, so you can expect to see more of them as time goes by. Documentation The SPARCstation 1 Forth is a built-in on-line help facility. There is also a manual called the "Open PROM Toolkit User's Guide" which is slated for inclusion in the SBus Developer's Kit, which is due out soon. I can't say exactly when. Buy a SPARCstation for the Forth PROM? That's probably not what you want to do. The Forth in the SPARCstation 1 boot PROM, while complete, is optimized for the booting / machine testing / Unix debugging. It trades off execution speed to be more compact, and its primary users are not expected to be Forth programmers. If you are developing SBus hardware, then you would want a SPARCstation 1 so you could use the system, including the PROM Forth, for debugging your product. If you just want to use Forth, the best way to do it on a SPARCstation 1 is to run Forth under Unix. My Sun Forth product is a suitable choice for that environment.
wmb@SUN.COM (10/13/89)
> I was very impressed with the description of FCode, as well as a > number of other things I have seen your name on (your proposed revisions > to INTERPRET come to mind). I think that you should publicize your > efforts in Forth through articles and publications. The computing > community will soon have a better opinion of Forth if they see the > quality of your work. Thanks. I publish a reasonable number of articles in Forth journals, but so far I haven't published in any "respectable" publications. Writing takes a lot of time. I was thinking about selling some Sun stock and hiring a writing assistant so I could publish more, but that scheme is just daydreaming at this point. > I am interested in seeing the final list of Forth "primitive" words > that you arrived at. Enclosed > I am also interested in your version of Forth. > Does it come with source code? I have been thinking about developing > a Forth-like system for IRIS workstations, as I do a lot of work > in interactive 3D graphics and animations, which would be an excelletn > application of Forth. My Sun Forth product will run on 680x0-based SGI workstations, and the C Forth product will run on MIPS-based ones. Atari/Macintosh Forthmacs (assembly language based) working disk & manual $50 source code $50 Sun Forth (runs on any 680x0 or SPARC Unix machine, assembly language based) tape, manual, and source $200 C Forth 83 (written in C, runs on nearly anything, PCs to mainframes) source and manual $50 Address: Bradley Forthware P.O. Box 4444 Mountain View, CA 94040
torkel@SICS.SE (10/17/89)
About the SPARC 1 Forth: some of us Forth enthusiasts at the Logic Programming Laboratory of SICS (don't tell our bosses) are very interested in exploring the resident Forth, but it seems we need some documentation. Is is possible to obtain such from you or some other source?