ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/29/91)
Category 10, Topic 36
Message 20 Sun Apr 28, 1991
R.BERKEY [Robert] at 05:23 PDT
----------------------------------------------------------------------
Essay on X3.J14 Address Alignment
"Imposing an even-address alignment requirement could simplify
an architecture's implementation, but only at the expense of
more difficulty for the programmer (and compiler), and reduced
efficiency of memory utilization for data and instruction
storage. For example, consider a record declared to contain
two elements, one of which is byte-sized and the other
word-sized." (Colin Hunter, _National Semiconductor Series 32000
Programmer's Reference Manual_, Prentice-Hall, Englewood Cliffs,
NJ: 1987.)
Forth-83 specifies that @ ! and +! work independently of underlying machine
architecture.
The X3.J14 committee puts forth that there are machine architectures for
which implementors cannot provide optimally-efficient memory-access operators
within the scope of the Forth-83 standard. X3.J14 proposes to redefine the
memory-access operators such that @ ! and +! are, at the implementor's option,
functions of the underlying machine architecture. However, exposure of
programs to the underlying machine architecture means that there are addresses
which if accessed result in failure of the program. So, the introduction of
these new definitions of @ ! and +! brings the addition of the words ALIGN and
ALIGNED to the Core word set, and a set of procedures which programs must
follow involving ALIGN and ALIGNED .
------------------------
This proposal has multiple problems.
(1) Absence of technical necessity
This change may be seen as a "naming jealously" issue--there exists no
technical necessity for the change. (I define "naming jealously" as the bias
of Forth standard's committees to prefer to "fix" an existing function rather
than also add to the task the problem of getting concensus on a new name.)
(2) Existing code would be broken
The X3.J14 proposal would break numerous Forth programs ("broken code" is
that which is compliant with the previous standard, but which is non-compliant
with the new standard, and thus can no longer be relied upon to port between
Standard Systems).
(3) Conflicting implementation alternatives
Implementors on systems with memory-access limitations are presented with
the issue of choosing between:
(3A) speed-optimized @ ! and +!
(3B) space-efficient, bus-error free, Forth-83 compatible @ ! and +!
(3C) providing both sets of operators, with the names @ ! and +! assigned
to (3A) definitions
(3D) providing both sets of operators, with the names @ ! and +! assigned
to (3B) definitions.
These last two elections add the issue of what names to assign for the
alternate set of operators.
Some architectures don't have memory-access limitations, but aligned-
address access has some efficiency benefits. On these systems, implementors
will have unclear decisions regarding ALIGN and ALIGNED . Should ALIGN and
ALIGNED be
(3E) immediate noops and space-efficient, or
(3F) active operations?
(more considerations--the time it takes to execute ALIGN and
ALIGNED may well result in less overall program speed efficiency
than the benefit gained from bus alignment)
(4) Chaotic impact on standard/common programming technique.
The (3F) implementation alternative provides defacto encouragement to
programmers to use non-standard programming technique for routine
implementation-specific coding.
For machine architectures not listed above, ALIGN and ALIGNED will be
immediate noops. It seems unrealistic to anticipate that implementors; on
either these systems; or for (3B), (3D), or (3E) systems; will encourage
programmers to use standard programming technique; and that all Forth
programmers will begin using such technique.
(5) Loss of entitlement to space-efficient programs
Under the new BASIS definitions, space-efficient programs can be designed
only with considerable speed-efficiency loss in implementing the Forth-83
style definitions in high level.
(6) Taxation without representation
While Standard Programs must carry the burden of coding for the new
technology, implementations may choose or need to remain Forth-83 compatible:
so BASIS doesn't guarantee programs to the benefit of the new technology.
----------------------
All because of a few names.
X3.J14 should provide new names for the new operators.
This gives clear guidance to implementors, and also allows programmers to
optimize for either space efficiency or execution efficiency. All of the
problems cited above are eliminated.
----------------------------------------------------------------------------
-----
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!dwpMitch.Bradley@ENG.SUN.COM (05/02/91)
> The X3.J14 proposal would break numerous Forth programs ("broken code" is > that which is compliant with the previous standard, but which is non- > compliant with the new standard, and thus can no longer be relied upon to > port between Standard Systems). My definition of "broken code" is somewhat different. I am not too concerned about breaking existing "standard programs". This may seem surprising, but here is my reasoning: 1) There aren't many existing "Forth 83 Standard Programs". I have seen a few, but not many. 2) Of the few I have seen, none has any "economic momentum" behind it. "Economic momentum" is when a company has spent a million dollars developing and supporting a program. The "breaking code" scenario that concerns me more is the following: 1) Vendor "x" has some number of customers, each with substantial investments in their existing applications. 2) The new standard imposes a requirement that vendor "x" cannot meet and still remain compatible with his customers' existing code. The "breaking vendors" scenario would have these effects: a) Such vendors would have a disincentive to implement the new standard. b) A substantial number of vendors probably would not implement it. c) The Forth world would become even more fragmented. A strong goal of ANS Forth is to make it as easy as possible for existing implementations to migrate to the new standard, thus encouraging widespread availability. The focus is on not requiring vendors to break their customers' code, rather than on ensuring that ANS Forth is a strict upward-compatible superset of Forth 83. ANS Forth imposes some usage restrictions that Forth 83 did not impose. Implementations are not required to enforce those restrictions; the restrictions are instead guidelines for application writers who wish to achieve the widest degree of portability. Here is a partial list of things that a Forth-83 Standard Program could do, that ANS Forth does not guarantee are still portable (on a given ANS Forth implementation, there is a good chance that these things will work, but there is no guarantee): 1) Assume 16-bit stacks 2) Assume byte addressing 3) Use @ and ! with unaligned addresses 4) Change the length of the text input by storing inte #TIB It would be nice to develop a complete list. Additions to the list are solicited. Mitch.Bradley@Eng.Sun.COM
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/19/91)
Category 10, Topic 36
Message 22 Sat May 18, 1991
R.BERKEY [Robert] at 03:52 PDT
"All because of a few names." (from "Essay on X3.J14 Address Alignment",
GEnie Category 10, Topic 36, Message 20, 91-04-28)
<[wheels] S.WHEELER> I can ... <[wheels] S.WHEELER> guarantee you that many
simple things which will ... <[wheels] S.WHEELER> work on the 8088 and 80286
will kill a 68000 or 80196 ... <[wheels] S.WHEELER> as for example, non-
aligned addresses, which ... <[wheels] S.WHEELER> have become subject to a
flurry of messages lately ... <[wheels] S.WHEELER> by PC-based programmer who
don't want to be restricted ... <[wheels] S.WHEELER> in what they do, but seem
to have no care that the ... <[wheels] S.WHEELER> requirement for aligned
addresses will allow a ... <[wheels] S.WHEELER> standard portable across
processors.
(from "Minutes of a special GEnie Forth RoundTable Conference with Bradford
J. Rodriguez", BRAD-R.TXT, GEnie Forth Software Library, Date: 05/16/91)
As the author of a recent message on address alignment I choose to rebut S.
Wheeler's above-quoted comments. The message "Essay on X3.J14 Address
Alignment" takes no position on the benefit or non-benefit of aligned
addresses. Rather it cites "name jealousy", and notes that the complex of
portability problems involving X3.J14's proposal for address alignment is
resolvable by standardized names for aligned address operators.
By inference, "Essay on X3.J14 Address Alignment" takes a position against the
non-standard usage of the @ word, as well as a position against de-
standardizing @ .
-----
Besides being an implementor of Forth's both with and without address
alignment requirements, I can cite professional programming experience with a
critical application need for speed optimization on a 68000. The situation
had AT&T withholding payment of a low-six-figure dollar amount due to non-
performance of a delivery agreement. The amount of difference that the speed
of implementation of @ could have made to the application level code in
fulfilling the contract was not a factor.
If the TC chooses to agree that inefficient programs are a problem in the
world, I think the most productive approach is toward a standardized timing
utility/capability that programmers can use to find critically slow sections
of code.
----------
Now, forgeting everything else that I've said here for a moment, I sense that
the deeper issue is, "Is Forth becoming a Tower of Babel?"
----------
Robert
-----
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!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/31/91)
Category 10, Topic 36 Message 23 Wed May 29, 1991 S.WHEELER at 21:26 MDT I understand Robert Berkey's point of view, and have some sympathy for it. What I do not have sympathy for, however, is being quoted out of context so that he can grind his axe. My comments were in response to Brad Rodriguez's comment that he had six versions of Forth on his system. In view of his proposal that six systems should be examined for common words to be used as a criterion for inclusion into the standard, my remarks (as quoted by R.BERKEY) were prefaced by a question as to how many SYSTEMS Brad had. If the problem is merely one of name jealousy (here raising the Sarcastic Roger flag - grinning skull and crossed funnybones), then I have no problem with implementing slower @ and ! operators on 68000s and other address- restricted processors if we can standardize on a full 32-bit Forth. Of course, 8088's, 6502's, etc. will have to take a small performance hit ... (strike the colors!). Actually, though, ALIGN shouldn't have much effect on run-time performance, since my understanding of it is that one would normally use it at compile time. In any case, 8086 processors take a performance hit (4 cycles/access) when making word accesses to odd addresses. I can't speak for 286's and up, since I don't have their data books. That may not make much difference, but I can just see a tight timing loop changing because someone changed a name from WAIT to DELAY :-). ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/02/91)
Category 10, Topic 36 Message 24 Sat Jun 01, 1991 B.RODRIGUEZ2 [Brad] at 18:02 EDT Well, as long as I'm being mentioned, I suppose I can respond... I _do_ have a problem with implementing slower @ and ! operators on 68000s, LSI-11s, and such. The problem with these CPUs is not just the 4-cycle performance hit experienced by the 8086. On the 68000 and LSI-11, word accesses to odd addresses are flat-out _illegal_. This means a 16-bit @ would have to be synthesized from two 8-bit fetch instructions. Gag. Also, judging by what I've learned recently in my architecture courses, this problem is not going to go away. Word access at odd addresses is a significant hardware investment and has an unavoidable timing impact. The trend these days, what with RISCs and all, is to simplify the processor and make the compilers smarter. - Brad Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/02/91)
Category 10, Topic 36 Message 25 Sat Jun 01, 1991 R.BERKEY [Robert] at 21:18 PDT Re: Address Alignment S. Wheeler writes, 91-05-19, sw> Actually, though, ALIGN shouldn't have much effect on run-time sw> performance, since my understanding of it is that one would sw> normally use it at compile time. In BASIS, ALIGNED must be used as a runtime operator, to match the compiled ALIGNments. sw> In any case, 8086 processors take a performance hit (4 sw> cycles/access) when making word accesses to odd addresses... sw> That may not make much difference, but I can just see a tight sw> timing loop changing because someone changed a name from WAIT to sw> DELAY :-). Ho! is that a good point. It's one the engineers here missed when they ported the application from the 8085 to the 80186. I've got an 80286 timing loop whose time variation between an odd and an even alignment is 20%! Here's a note in my files for an F-PC running on an 80286 system: \ Alignment of code words, execution routines, and vocabulary tables \ costs about $C0 bytes, and on an 80286 increases compilation speed \ by 2%. Robert ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/02/91)
Category 10, Topic 36 Message 26 Sat Jun 01, 1991 R.BERKEY [Robert] at 21:19 PDT Re: X3.J14 Address Alignment Proposal My experience with a must-align @ is that the cost in programmer productivity is greater than the benefit in processor optimization. The message, "Essay on X3.J14 Address Alignment" was a triggered by a portability failure reported by Jack Woehr, in comments to John Wavrik, dated 91-04-23: jw> John, WHAT ARE WE SUPPOSED TO DO? We could say, "`Comma' jw> compiles sixteen bits." WELL THAT DOESN'T EVEN WORK NOW! jw> My co-worker came into my office to complain to me about my jw> Forth for the 80C196. Seems he had an application from our Forth for jw> the 80188 that had jw> 1234 , 34 c, 678 , 9999 , jw> etc. scattered in an array. Of course it didn't run! The 80196 jw> enforces word alignment on 16-bit quantities! In the context of portability and address alignment, the issue here is what the name , (comma) should do, rather than technical issues. The point is that there are two valid concepts, logical and physical access. If it is inefficient to implement a logical fetch on a processor in assembler code, it can only be more inefficient to implement it in high level. Since physical-access addresses must be aligned, the savings for accesses using a physical name versus that using a logical name, is the assembly code for a bit test and a branch. A while back I posted a Forth-83 Standard Program called QUOTE-TO.SCR, stated that I was aware of aspects that were non-BASIS conforming, and challenged readers to see if they could detect problems. No one detected that the program fails to force address alignment. Also, it is an intermittent address- alignment failure that is affected by previous compilation alignment, rather than being a function of the data structure itself. In terms of conversion of existing code, the X3.J14 address-alignment proposal falls into one of the less-desirable categories that requires "human analysis" with "knowledge of the program structure". If the X3.J14 proposal is accepted: For existing code rendered nonconforming, such as QUOTE-TO.SCR and the Vesta- programmer's code, I think new names are needed for the logical accesses, but without X3.J14 providing the leadership here, this is back to reinventing the wheel. "Essay on X3.J14 Address Alignment" has cited multiple problems: (1) Absence of technical necessity (2) Existing code would be broken (3) Conflicting implementation alternatives (4) Chaotic impact on standard/common programming technique (5) Loss of Standard Program entitlement to space-efficient programs (6) Costs to Standard Programs without benefits However, the proposal is technically valid, and it can be used in a practical manner to write portable code. I do hope that analysts in the public review will consider rejecting this proposal. Robert ----- 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
Mitch.Bradley@ENG.SUN.COM (Mitch Bradley) (06/04/91)
> In BASIS, ALIGNED must be used as a runtime operator, to match the compiled > ALIGNments. I disagree. It is possible to perform the ALIGNED operation at compile time, storing the result either in a constant or in a definition with LITERAL . Here's how I do data structures: : STRUCT 0 ; : CELL: ( offset -name- offset' ) CREATE ALIGNED , CELL+ DOES> @ + ; : CHAR: ( offset -name- offset' ) CREATE , CHAR+ DOES> @ + ; STRUCT CHAR: >FIELDA CELL: >FIELDB CONSTANT /MYSTRUCT CREATE MYSTRUCT1 CHAR q C, ALIGNED 1234 , CREATE MYSTRUCT2 CHAR z C, ALIGNED 5678 , : .MYSTRUCT ( adr -- ) DUP >FIELDA C@ EMIT ( adr ) >FIELDB @ . ; MYSTRUCT1 .MYSTRUCT MYSTRUCT2 .MYSTRUCT This illustrates a fairly typical case in which alignment is required - user-defined data structures with mixed-size fields. All the alignment is done at run time. It can be done without the structure defining words: : .MYSTRUCT ( adr -- ) DUP C@ EMIT ( adr ) [ 1 CHARS ALIGNED ] LITERAL + @ . ; Note that the ALIGNED step is again performed at compile time. Mitch
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/08/91)
Date: 06-03-91 (12:21) Number: 99 of 102 (Echo)
To: B.RODRIGUEZ2 [BRAD] Refer#: 81
From: RAY DUNCAN Read: NO
Subj: MEMORY MANAGEMENT/PIC Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
>word access at odd address is flat-out illegal on the 68000
That's true, but it has to be allowed I think if Forth code is to be
portable. In our CP/M-68K Forth systems (long since dead & buried) we
took a compromise approach to this that didn't affect performance. We
word aligned everything in the Forth system, and had the @ and !
operators use the "obvious" (i.e. word-oriented) MOVE instructions.
However, we also captured exceptions that were caused by non-aligned
WORD accesses, figured out whether they originated within the @ and !
primitives, and if they did we would then decompose the @ or ! into the
appropriate byte-oriented MOVEs and resume execution. This is a
straightforward fix in a native Forth system or a Forth running under a
dumb environment like CP/M-68K, but it is impractical in more complex
environments since a lot of them won't let you handle these sorts of
machine exceptions yourself.
NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
<<<>>>
-----
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!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/10/91)
Category 10, Topic 36 Message 29 Sat Jun 08, 1991 B.RODRIGUEZ2 [Brad] at 14:17 EDT Hmmm... reading Robert Berkey's comments, I'm beginning to believe that _all_ existing Forth code will be rendered nonconforming by the BASIS. Does anyone have (nontrivial) counterexamples? I must admit I rather like Ray Duncan's solution to the problem. I hadn't thought of using the exception trap to resolve this problem. This is good for 68K and LSI-11; does the 80196 have such a trap? However, it's an oversimplification to state that only @ and ! are affected. I'm in the midst of converting a Super8 Forth from a RAM model to a register model, and you wouldn't _believe_ how many words do memory reference. Granted, many of them access stack (trivial to keep aligned) or threads (via IP). Should the dictionary (threads) be kept aligned, and not data? This has implications for those who would write IMMEDIATE words to extend the compiler (e.g., no 8-bit branch offsets). - Brad Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/14/91)
Date: 06-11-91 (12:43) Number: 138 of 138 (Echo) To: B.RODRIGUEZ2 [BRAD] Refer#: 122 From: STEVE WHEELER Read: NO Subj: MEMORY MANAGEMENT/PIC Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) The 80196 does not have any such exception vector for odd-address-aligned word accesses. The only thing the Intel manual states about them is that they are not guaranteed to work in a consistent manner. - wheels NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth! <<<>>> ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/15/91)
Date: 06-09-91 (13:57) Number: 139 of 145 (Echo) To: B.RODRIGUEZ2 [BRAD] Refer#: 122 From: RAY DUNCAN Read: NO Subj: MEMORY MANAGEMENT/PIC Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) >I rather like Ray Duncan's solution to the problem This was actually Joe Barnhart's solution to the problem, to give proper credit. Unfortunately or otherwise, Joe has moved on to C++ and SmallTalk programming these days. >will it work for the 8096/196 too Not sure about the 80196, but it doesn't work for the 8096. That machine gives you no warning at all if you make a word access on an odd boundary, but it returns garbage. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/16/91)
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
rob@innovus.uucp (Rob Sciuk) (06/18/91)
In article <2890.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes: >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) >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. I have implemented Forth-83 in C from the standard specification which runs on Intel, RISC, Motorola, and other proprietary platforms, many of which have strict alignment rules. Elizabeth points out that any standard defining word should take care to align words, (bodies, headers, and fields contained therein) on appropriate boundaries. Further, `ALLOT' and `,' should align on CELL boundaries, and `C,' should ensure that the next invocation of `HERE', `ALLOT', `,' etc. will utilize a CELL boundary appropriate to the processor [mine]. My solution was to maintain a separate byte aligned pointer for `C,' which is checked against the dictionary pointer. If not pointing at a cell boundary, the equivalent of an ALLOT is done, and two pointers, one for byte, and one for word allocation type words use are maintained. The byte pointer need be accessible ONLY from within the `C,' word itself. By having my language take care of this, I have clearly defined semantics (I'm the only user), and have increased portability of FORTH applications between machines. The following excerpted sequence will show the mechanism used ... (I apologize for posting C source, but the result should be clear). void zz_Ccomma() /* "C,", 0, ( 8b --- ) */ { if( !CDP || ( CDP == (UChar_ptr) DP ) || ( ( (UChar_ptr) DP - CDP ) > (sizeof(CELL) - 1 ) ) ) CDP = (UChar_ptr) DP++ ; *(CDP++) = (UCHAR) POP ; } Again, I don't want to get hung up on implementation details, but by having the language take care of this one little detail, an awful lot of porting headaches can be avoided (I'm in the porting business!). Elizabeth, forgive me if the BASIS 16 standard has addressed this, I have just printed it, and have not had time to read it just yet, but I do not believe that this was covered in the last BASIS I read (10). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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