Newsgroups: comp.lang.forth
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!maccs!innovus!rob
From: rob@innovus.uucp (Rob Sciuk)
Subject: Re: Align
Message-ID: <1991Jun20.155046.4273@innovus.uucp>
Organization: Innovus Inc.
References: <9106190432.AA02430@ucbvax.Berkeley.EDU> <6217@lectroid.sw.stratus.com>
Date: Thu, 20 Jun 91 15:50:46 GMT

In article <6217@lectroid.sw.stratus.com> nick@sw.stratus.com (Nicolas Tamburri) writes:
>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?).

here's how!

	hmmm ... here we go again ... my C, will not pad the dictionary
	per se, there is an implicit ALIGN and ALLOT done if necessary

	My prior posting included a C implementation of C, but the 
	following code is provided to clarify (?) the semantics of my
	proposed C,. 

	quan CDP
	: C,	( c --- )
		CDP NOT  ( CDP not initialized or ... )
		CDP HERE = OR ( CDP is at HERE or ...)
		DP HERE - CELLSIZE 1- > OR IF ( CDP is more than 1 
						CELL behind HERE )
			HERE is CDP  	( re-align CDP )
			1 ALLOT  	( push HERE up to the next CELL )
		THEN
		CDP !			( store the character at CDP )
		CDP 1+ is CDP		( increment CDP )
	;

	This code will sucessively store bytes contiguously, unless an
	ALLOT intervenes.  HERE will ALWAYS point to the next ALIGNED
	address regardless of the number of invocations of C,

	The ONLY time padding will occur, is if C, is followed by ALLOT,
	CREATE, or a : def'n ... otherwise, CDP points to the next available
	byte in the dictionary, and HERE points to the next available CELL
	greater than CDP .... when padding does occur, it will cost at most
	three bytes on a 32 bit machine (1 byte on a 16 bit machine).
>
>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

	don't be ... your interest makes you a peer!

>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

	The problem lies not with processors like the MC68000 family, 
	which allow byte aligment (as do Intel) but the MC88000 and other 
	RISC processors which REQUIRE word alignment (HP-PA, SPARC etc).
	This means code will CORE a Unix process running on such a RISC
	machine.

rss.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Sciuk	rob@innovus.com OR rob@innovus.on.ca
Innovus Inc.	204-200 James St S. Hamilton, Ont. 	Phone:	(416) 529-8117 
		{not a flame ... merely a glimmer ...}	Fax:	(416) 572-9586	
