home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / forth / compiler / forthed / programr.asc < prev    next >
Text File  |  1987-07-28  |  6KB  |  127 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.         Portable Forth Environment - by Guy M. Kelly    July 28, 1987
  8.  
  9.         "When you've seen one Forth you've seen one Forth!" Anon.
  10.  
  11.         Consider the plight of Forth programmers.  A fortunate? few use
  12.         a single version of Forth (and the Forth programming environment
  13.         supplied with that version).  This (un)fortunate few will
  14.         eventually modify their programming environment to be a bit more
  15.         comfortable (add a few utilities, a different editor, etc.).
  16.         Most of them will become reasonably (un)comfortable with their
  17.         programming environment (after all, even with it's warts, it's
  18.         probably better that programming in <fill in your pet language
  19.         here>.
  20.  
  21.         But what about "the rest of us?"  Isn't it fun to change from
  22.         MMS to HSW to poly to F83 to MVP to <again, fill in your
  23.         favorite version>?  Of course they're all standard version of
  24.         fig or 79 or 83 etc. <another chance to vote for your choice>!
  25.         And they all have similar features and extensions (is someone
  26.         laughing?).  (This may be easier than changing from an Intel
  27.         development system and the 80xx family of processors to the
  28.         Motorola or National "equivalent" or from UNIX to RSTS to
  29.         OS-360/370, et. al. but does that make it right? No!)
  30.  
  31.         Here are a few suggestions (at least for the world of PC's)
  32.         which might help.  While it's hard to do much for the many
  33.         varieties of Forths out there other than to add a few utilities
  34.         and redefinitions (or given source and meta-compiler, to re-do
  35.         them), we could at least standardize (sorry to use such a vulgar
  36.         word in such polite society) a few of the aspects of our
  37.         environment.
  38.  
  39.         What do we spend most of our time doing (while sitting at the
  40.         keyboard)?  Pushing keys of course.  Now, editors are probably
  41.         one of the most idiosyncratic programs that we have to use,
  42.         right?  (Ok Socrates, we know that game.) Wouldn't it be nice if
  43.         there were a reasonably good screen editor available that a
  44.         Forth programmer could acquire once and then take along to be
  45.         used with any of the various versions of Forth (for the PC's)
  46.         that are out there?  And wouldn't it be nice if that editor took
  47.         less than a kilobyte of memory from the resident Forth?  And
  48.         knew about various DOS and non-DOS media access methods?
  49.  
  50.         My thinking also, so I wrote one.  It loads as an overlay into
  51.         it's own segment.  The only memory required from the resident
  52.         Forth is for the overlay loader (a very small module).  The same
  53.         editor overlay is currently running with five different Forths
  54.         (F83, MVP, UNIFORTH, LMI, and both the stand-alone and the DOS
  55.         versions of PC-Forth).  A new overlay loader can be adapted from
  56.         one of the existing five in less than an hour, assuming that you
  57.         know a few details of your version of Forth and can write a few
  58.         code words. (Which brings us to the next topic: Assemblers!)
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.         In writing the overlay loaders for the various Forths, a great
  74.         diversity of design in the various Forth assemblers for the 80xx
  75.         family was (re)discovered.  No wonder there is so little
  76.         transportability among these Forths (and so little hope of
  77.         providing it)!  You have to learn a new assembler every time you
  78.         want to twiddle a bit!  Wouldn't it be nice if there were some
  79.         standardization among assemblers?  (An IEEE? sponsored group has
  80.         been working for years now to standardize assembler mnemonics
  81.         with no sign of success, but couldn't we at least agree on the
  82.         order of parameters?).
  83.  
  84.         Many Forth 80xx assemblers use:
  85.              source destination OPCODE,
  86.         unfortunately, others use:
  87.              destination source OPCODE.
  88.  
  89.         Most of these assemblers use different operators and defaults.
  90.         Using  #  for immediate is fairly standard, but:  #A  #)  and  )
  91.         and more have been used to indicate direct addressing; some
  92.         default to word, some to byte; some have left out all the
  93.         compact modes, some have not; etc.  And what is worse, some have
  94.         some very interesting features (dare we say bugs?).
  95.  
  96.         The UNIFORTH and the PC-Forth assemblers are the most complete
  97.         and compact of the assemblers available to me.  I normally use
  98.         the PC-Forth assembler (not to be confused with the LMI PC/FORTH
  99.         assembler) because I wrote PC-Forth. (The UNIFORTH assembler
  100.         would probably be quite acceptable if the source code for it
  101.         were public.) One feature of the PC-Forth assembler is
  102.         re-entrancy (it requires one user variable on a multi-user
  103.         system).  It would be nice (but not a necessity) if that were
  104.         true of any of the other assemblers.  The source code for the
  105.         PC-Forth assembler has been in the public domain for over four
  106.         years now and was written to run on any 83 Standard version of
  107.         Forth.
  108.  
  109.         Suggestion: we should all try to agree on the operator names and
  110.         defaults (and whether to use a trailing "," for op-codes) and
  111.         then all use a "standard" assembler (at least when publishing
  112.         code).
  113.  
  114.         A third "tool" that could make life easier for most of us would
  115.         be a common set of utilities to either directly load from, or to
  116.         translate source code between, text oriented files,  block
  117.         oriented files, and straight blocks.
  118.  
  119.         One solution: my current version of Forth has a multi-media
  120.         capability.  It exists in both stand-alone and DOS versions and
  121.         will transfer blocks between any media and between DOS files and
  122.         direct blocks.  It also will do nested compiles for any mix of
  123.         DOS block files, DOS text files, and direct-access blocks. (The
  124.         DOS loaded version is included as part of the editor overlay
  125.         package and can be used as a general utility to move data
  126.         between direct blocks and blocks in files.)
  127.