Mitch.Bradley@ENG.SUN.COM (Mitch Bradley) (06/05/91)
In a threaded code implementation, the penalty for arbitrary-alignment @ and ! operators is relatively small. In an optimized native-code system, where you are really pushing for speed, the situation is somewhat different. @ and ! are often expanded in-line on those systems, and peephole optimization can frequently combine the access with nearby calculation steps and/or arithmetic and logical operators. The requirement for arbitrary alignment support makes this much more difficult, and the compiler is considerably less likely to succeed in generating excellent code. I ran into this problem when I wrote a translator program that would convert 68000 binary code into SPARC binary code. 68000's are 2-byte aligned, and SPARC's are 4-byte aligned. The alignment problems made the generated SPARC code much worse in the general case, and caused me to go to a lot of trouble to get the translator to guess about actual alignment at compile time. My experience with Forth programmers is that many of them want to be able to get the most out of their hardware, and are willing to go to a bit of extra programming effort to get it (e.g. by adding ALIGNED at judicious places in their code). Mitch