ma168a@sdcc3.ucsd.EDU (John Wavrik) (12/15/87)
Every other year I post this inquiry -- it is now time to do it again: I am interested in locating others who teach Forth (at any level). I think it would be valuable for people who are teaching Forth to communicate with each other -- and I would be willing to do what I can to facilitate communication. Please contact me if you are teaching Forth. ...ucbvax!sdcsvax!jjwavrik (UUCP) jjwavrik.ucsd.edu (BITNET) jjwavrik@sdcsvax.ucsd.edu (ARPA) Prof. John J Wavrik Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093 For the curious: two years ago the set of people who read this newsgroup and teach Forth had one element.
wmb@MITCH.ENG.SUN.COM (09/26/90)
Forth Crash Course report. by Michael Saari
On September 18, 1990 I presented a "Forth Crash Course" here at
Sun Microsystems to approximately 200 attendees. It ran for 3 1/2
hours (3 one-hour sessions with breaks), and was designed to convey
a practical overview of the language with emphasis on actual usage.
About 140 attendees were Sun employees. I would guess that half of
these were technician-level people who wanted to learn Forth for the
purpose of writing machine diagnostics for system debugging. The other
half were probably simply interested in getting familiar with the language,
since Sun is now using Forth on most of its new workstation platforms.
The other 60 attendees were third-party vendors, here for our two-day
"SBus Expo". The class was presented here because Forth is an
integral part of the SBus interface (for adding peripheral cards to
Sun systems). These people were thus interested in learning Forth as
part of their SBus card development efforts.
As such, I had an easy job of it. Everyone was there because they
wanted to learn Forth - I didn't have to try to convince them of
anything or try to "sell" them. The audience seemed generally awake
and interested. Most of the questions were appropriate and relevant.
Because of the limited time, and the mixed needs of the audience, I
restricted the subject area to Forth basics, i.e. 83-Standard words
for the most part. I did not go into SBus FCode specifics (i.e.
attributes) or SPARCstation diagnostics specifics (such as memory
mapping). The idea was that these particulars can be learned from
existing documentation. The goal here was an overview of the
language, its capabilities, and practical tips.
Although I didn't receive any "rave reviews", the general feedback
I got from the class was positive. My intent was to convey enough
"familiarity" that people could go out and use the language if
needed. I gave out extensive (56 page) class notes, plus a quick
"reference card" listing all of the commands in an easy-to-use
format organized by functional groups. The class was also
videotaped, and the video and/or the class notes will be made
available to anyone who requests it, both inside and outside of
Sun. Contact:
Michael Saari
Sun Microsystems - SBus Technical Support Group
2550 Garcia Ave., Mailstop MTV 21-19
Mountain View, CA 94043
(415) 336-3609
Email: saari@robotman.Eng.sun.COM
Here's an outline of the class and what was covered. Several examples
of use were given for most words covered.
FIRST HOUR - Basics
- ----------
Logistics, etc.
Characteristics of Forth - Advantages and disadvantages
Versions of Forth - 83-Standard vs. Sun's versions
-this class covers the subset common to all
Basics (syntax, stack, interpreter, definitions, file downloading)
BREAK
SECOND HOUR - Tools
- -----------
"Hang onto your hats" - presented a *lot* of material very quickly,
but with good notes handed out for later reference.
Operators (stack, arithmetic, memory, text and numeric I/O, numeric base)
Conditionals (flags, If-then)
Loops (conditional, DO)
CONSTANTs, VALUEs, VARIABLEs
Array creation with CREATE C,
BREAK
THIRD HOUR - Actual Practice
- ----------
General Guidelines (how to write readable, modular code)
Practical example (right way vs. wrong way to initialize a complex device)
Testing/debugging with above example
Common pitfalls of Forth
Advanced topics (was going to be handouts with no discussion, but I had
some extra time so they got discussed anyway...)
- -Return stack usage
- -"see" decompiler
- -"patch" and "npatch", to change definition contents quickly
- -ABORT and ABORT" and QUIT
- -Deferred execution
- -Basic dictionary structure
- -Assembler (general, no specifics)
- -CREATE and DOES> (concept of creating new defining words only)
Notes for Forth people:
I didn't mentions vocabularies at all, nor did I mention "immediate" words.
Dictionary structure only got mentioned at the very end. EXPECT was
not mentioned.
Many of my examples used interactive "compile-only" words, such as:
ok begin 4000 c@ . key? until
11 11 11 11 11 11 11 11 11 11 11 11 11
ok
which is allowed in our versions of Forth (but not in the 83-Standard).
Personally, I consider this a deficiency in the Standard.
We use files for downloading. BLOCKs were not mentioned at all.
We use a 32-bit Forth, with words such as: c@ (8 bit), w@ (16 bit),
l@ (32-bit) and @ (unspecified, for VARIABLEs only). This approach
should make it easy to port to any 16-bit system if necessary. These
words were described, but the 16-bit vs. 32-bit aspect was mostly
glossed over.
Michael Saari
------- End of Forwarded Message