🚀 go-pugleaf

|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.