koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/07/89)
--- email didn't work, and this may be of general interest anyway. From: Philip Koopman <koopman> Message-Id: <8907071154.AA21968@greyhound.ece.cmu.edu> To: marmar%mtk%thebes%sumax@beaver.cs.washington.edu Subject: Postscript & stack machines > Over the last three years I've presented the idea of building an image > processor with a stack machine and writing PostScript for it. No one I've > worked with is familiar with Forth or stack machines so I got either blank > stares or giggles. Except for your brief mention of it in your book, I > haven't seen or heard of anyone else considering the idea. I mentioned > the idea to a guy named Snow at CPTM and he seemed to think that using > a stack processor and Forth would not make much of a difference in > PostScript performance. CPTM wrote a PostScript interpreter in Fifth so > I suppose they know what they are talking about. > Am I missing something? Wouldn't a stack based, threaded language like > PostScript benefit from running on a stack machine? Please answer soon > so I can get some sleep and get on with my career. There are a number of issues here, so this gets sort of complicated. I'll try to address the more important ones, in no particular order. Postscript spends most of its time doing bit-blt operations and coordinate transformations. These have nothing to do with the stack-ness of the processor or the software. In the past, stack machines have not been noted for super numeric performance, but this will probably change in the future. An advantage to a stack machine is that there may well be room left over on the chip to put on support hardware for graphics operations. If you want to build affordable Postscript systems (*especially* for display postscript, where every CRT gets a processor), then you need to keep system costs down. Buying a Motorola 88000 at $1500 - $2500 per chip set is not a good way to do this. It possible likely that a specially-designed Postscript chip (I believe AMD recently came out with one) will be faster than a general-purpose stack processor. However, the Postscript chip will probably cost more, at least at first, and will be much less flexible. It all depends what your tradeoffs for design are. An important issue is how much time does a typical Postscript program spend in interpretting programs (Forth processors win here) vs. time spent doing bit and transformation operations (Forth processors do not have an inherent advantage there). Also, do you need the Postscript chip AND a 68030, or just a single stack processor to run the entire system? Postscript is a stack-based language, but the semantics of stack usage are sufficiently different from Forth that Forth may or may not be an advantage in implementing it. Snow & company used a Forth derivative because it gave them a good interactive environment, and all the other reasons Forth is good for software development. I don't think the stack-ness of Forth helped them all that much. Adobe does all their work in C. So, why use a stack processor for postscript? I'm still considering this to some extent, but the initial reasons are cheaper system cost and extra room on the chip for special hardware support. Absolute performance is not always the goal, for Postscript engines I think performance for a given price is more important. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 Senior scientist at Harris Semiconductor, and researcher at CMU. I don't speak for them, and they don't speak for me.
Philip.Koopman@livewire.FIDONET.ORG (Philip Koopman) (07/08/89)
-- Philip Koopman - via FidoNet node 1:362/130.0 UUCP: ...!tiamat!livewire!Philip.Koopman INTERNET: Philip.Koopman@livewire.FIDONET.ORG