Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!willett!ForthNet From: ForthNet@willett.UUCP (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: HS/Forth Message-ID: <693.UUL1.3#5129@willett.UUCP> Date: 22 Mar 90 02:43:08 GMT Organization: Latest link in the ForthNet chain. (Pgh, PA) Lines: 37 Date: 03-20-90 (21:48) Number: 56 (Echo) To: BILL MCCARTHY Refer#: 55 From: JULIAN NOBLE Read: NO Subj: FORTE Status: PUBLIC MESSAGE Dear Mr. McCarthy, I have checked your timings and of course you are correct. The code produced by the FORTRAN module of FORTE is slow compared with working directly with the co-processor. There are several reasons for this: 1. In order to optimize FORTRAN, you need to know the types of variables at compile time. 2. The IFSTACK module, that manages the software floating stack, has not been optimized. All the memory transfers are bytewise, e.g. And a lot of memory thrashing is needed. Think of the IFSTACK (which is the main bottleneck -- the generic operators produce relatively little speed penalty) as a pedagogic tool and/or a convenience. The proper way to do it would be to extend the hardware stack on the 80x87 chip into memory. Unfortunately, as Palmer and Morse note in The 8087 Primer, the instruction set gives no hooks for easily extending the 80x87 stack. All the approaches I have tried so far have been pretty cumbersome. So FORTE is not intended to produce optimized code. If you need speed, you hand-code the inner loops. FORTE lets you do quick-and-dirty cal- culations easily, a la interpreted BASIC. I am rewriting FORTE to reduce its code size and workspace. I will put some effort into the generic data stack manager to reduce the speed penalty, if people are interested. Best regards, Julian V. Noble (bitnet JVN@VIRGINIA) ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'