Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Memory Management/PIC
Message-ID: <2890.UUL1.3#5129@willett.pgh.pa.us>
Date: 16 Jun 91 13:07:53 GMT
Organization: (n.) to be organized.  But that's not important right now.
Lines: 46

Category 10,  Topic 36
Message 32        Fri Jun 14, 1991
D.RUFFER [Dennis]            at 20:53 EDT
 
To: X3J14 watchers

From: Elizabeth Rather (as an individual, this time)

A great deal of the flap over address alignment in ANS Forth seems unnecessary
to me.  The assumption seems to be that you have to go around inserting
ALIGNED before all instances of @, for example.

WRONG!  All words that generate and return addresses (e.g., VARIABLE, '
(tick), words defined by CREATE) return aligned addresses which can be used
directly.  So long as you increment these addresses by a value expressed in
transportable units (e.g., n CELLS, CELL+, n CHARS, FLOAT+, CHAR+) you still
have a usable address.  The only time you get an unusable address is when you
mix data types (e.g., ... CHAR+ @) or use an arbitrary value as an increment. 
The latter practice is intrinsically non-transportable in any case, however,
in that it assumes a character or cell width and hence introduces a dependency
on that width.  This is discussed clearly (IMHO) in Appendix G.2 of BASIS 15
and 16.  I have submitted a proposal that will be discussed this next week (I
assume) to make some of this language normative, so that it is clearly
*specified* under what circumstances an address can become un-aligned.

I realize that using words such as CELLS introduces a variance from FORTH-83. 
But remember that the benefit you get from this is the ability to run on 32-
bit systems, which are generally the wave of the future and which are
specifically *non-standard* under FORTH-83. Having witnessed several projects
involving upgrading very substantial pieces of code from 16 to 32-bit
architectures, I can assure you the cost-benefit tradeoffs in this case are
real and strongly in favor of width-independence.

(By the way, though: before you make a blanket change of all instances of 2+
to CELL+, remember that sometimes the number 2 counts something other than
bytes!  We've been bitten by that one, too.)

P.S. A search of BASIS 16 reveals that the _only_ word that returns a possibly
unaligned address is HERE, and that can only become unaligned as a result of
an arbitrary argument to ALLOT or an odd # of C,'s - meaning, _you_ as a
programmer _know_ & _control_ whether addresses are aligned.
-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp