home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Portable Forth Environment - by Guy M. Kelly July 28, 1987
-
- "When you've seen one Forth you've seen one Forth!" Anon.
-
- Consider the plight of Forth programmers. A fortunate? few use
- a single version of Forth (and the Forth programming environment
- supplied with that version). This (un)fortunate few will
- eventually modify their programming environment to be a bit more
- comfortable (add a few utilities, a different editor, etc.).
- Most of them will become reasonably (un)comfortable with their
- programming environment (after all, even with it's warts, it's
- probably better that programming in <fill in your pet language
- here>.
-
- But what about "the rest of us?" Isn't it fun to change from
- MMS to HSW to poly to F83 to MVP to <again, fill in your
- favorite version>? Of course they're all standard version of
- fig or 79 or 83 etc. <another chance to vote for your choice>!
- And they all have similar features and extensions (is someone
- laughing?). (This may be easier than changing from an Intel
- development system and the 80xx family of processors to the
- Motorola or National "equivalent" or from UNIX to RSTS to
- OS-360/370, et. al. but does that make it right? No!)
-
- Here are a few suggestions (at least for the world of PC's)
- which might help. While it's hard to do much for the many
- varieties of Forths out there other than to add a few utilities
- and redefinitions (or given source and meta-compiler, to re-do
- them), we could at least standardize (sorry to use such a vulgar
- word in such polite society) a few of the aspects of our
- environment.
-
- What do we spend most of our time doing (while sitting at the
- keyboard)? Pushing keys of course. Now, editors are probably
- one of the most idiosyncratic programs that we have to use,
- right? (Ok Socrates, we know that game.) Wouldn't it be nice if
- there were a reasonably good screen editor available that a
- Forth programmer could acquire once and then take along to be
- used with any of the various versions of Forth (for the PC's)
- that are out there? And wouldn't it be nice if that editor took
- less than a kilobyte of memory from the resident Forth? And
- knew about various DOS and non-DOS media access methods?
-
- My thinking also, so I wrote one. It loads as an overlay into
- it's own segment. The only memory required from the resident
- Forth is for the overlay loader (a very small module). The same
- editor overlay is currently running with five different Forths
- (F83, MVP, UNIFORTH, LMI, and both the stand-alone and the DOS
- versions of PC-Forth). A new overlay loader can be adapted from
- one of the existing five in less than an hour, assuming that you
- know a few details of your version of Forth and can write a few
- code words. (Which brings us to the next topic: Assemblers!)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- In writing the overlay loaders for the various Forths, a great
- diversity of design in the various Forth assemblers for the 80xx
- family was (re)discovered. No wonder there is so little
- transportability among these Forths (and so little hope of
- providing it)! You have to learn a new assembler every time you
- want to twiddle a bit! Wouldn't it be nice if there were some
- standardization among assemblers? (An IEEE? sponsored group has
- been working for years now to standardize assembler mnemonics
- with no sign of success, but couldn't we at least agree on the
- order of parameters?).
-
- Many Forth 80xx assemblers use:
- source destination OPCODE,
- unfortunately, others use:
- destination source OPCODE.
-
- Most of these assemblers use different operators and defaults.
- Using # for immediate is fairly standard, but: #A #) and )
- and more have been used to indicate direct addressing; some
- default to word, some to byte; some have left out all the
- compact modes, some have not; etc. And what is worse, some have
- some very interesting features (dare we say bugs?).
-
- The UNIFORTH and the PC-Forth assemblers are the most complete
- and compact of the assemblers available to me. I normally use
- the PC-Forth assembler (not to be confused with the LMI PC/FORTH
- assembler) because I wrote PC-Forth. (The UNIFORTH assembler
- would probably be quite acceptable if the source code for it
- were public.) One feature of the PC-Forth assembler is
- re-entrancy (it requires one user variable on a multi-user
- system). It would be nice (but not a necessity) if that were
- true of any of the other assemblers. The source code for the
- PC-Forth assembler has been in the public domain for over four
- years now and was written to run on any 83 Standard version of
- Forth.
-
- Suggestion: we should all try to agree on the operator names and
- defaults (and whether to use a trailing "," for op-codes) and
- then all use a "standard" assembler (at least when publishing
- code).
-
- A third "tool" that could make life easier for most of us would
- be a common set of utilities to either directly load from, or to
- translate source code between, text oriented files, block
- oriented files, and straight blocks.
-
- One solution: my current version of Forth has a multi-media
- capability. It exists in both stand-alone and DOS versions and
- will transfer blocks between any media and between DOS files and
- direct blocks. It also will do nested compiles for any mix of
- DOS block files, DOS text files, and direct-access blocks. (The
- DOS loaded version is included as part of the editor overlay
- package and can be used as a general utility to move data
- between direct blocks and blocks in files.)