Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Mini History
Summary: another porting story
Message-ID: <7305@pt.cs.cmu.edu>
Date: 12 Dec 89 11:50:36 GMT
References: <5565@sdcc6.ucsd.edu> <6467@tekgvs.LABS.TEK.COM> <730@noe.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 27

> This is getting so nested that I'm not sure *who* wrote ...
> >And an excellent idea! I found figFORTH to be the most portable version I
> >ever used because the implementation was defined!  ...

I used MVP-FORTH for many years, and found it extremely portable.
My favorite portability story is porting a large floating point
math package from an Atari 800 to an IBM PC to a Heathkit Z80 to
an Apple II to a WISC CPU/16 without any changes at all.  Of course,
it was slow, but typically it took less than 24 hours to get the
machine code in place for higher speed -- which depended on good
factoring techniques.  I also ported a 500 screen hotel control
system from an Atari 800 to an IBM PC in about a day (lots of
I/O code and screen interface in this one, so it took a while).
Porting the math package to an F83 system is a bear, because
the numeric input words differ and divide is "broken".

Perhaps there is something to be said for defining an implementation
for a core.  It increases portability tremendously.  It should
not prevent manufacturers from offering product differentiation
(which they probably should be doing in the extension set, not
in the core anyway).

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor.
I don't speak for them, and they don't speak for me.