wsbusup4@rwa.urc.tue.nl (Jan Stout) (05/16/91)
B15>I.2.4 Alignment Problems B15> ... B15> An implementor of ANS Forth can handle these alignment restrictions B15> in one of two ways. Forth memory access words (@,!,+!,etc) could be B15> implemented in terms of smaller width access instructions which have B15> no alignment restrictions. B15> ... B15> Although this conceals hardware ugliness from the programmer, it is B15> inefficient. B15> An alternative implementation of ANS Forth could define each memory B15> access word using the native instructions that most closely match B15> the word's function. B15> ... B15> In this case responsibility for giving @ a correctly aligned address B15> devolves on the programmer. B15> A portable ANS Forth program must assume the worst case and use the B15> alignment operators described below. B15> ... The fundamental issue raised in Forth implementations on machine architectures with alignment restrictions, is whether to aim for maximum space efficiency (solution 1) or to aim for maximum speed efficiency (solution 2). Dependent on the kind of application either of the solutions may result in better performance of a particular application. This suggests that the programmer (or even the user!) of the final application is best suited to make the space vs. speed decision. However B15 leaves the decision to the implementor of the Forth system. Big deal?! Well, yes ... because in order to let the implementor make that decision B15 supplies him with 2 Core Words (ALIGN & ALIGNED) that must be used by portable ANS Forth programs. Besides breaking existing code (already mentioned by MB) this 'solution' places the alignment-burden on ALL PROGRAMMERS, including those that do not use alignment restricted hardware. Unfair would be the least to call this; in order to let some ppl have the advantage of a speedier Forth, all the rest should suffer from ALIGNment indigestion. But should we then force implementors to chose the first solution? In priciple yes, but this sounds worse than it actually is: My suggestion would be for Forths on aligned machines to both implement the space as well as the speed efficient versions of the memory access words. Furthermore when dealing with the speed efficient words the character unit should be cell-size so every operator would keep addresses aligned. Different wordlists should be used for the two kinds of definitions; the space efficient words could e.g. be kept in SMALL, whereas their speed efficient counterparts would reside in FAST. Now when a program is ported from a non-aligned to an aligned environment, the programmer can first select the appropriate versions by executing SMALL or FAST, resulting in either small or fast compiled code. I'm sorry for LZ because he had to enter the whole Alignedness into the basis document , but I would be even more sorry if hardware patches like ALIGN(ED) would enter the standard. For after all who knows in X years alignment restrictions may no longer be relevant, but because some ppl in the 90s thought they were, Forthers are still aligning their datastructures. Jan Stout, wsbusup4@urc.tue.nl