Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.freenet.ag!takemy.news.telefonica.de!telefonica.de!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail
From: Bernd Paysan <bernd.paysan@gmx.de>
Newsgroups: comp.lang.forth
Subject: Re: PICK changed from 1-based to 0-based?
Date: Tue, 14 Jan 2014 17:53:02 +0100
Organization: 1&1 Internet AG
Lines: 52
Message-ID: <lb3q1e$ibt$1@online.de>
References: <7xvby8f6md.fsf@ruckus.brouhaha.com> <la4c9j$2hk$1@online.de> <BLudnVNaAN08QFjPnZ2dnUVZ_oidnZ2d@supernews.com> <la4qqo$qkl$1@online.de> <YIGdnfdJDPTjEFvPnZ2dnUVZ_oWdnZ2d@supernews.com> <la6png$v0u$1@online.de> <gN2dnTjkOcj4ZlvPnZ2dnUVZ_u-dnZ2d@supernews.com> <12f05881-1ac4-45f1-b476-0179540c6e27@googlegroups.com> <doOdnQrmscNVhUzPnZ2dnUVZ_radnZ2d@supernews.com> <52d145c4.1561442586@news.demon.co.uk> <XemdnacdqL0q0UzPnZ2dnUVZ_o6dnZ2d@supernews.com> <2014Jan13.164601@mips.complang.tuwien.ac.at> <s4OdnVAR-uurhUnPnZ2dnUVZ_rSdnZ2d@supernews.com> <52d43774.1754399942@news.demon.co.uk> <lb1g8c$r6o$1@online.de> <PsSdnYfhz8TXm0jPnZ2dnUVZ_gednZ2d@supernews.com>
NNTP-Posting-Host: p4fc5455e.dip0.t-ipconnect.de
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Trace: online.de 1389718383 18813 79.197.69.94 (14 Jan 2014 16:53:03 GMT)
X-Complaints-To: abuse@einsundeins.com
NNTP-Posting-Date: Tue, 14 Jan 2014 16:53:03 +0000 (UTC)
User-Agent: KNode/4.11.3
Xref: csiph.com comp.lang.forth:27893

Andrew Haley wrote:
>> * Every word wastes one cell of precious memory (could be reduced to
>> wasting only cells on CREATE)
> 
> Hold on a second: are you saying that you waste a cell for every word
> (rather than just words from CREATE) voluntarily and unnecessarily,
> yet you are complaining about the overhead that could be avoided by
> <BUILDS ?

No, I just follow the general idea from the concept of not having <BUILDS 
that CREATE is the vanilla defining word, and all other defining words are 
one way or another derived from CREATE, and there's no special casing for 
DOES> (this is to be compatible with code that makes that assumption - non-
standard code, though, but not worth breaking).  There is an additional 
pointer to RAM, as well...  but that one really is only there if it needs to 
be.  The usual case for CREATE DOES> is constant data, and therefore, there 
should be a way to have constant ROM-based data after the CREATE (not 
wasting precious RAM and one pointer less in precious flash).

Let's say you want a cell array in RAM, so you would define:

: array: ( n -- )
  <BUILDS RAM here ROM , RAM cells allot
  DOES> ( n <addr> -- )  @ swap cells + ;

This separation of RAM and ROM even makes sense on a native code desktop 
Forth like VFX, iForth or bigForth, as you don't worry about sharing data 
and code in the code cache, you only worry about sharing writable data (this 
can cause a big performance hit).

> But... the alternative, <BUILDS, also wastes one cell per child of
> DOES> , and it also has to write a flash cell twice, does it not?

<BUILDS would give a reason for special-casing it - it is not the root of 
all defining words, but the special case for DOES>.  And as the usual 
embedded flashs are word-writable, you just put in the DOES> address when 
you get to the DOES>.

> There has to be a pointer to RAM from flash, and there has to be a
> pointer to code.  So that's two cells.  This is true whether DOES> is
> used or not.  When DOES> is used, add a pointer to the DOES> code
> and overwrite some bits of the pointer to code.  So, there are now
> three pointers.

Yes; the point is that there has to be one additional unused pointer for 
every header that can be modified by DOES>.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/