From: Bernd Paysan Newsgroups: comp.lang.forth Subject: Re: PICK changed from 1-based to 0-based? Date: Wed, 15 Jan 2014 04:19:14 +0100 Organization: 1&1 Internet AG Lines: 91 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> 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 1389755955 14468 79.197.69.94 (15 Jan 2014 03:19:15 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Wed, 15 Jan 2014 03:19:15 +0000 (UTC) User-Agent: KNode/4.11.3 X-Original-Bytes: 5514 Path: csiph.com!usenet.pasdenom.info!news.stben.net!border3.nntp.ams.giganews.com!backlog3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail Xref: csiph.com comp.lang.forth:27906 Elizabeth D. Rather wrote: > Wrong. ALLOT manipulates the *data space pointer* not the dictionary, > and HERE returns the address of the next available location in *data > space*. > > Applications have no inherent right to manipulate dictionary space. Yes, > there have always been (and still are) systems in which data space and > dictionary are intermingled, but as a programmer you need to be able to > think of them separately. That concept is essential for dealing with > RAM/ROM/FLASH environments. The RAM/ROM part is orthogonal to data/code. ROM is for constant data and constant code, RAM is for variables. There's a lot of constant data, as well, and RAM can be used for temporary code - we do have use cases for that, too. Some processors (8051, AVR) assign flash and RAM to these roles by being Harward architectures, others don't. The current standard is not fitting well with the situation we have on these small controllers. Andrew asks me why I bother with standards when my system is uttrly non-standard. The reason is: I do care, but I can't, because the standard collides hard with the reality of these systems - so this opens up the question whether this is a problem with the standard or these systems. One reality of these systems is that code and data are no longer separated in flash and RAM - the more recent systems are von Neumann architectures, you can intermingle data and code - and it helps to fully utilize the few resources if you do. We are not talking about esotheric hardware, we are talking about mainstream controllers - whether small ARM Cortex-M0 or -M1, the MSP430, or the R8C family. They all are no longer arcane 8 bit microcontrollers as it used to be, but scaled down derivatives of respected architectures (PDP-11 in case of MSP430 and R8C, ARM Thumb mode in case of the Cortex series). Programs written for such systems can still be portable. If you don't have a flash, but everything is in RAM (like on a PC), well, then writing to the ROM space is actually possible. The program that doesn't write into ROM space still will work. Unless you overdo it with switching between RAM and ROM, all you need to do on a PC is to define the two words as NOOP. Let's give an example: In the R8C port of Dirk Zoller's Tetris for Terminals, bricks look like that (comments partially stripped in this code for faster downloading): \ Define shapes of bricks: : def-brick create does> rot 4 * rot + 2* + ; : ,s" [char] " parse bounds DO i c@ c, LOOP ; def-brick brick1 ,s" " ,s" ###### " ,s" ## " ,s" " This is all ROM space, because we have a number of bricks, but we don't have enough RAM for all the bricks - and the data is constant, anyways. Then we have the space for two bricks which is actually in RAM: \ this brick is actually in use: ram def-brick brick ,s" " ,s" " ,s" " ,s" " def-brick scratch ,s" " ,s" " ,s" " ,s" " rom The whole program fits very tightly into the available memory. My experience with all these projects is that they fill up all available space, and therefore have to make best use of what's there. Being free to select RAM or ROM for data is one of the key features that allows this. Having one intermingled dictionary is also conceptually easier. Remember: We use these controllers as carrot on a stick to get people interested in Forth. It is much more fun to program these controllers in Forth than with C, and we do get them that way. They are not interested in Forth on PCs, because Python gives them all they need, including interactiviy. Python doesn't run on a controller. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/