Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.datemas.de!weretis.net!feeder1.news.weretis.net!news.szaf.org!news.gnuher.de!rz.uni-karlsruhe.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: Thu, 09 Jan 2014 18:33:54 +0100
Organization: 1&1 Internet AG
Lines: 49
Message-ID: <lammi3$516$1@online.de>
References: <7xvby8f6md.fsf@ruckus.brouhaha.com> <lahe7f$l55$1@online.de> <2014Jan8.160903@mips.complang.tuwien.ac.at> <lak78m$5lc$1@online.de> <52ce067b$0$9211$e4fe514c@dreader35.news.xs4all.nl> <cs6dnavurarz6lPPnZ2dnUVZ_rudnZ2d@supernews.com> <lam9ep$f9j$2@online.de> <BO2dnaxKvcLvJlPPnZ2dnUVZ_tKdnZ2d@supernews.com>
NNTP-Posting-Host: p5dcd70ad.dip0.t-ipconnect.de
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Trace: online.de 1389288835 5158 93.205.112.173 (9 Jan 2014 17:33:55 GMT)
X-Complaints-To: abuse@einsundeins.com
NNTP-Posting-Date: Thu, 9 Jan 2014 17:33:55 +0000 (UTC)
User-Agent: KNode/4.11.3
Xref: csiph.com comp.lang.forth:27770

Andrew Haley wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Andrew Haley wrote:
>>> On the face of it, your argument -- that <BUILDS should be standard
>>> because it's needed to simplify implementations in such an
>>> environment -- is ludicrous.  There are tricks/techniques (your
>>> choice) that work in that environment with CREATE ... DOES> .
>> 
>> We standardized BUFFER: for much less, the trickery to implement
>> something similar to BUFFER: is much easier to do.
> 
> There's no portable way to do it, though.

CREATE ALLOT is 100% portable.  The point for why a BSS segment is needed is 
that you don't want to store tons of zeros.  But the amount of "trickery" 
necessary to compress (and expand) long runs of zeros in you image, which 
you have to copy to RAM anyways at startup is very small, and it will 
compress all zero-initialized stuff regardless how it was allocated.

>> Why are you so violently opposing this one?  Because it requires to
>> acknowledge that merging <BUILDS and CREATE was a mistake?  Come on!
>> Were you personally involved in this mistake?
> 
> No, I was not: it was before my time.  I think it was a brilliant
> idea, and far too valuable to miss because of some marginal systems,
> and besides that, they can implement CREATE ... DOES anyway.  The only
> problem is that you don't like the way that has to be done.

It's not just about not liking that way, it's about imposing things on 
implementors that can be quite difficult to achieve.  This sort of thing 
should not go into a standard, especially not a Forth standard (you can put 
very difficult to implement stuff into C++ or Java if you like; these are 
language standards with very few people actually writing compilers).  Almost 
anything in Forth is very easy to achieve and to implement, and as BUFFER: 
above shows, we encourage people to code hints to the system so that it is 
easier to implement the system.

So I still don't understand this violent opposition to <BUILDS, whereas you 
apparently seem to like a completely superfluous word like BUFFER:.  
Implement RLE compression on your initialized data, and you'd be done.  
Expanding RLE is really trivial, and when you do a high-quality compression, 
it will provide way more opportunity to compress your image than BUFFER:.

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