Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman From: koopman@a.gp.cs.cmu.edu (Philip Koopman) Newsgroups: comp.lang.forth Subject: Re: Postscript & stack machines Message-ID: <5470@pt.cs.cmu.edu> Date: 10 Jul 89 23:33:10 GMT Organization: Carnegie-Mellon University, CS/RI Lines: 95 Mark Martino and I are corresponding about how to support Postscript on stack machines. He can't post, and I can't reach him by e-mail. So, I'll be posting both sides of the conversation to communicate with him, and because I think the discussion might be interesting to others (it's not as if we're overloaded on this bboard!) ____________________________________________________________ Return-Path: Date: Mon, 10 Jul 89 10:06:48 PDT From: mtk!marmar@beaver.cs.washington.edu (Mark Martino) To: a.gp.cs.@pt.cs.cmu.edu Thanks for responding on this topic. I had the opposite problem as you did so I'm trying to send this e-mail. > 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. Mike Wood, an application engineer specializing in the 80960 from Intel, told us that their studies of PostScript and PostScript files showed that the processing time was divided this way: 20% - 30% Floating point calculations 40% - 50% Character generation 5% - 10% Bit-blting It should be noted that it was in Intel's best interest to reduce the importance of bit-blting, however after we had designed a bit-blting chip one of our previous printer controller designs, we found that we used it so little, we left it off in the final design. > 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. We have an ASIC that is sort of an "everything-but-the-kitchen-sink" kind of design, but it's main function is engine control. I'd like to try to put at least some of its functions onto the main processor chip. > 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. The page buffer ( or frame buffer if you're from the video world ) takes up at least one megabyte, and this cannot be reduced by using a different processor. However, the PostScript interpreter (300 Kbytes) and other program code in the ROM, could, I hope, be reduced in size. Also, I hope we could use less system RAM because of smaller code size. > Also, do you need the Postscript chip AND a 68030, or just > a single stack processor to run the entire system? I thought a stack processor would be a good solution because we are very concerned about system complexity and system cost. Reliablity is a big deal at Tally and the less parts you have, the less can go wrong, usually. > 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. The operand stack in PostScript, as I understand it, is actually a stack of eight byte cells. Even an integer takes up eight bytes. The execution stack controls which operator or procedure gets executed next, but it is not like the return stack in Forth. The graphics state stack and dictionary stack have fairly large cells, but they are not accessed as often as the other two stacks. Are there easy and cheap ways to modify or add to existing stack processors to handle these differences? If there were, this would be an easy way of developing inexpensive PostScript processors. Before PostScript saw the light of day, I thought about using Forth to create an extendible graphic language for artists. At the time, I was still heavily entrenched and educated in hardware, so I didn't pursue it very far. I've used PostScript and I really like it. I vacillate between thinking that there's no use reinventing such an elegant wheel and thinking that a more Forth-like language would be faster and smaller and more fun for artists. What do you think? The fun part is really important to me because I started out as a graphic artist with a BFA in Visual Communciations. The expense and slowness of affordable graphic software written in C gets in the way of visual experimentation. The write-compile-test cycle is inhibiting if you can program and if you can't, you're limited to the functions a graphic program provides. Thanks for your advice. This is the most insightful discussion I've had so far on this topic.