Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!news-1.dfn.de!news.dfn.de!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!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 21:37:25 +0100
Organization: 1&1 Internet AG
Lines: 67
Message-ID: <lb476a$7t4$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> <lb3q1e$ibt$1@online.de> <G-WdnRIzN-ExEEjPnZ2dnUVZ_hOdnZ2d@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 1389731850 8100 79.197.69.94 (14 Jan 2014 20:37:30 GMT)
X-Complaints-To: abuse@einsundeins.com
NNTP-Posting-Date: Tue, 14 Jan 2014 20:37:30 +0000 (UTC)
User-Agent: KNode/4.11.3
Xref: csiph.com comp.lang.forth:27898

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> 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,
> 
> Well, it's both, really.

Yes, the problem with CREATE is that it is dual-purpose: First, CREATE 
<name> is just creating a data label.  And then, CREATE is the starting 
point of what becomes modified by DOES>.  There are systems where this dual 
use is no problem at all, and there are systems (as discusssed) where this 
dual use is really problematic.

The usual case of CREATE + ALLOT something in RAM is already dealt with 
BUFFER:, a special-purpose word.

>> 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).
> 
> But that's very nonstandard: by definition anything after CREATE is
> writable.

Er, we are talking about dictionary-in-flash mode.  If you are in this mode, 
everything is exactly write-once.  If you want to have stuff in RAM, switch 
to RAM mode.

> Of course, I know that, but there's no reason that
> 
> : array: ( n -- )
>    create cells allot
>    does> ( n <addr> -- )  swap cells + ;
> 
> can't work, given appropriate definitions for CREATE and DOES>

And ALLOT, which however is not the case.  ALLOT manipulates the current 
dictionary, and if that's flash (ROM), then it is write-once.  Defining 
VARIABLE in that mode will redirect you to RAM space (implemented as 
CONSTANT).

You can hide this fact by being clever, but being clever is orthogonal to 
being simple.  These resource-constrained environments absolutely require 
being simple.

> You don't need to allocate space for that pointer until DOES> is
> executed, therefore there is no space wasted.

Unfortunately, the user is allowed to allocate stuff from the dictionary 
*before* DOES> is executed.  However, when you hide the flash space, and the 
user only can manipulate RAM space, while all the code and header stuff goes 
to flash, this restriction goes away.

However, as these systems are very RAM-constrained, it is important that the 
user can put all constant data into flash.

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