Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!ENG.SUN.COM!wmb From: wmb@ENG.SUN.COM (Mitch Bradley) Newsgroups: comp.lang.forth Subject: Re: Why is Postscript not Forth? Message-ID: <9002121713.AA24890@jade.berkeley.edu> Date: 12 Feb 90 04:42:32 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Mitch Bradley Organization: The Internet Lines: 99 Speed PostScript is inherently slower than Forth for several fundamental reasons: 1) Operator overloading. Many of PostScript's basic operators operate on multiple data types. The operator (e.g. "add") must test its operands at run time and decide what how to handle them. In some cases, it may be possible to optimize some of this at compile time, but the compiler's ability to do so is somewhat compromised by the default late binding (see 3), and the "visibility" of innards of the compiled procedure. 2) "objects" on the stack. Each items on the PostScript stack is a typed abstract object, rather than a programmer-visible collection of bits. The objects must be decoded at run time; you can't just pop the PostScript stack and execute the processor's "add" instruction, like you can do with Forth on most machines. Items 1 and 2 could be summarized by the phrase "strong typing enforced at run time". 3) Late binding. By default, the association between keywords and their actions is determined at run-time, rather than compile time. This causes a dictionary search (usually accelerated by hashing) every time that a keyword compiled into a procedure is executed. The late binding can be overridden, but most programs do not choose to do so. In contrast, Forth uses early binding by default, and the programmer must go to extra effort (like using execution vectors or (non-standard) DEFER words) to get late binding. 4) Virtual machine. Forth proponents argue about whether or not Forth is a virtual machine. In PostScript, you have basically zero direct access to the real machine, so it is clear that you are programming a virtual machine. Many or most of Forth's basic operations map very closely onto the real hardware. 5) Floating point. This is a performance hit, but it's not as bad as you might think. First of all, fast floating point hardware is becoming more and more "standard". Secondly, some PostScript implementations manage to avoid the use of floating point arithmetic in most cases. The PostScript implementation upon which the NeWS window system is based uses scaled integer arithmetic (with a fixed binary point) in most cases, switching automatically to real floating point only when the numbers do not fit comfortably in the scaled integer range. Size If you separate out the graphics functions from PostScript, the language you have left is still a functionally-complete and useful language. It is probably not much bigger than a Forth implementation with equivalent features (such as error handling, file access, and floating point). Please don't interpret this as "PostScript bashing". I really like PostScript; I think that it is a beautiful and elegant language. It is significantly more consistent in its reverse-polish orientation than is Forth. PostScript addresses many real problems that Forth "sweeps under the rug" (like what really happens when an error occurs). On the other hand, Forth is inherently more efficient on today's hardware, because it is less abstract. The bottom line: Use Forth for what it is good for and use PostScript for what it is good for. Each is valuable in its own domain. Which brings up the question: What if we had a language with mostly PostScript syntax, but Forth "real machine, not overloaded" operators and "early binding" semantics? That would be a nice language. But does the world need yet another language that will not succeed for lack of a market? Nope. Aside: Forth: Virtual Machine or not? There is a hot debate about whether Forth should be a "virtual machine" or a "high level assembler". The essence of this debate is: "Should the bit-level details of how the dictionary is implemented be specified or not specified". "virtual machine" advocates answer "yes", "high level assembler" (a poor name, by the way) advocates answer "no". (I answer "no"; you may wish to take my further comments with a grain of salt based upon that admission). Anyway, the inherent performance advantage of Forth over PostScript is largely due to its "real machine" orientation. Specification of Forth compilation in terms of a virtual machine model can negate some of those advantages. For example, implementation of the traditional Forth virtual machine in many modern system environments requires the use of logical addressing, where an address on the stack is not a native machine address. Many of the advantages cited by "Forth virtual machine" proponents apply more strongly to PostScript than to Forth. Mitch