Path: utzoo!attcan!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: LMI Forth(s)
Message-ID: <1228.UUL1.3#5129@willett.UUCP>
Date: 27 Jun 90 11:00:33 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 76

Category 1,  Topic 46
Message 85        Tue Jun 26, 1990
R.BERKEY [Robert]            at 22:00 PDT
 
  Topic: portability, input stream standardization

Ray Duncan writes (to Robert Berkey), 900618:

  RD> Since the ANSI process mandates that standards be built on
  RD> existing practice, I'm surprised that you have not taken the
  RD> trouble to research how the current, commercially available
  RD> systems are already handling these problems.

I don't see a need to respond to this statement beyond noting that it is
emotive and ad hominem.

 RD> In LMI systems, the variables >IN, BLK, etc. are read-only to the
 RD> application.

In (at least some) LMI systems, the variable >IN is read/write, with the
variable BLK being nominally read-only.  As for BLK , here is an example of
LMI-based application code, being used as part of restoring BLK :

   : SOURCE! 14964 2! ;

The point is not what this means or does, but that applications store into BLK
on LMI systems, however cryptic the process.

  RD> This allows a much more efficient implementation of the
  RD> interpreter/compiler, particularly in WORD.

A code fragment to check for a modified BLK :

 MOV AX, DEFAULT-BLK
 CMP AX, BLK
 <> IF

This code fragment constitutes about 13 cycles on an 80286.  At 10Mhz this is
less than two microseconds per token, i.e., more than 500,000 tokens per
second.

  RD> If you allow the application to twiddle these variables, the
  RD> system is forced to check BLK each time it reads a token off the
  RD> input stream to make sure the input stream has not been moved
  RD> behind its back.

I agree as far as saying I think that it is preferable to standardize ways
other than storing into BLK for setting the input stream.  If LMI has offered
X3.J14 any proposals I'm not aware of it.

  RD> The existence of a word with the functionality of EVALUATE
  RD> completely eliminates any need for the application to twiddle >IN
  RD> etc. to manipulate the input stream.

Not when the source is on BLOCKs--EVALUATE has multiprogramming impact, and
portable programs must allow for multi-tasking.  Additionally, if EVALUATE is
pointed at source on a BLOCK , there is a problem when such code needs to know
the real value in BLK , as opposed to the 0 found there from within an
EVALUATE .  Thirdly, directly setting the input stream pointers is more
efficient than EVALUATE for passing a <name> to CREATE , as this bypasses the
interpreter and vocabulary mechanisms.

 RD> But I can tell you from a *practical* standpoint, from experience
 RD> with Forth systems that have thousands of users, that making >IN
 RD> BLK etc. read-only works perfectly well *if* you provide with a
 RD> superior alternative such as EVALUATE.

Meanwhile, code won't port to LMI systems, and LMI user's must work around the
problem.  Which gets back to the original question to LMI users: What's needed
to run QUOTE-TO.SCR on LMI products?

Robert

-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu