Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!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 Newsgroups: comp.lang.forth Subject: Re: DOES> and flash (was: PICK changed from 1-based to 0-based?) Date: Thu, 16 Jan 2014 02:02:58 +0100 Organization: 1&1 Internet AG Lines: 48 Message-ID: References: <7xvby8f6md.fsf@ruckus.brouhaha.com> <12f05881-1ac4-45f1-b476-0179540c6e27@googlegroups.com> <52d145c4.1561442586@news.demon.co.uk> <2014Jan13.164601@mips.complang.tuwien.ac.at> <52d43774.1754399942@news.demon.co.uk> <2014Jan15.185210@mips.complang.tuwien.ac.at> NNTP-Posting-Host: p5dcd6c24.dip0.t-ipconnect.de Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: online.de 1389834180 12054 93.205.108.36 (16 Jan 2014 01:03:00 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Thu, 16 Jan 2014 01:03:00 +0000 (UTC) User-Agent: KNode/4.11.3 Xref: csiph.com comp.lang.forth:27912 Anton Ertl wrote: > Bernd Paysan writes: >>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). > > But the standard CREATE...DOES> must put the data in RAM, because the > user is entitled to do stuff like > > 5 ' foo >body ! > > at any time if FOO has been CREATEd and at least one cell has been > ALLOTed. And changing the body of a child of CREATE...DOES> is pretty > common (e.g., consider the reference implementation of X:deferred), so > dealing with that by "environmental restriction" is not a good idea. You tell the Forth system whether it's RAM or ROM, so you know that you can only put constants into ROM (write-once flash). If the user wants RAM, he says RAM. DEFER in flash is useful for forward references (write-once pattern). Arguing that the standard entitles to treat everything as RAM and therefore you don't want to have stuff in flash is a bit silly, because this is exactly the deficit of the standard implementers on small embedded systems face: You have much more flash than RAM on all of them. > But marking some memory areas as read-only can help optimization. I > am not sure that ROM and RAM really are the best way to do that (e.g., > it probably would not help for ALLOCATEd memory), but maybe they are > good enough. I wouldn't waste too much time on constant folding ALLOCATEd memory ;-). The main purpose of dynamic memory is to handle things that come and go. If it is just a one-time allocation of static data, don't ALLOCATE it. One thing worth to note about embedded systems is that this has become a moving target after 30 years of standstill and 8051. Now we have these PDP-11 derivatives with little RAM and some flash; with some small ARMs in between (with similar memory architecture, but usually more memory than the MSP430s). Maybe in a few years, we'll have ReRAM instead of flash, and the write-once problem is gone. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/