toma@tekgvs.UUCP (Thomas Almy) (11/11/86)
In article <608@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >If one were to use the portablilty of Forth to advantage, a mostly portable >"Forth Enhancer" tool could be created to optimize the Forth implementation >based upon the underlying architecture of the processor it's targeted for. >Given particulars on the machine and the level of performance necessary, the >"Enhancer" would take existing Forth code (including Forth or itself, if >desired) and reconstruct it in an optimized form. > >If the "Enhancer" could be written in a portable form, it could give all >implementations of Forth and Forth-like languages the key to the trade-off of >speed versus compactness/portablilty. > >I know that many people have written optimizers and native code compilers - >how about a generic, portable one! > Well I am an author of the Native Code Compiler sold by Laboratory Microsystems for their Z80 and 8086 Forths. Versions have been available for both their current 83 Standard Forths and for their earlier Fig Forths. There is also a version for their 32 bit PC/Forth+ (on IBM PC). I also sold the Z80 version with my own direct threaded code Z80 Forth. And I ran my first, simpler version under MMS Forth for the TRS-80 (Z-80) which was a 79 Standard system. While the logic of the programs is portable, there are considerable differences: 1) The different processors require different code emitters. For optimum performance, a large percentage of the design effort needs to go into the code emitters. 2) The compilers require intimate knowledge of the host dictionary structure, threading technique, and register usage, which hampers portability. 3) Differences in the Forth Standard can make a big difference in compilation techniques. In moving to the 83 standard, for instance: a). The definition of signed division does not match that of any processors divide instruction, forcing the generation of code calling a divide subroutine. Yet unsigned division can be done inline. Signed division by constant powers of two can now be done with shift instructions (they could not in previous standards). b). The definition of the LOOP termination condition is so generalized that the code is much less efficient that that required previously. To make up for the loss, the 83 Standard versions do a loop analysis, and try to build a less general code sequence. The best case is a loop which uses the LOOP instruction of the 8086, or the DJNZ instruction of the Z-80, but several possible code sequences are available. The resulting compiler generates tighter code than any C compiler (or any other language for that matter) that I have seen, but the expense is that it is highly optimized for the processor and implementation. I still might do a 68000 some day, though. Tom Almy (Note: the above work is not connected with my employer, Tektronix.)