Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!rutgers!rochester!ken From: ken@cs.rochester.edu (Ken Yap) Newsgroups: comp.lang.postscript Subject: Re: FPU for PostScript Message-ID: <1990Jan9.182332.8554@cs.rochester.edu> Date: 9 Jan 90 18:23:32 GMT References: <1666@intercon.com> <17582@rpp386.cactus.org> <1990Jan9.044252.18617@ico.isc.com> <1990Jan9.170357.25101@ux1.cso.uiuc.edu> Reply-To: ken@cs.rochester.edu Organization: University of Rochester Computer Science Department Lines: 82 Address: Rochester, NY 14627, (716) 275-1448 |Adobe's business is BUSINESS - i.e. profits, as is that of printer |makers. Whether a FPU is worthwhile depends on how much more money |it will make for them, and a faster printer might not sell enough more. |Its complicated. Why don't we base this discussion on something more substantial? I repost an article I saved. Hope this leads to better discussion. From: adobe!taft@decwrl.DEC.COM (Ed Taft) Date: 18 Feb 1986 1750-PST (Tuesday) Subject: Hardware support for PostScript Several people have suggested hardware enhancements (e.g., faster CPUs, RasterOp chips, etc.) to improve the performance of PostScript printers. Naturally, this is a topic of great interest to us at Adobe. I'd like to share a few of our current thoughts with you. Please note that I am talking only about current products; I am not speculating about future ones. Adobe's approach to PostScript has been first to define a fully general software model for the programming language and page description capabilities and only then to consider how hardware can be employed to accelerate the software. Experience with a pure software implementation of PostScript (of which the LaserWriter is a good example) gives us an understanding of what parts of the implementation would benefit most from hardware support. There are three major activities that together account for most of the execution time in Adobe's implementation of PostScript. These are: (1) Low-level raster manipulations, principally painting character bitmaps and filling trapezoids located at arbitrary bit boundaries. For typical pages, this activity dominates everything else if all characters are already in the font cache. (2) Character scan conversion. This is a very compute intensive operation because the original character definitions are at a high level and are being pushed through the full PostScript graphics machinery. In particular, there is a lot of arithmetic, both fixed and floating point. (3) PostScript input scanning and interpretation. This includes parsing the input stream, constructing tokens, looking up names, pushing and popping stacks, etc. The amount of time consumed by this activity varies considerably according to the type of page description and the programming style. A text document that consists primarily of strings and calls to simple PostScript procedures consumes relatively little time in the interpreter; a document that executes a lot of PostScript code for each mark placed on the page consumes proportionately more. Of course, I have deliberately left out time spent waiting for input data or waiting for the print engine. The effect of a slow communication channel or a slow print engine can completely dominate everything else. More to the point, obtaining the best performance requires the ability to perform communication, execution, and printing activities in parallel. The above three activities benefit from significantly different kinds of hardware support. (Of course, in a strictly software implementation, a faster CPU should speed all three activities.) Considering them in order: (1) Simple hardware for shifting and masking makes a substantial difference here; the full generality of RasterOp is not needed. The idea is to minimize the number of CPU instructions and memory cycles needed to perform simple, repetitive bit moving operations. A shifter-masker is included in the Adobe Redstone controller, versions of which are used in all present PostScript printers except the LaserWriter. This activity is one that would benefit greatly from having a separate, parallel processor; its interface with the rest of PostScript would be quite simple. (2) Efficient arithmetic is of particular importance here. Also, since a vast amount of code is being executed and all of it is written in a high-level language (C in the case of Adobe's implementation), the overall quality of compiled code is important. Apart from arithmetic, no single component dominates, so it's not practical to assembly-code much of it. (3) Here is a place where some special hardware and/or microcode might help. The PostScript interpreter's data structures and algorithms are sufficiently straightforward that custom hardware may be practical. Whether or not this makes sense economically depends on how much time is spent in the interpreter relative to everything else, which, as I said, is highly application dependent.