Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!bu.edu!transfer!lectroid!sw.stratus.com!nick
From: nick@sw.stratus.com (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: Align
Message-ID: <6217@lectroid.sw.stratus.com>
Date: 19 Jun 91 14:10:18 GMT
References: <9106190432.AA02430@ucbvax.Berkeley.EDU>
Sender: usenet@lectroid.sw.stratus.com
Organization: Stratus Computer, Inc.
Lines: 24

Daniel C. Sobral write:
>C, should ensure that the next invocation of HERE, ALLOT... will utilize a CELL
>boundary?!?!?!?!??!?!?!?

Good.  It wasn't just me who thought this was a lousy idea.  I was wondering
how C, would ever accomplish this,  short of always allocating enough
bytes to end up on a CELL boundary.  But then how do you pack bytes with
successive "C,"s (sp?).

I'm always hesitant of posting to this group,  having read publications
by many of the other posters, it is hard for me to think of myself as a
peer.  For example,  I assume there must be something I don't understand
about all these ALIGNment issues.  Haven't we been living with ALIGN on
68Ks for a decade now?  I've always assumed that the implementation was
pretty straight forward:  ALLOT assures that the address generated for the
variable being alloted is appropriate to the size of the variable, allocating
extra bytes to make it so.  Of course, this assumes the size is a 'natural'
size for the processor, usually bytes, longs etc.  For 'unnatural' records,
you had to align things manually.  Is there something new I'm missing?

BTW:  Alignment to a CELL boundary is not necessarily sufficient, depending
on the processor.  For example, the i860 requires address alignment to be
MOD(size of variable), or there is a very high performance penalty on memory
accesses.