Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: PHILOSOPHY & CM
Message-ID: <615.UUL1.3#5129@willett.UUCP>
Date: 6 Mar 90 01:04:16 GMT
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 53

Category 1,  Topic 12
Message 80        Sun Mar 04, 1990
F.SERGEANT [Frank]           at 21:50 CST
 
 Rob Chapman (via Usenet) suggests that  u  FOR  ...  NEXT   should  execute u
times.

 Rob, thanks for your suggestion and thanks for posting your source  code for
BOTFORTH.  (Where did the name come from?)

 : STARS  ( u -)   FOR  STAR  NEXT  ;

 In Pygmy and in cmFORTH and presumably in ANS,   u  STARS  would  do STAR  
u+1 times.  0 STARS would do STAR 1 time.  -1 STARS would do  STAR a whole
lotta times.  If you want it done u times you need to  do something like    :
STARS  ( u -)  ?DUP IF 1- FOR STAR NEXT THEN ;

 I have about decided that I agree with Rob.  In looking over several 
applications it seems that much of the time when I used  FOR NEXT I  preceded
it with 1- or surrounded it with  ?DUP IF 1- .... THEN.  So, I  think I'm
going to change over to Rob's method.

 cmFORTH has the word -ZERO that accomplishes this change to u instead  of 
u+1.  It is used like this

        : STARS  ( u -)   FOR  -ZERO  STAR   THEN  NEXT  ;

when I first looked at it, it didn't make sense to me that -ZERO was  laying
down an unconditional branch.  I thought it should be testing  for zero.  Now
I understand.  It lays down an unconditional jump to the  end of the loop,
using up the 1st of the u+1 passes without doing the  body of the loop.  If u
is zero, then the body of the loop is not  executed at all.  At compile time, -
ZERO increments the address left by  FOR so that NEXT will compile a branch
back to STAR and not back to the  unconditional branch laid down by -ZERO.

 Rather than use -ZERO, I think I will build it in as the default.

 The first cost I see is that each occurrence of FOR will take up 6  bytes (in
Pygmy:  PUSH BRANCH <address>  rather than just 2 bytes  for PUSH.  We could
define another primitive that would combine the  PUSH and branch and would
only take up 4 bytes instead of 6.  Thus our  cost in space is either 2 or 4
bytes.  We will make up for this by the  many times we can eliminate the  8
bytes for  ?DUP 1- IF  ...  THEN.   The other cost is the time to do the
branch in those cases where we do  not need to prevent the body of the loop
from executing for an index of  zero.  We will also gain in source code
clarity.

  Anyone have any thoughts on why we shouldn't make this change?

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