koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/11/89)
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: <sumax!thebes!mtk!marmar@beaver.cs.washington.edu> 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.
koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/11/89)
> .... bit-blting isn't important .... > 20% - 30% Floating point calculations > 40% - 50% Character generation > 5% - 10% Bit-blting Forgive me -- I sloppily included character generation in my estimate for bit-blting (I've been doing HP Laserjet graphics too long, where characters are simply bit-blts) I know Postscript outline fonts can get more interesting. But, the original argument holds unless you can show character generation is a stack-y operation. Now, floating point calculations get more interesting. Are they flow-through calculations, or repeated calculations on the same data point. In other words, how many floating point operations on each piece of data fetched? I'm looking at designing a processor that is very good at highly local computations, and so can have few pins and a correspondingly lower cost. We are seriously considering putting a *very* fast floating point ALU/Multiplier on the 32-bit stack machine. > 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. Yes, but $2000 RISC chip sets and cache memories are not cheap either.... So, system costs can be reduced somewhat. It appears that stack-based programs can be 10% to 50% of the size of corresponding RISC programs, depending on coding style. Subroutine re-use & factoring = small code. Of course, you can compress the data for a laser printer, and probably save a lot. You just need a processor fast enough to decompress it in real time as the paper is moving (with guaranteed response time!) We aren't ready to do the decompression at video rates just yet... > 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. Yes, I agree. Harris is moving to provide highly integrated systems, with lots of on-chip functions. Reliability is a part of it. Also power (driving pins can take a lot of power), for embedded systems that worry about power consumption. > The operand stack in PostScript, as I understand it, is actually a stack > of eight byte cells. Even an integer takes up eight bytes. Easy -- use double precision. > The > execution stack controls which operator or procedure gets executed next, > but it is not like the return stack in Forth. I'm afraid I don't understand how this stack works. > The graphics state stack > and dictionary stack have fairly large cells, but they are not accessed > as often as the other two stacks. This could be handled with an on-chip stack frame pointer. > 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. Probably, but I would have to think about it some more. One of the problems I have heard of is that Postscript pushes whole bunches of data onto the stack at once (e.g. array elements). This overruns on-chip stack buffers, causing lost time to do the spilling. If these poorly behaved stacks were kept in memory with on-chip stack pointers, then perhaps things would be nicer. > 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? I think that some experiments along these lines were done way back when (say, 5-10 years ago), but I forget the reference, and they weren't all that fancy. A Forth-based language would probably be faster, especially on stack hardware. Sounds like fun, why don't you give it a try? > 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. I learned graphics programming using a FORTRAN subroutine library. I know *exactly* what you are talking about! Of course, Forth is good for other types of software for similar reasons. Another advantage of Forth is that you can build "smart" data structures, and so teach the compiler what graphics means, instead of: call move(x,y); call draw(x,y); ..... I am really not very knowledgeable about Postscript, so I hope these answers are somewhat helpful. My strong point is hardware design. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/11/89)
Date: Mon, 10 Jul 89 16:10:20 PDT From: mtk!marmar@beaver.cs.washington.edu (Mark Martino) One other thing Phil... I forgot to mention this in my last message: PostScript, like Forth, promotes the use of a number of small, reusable, routines. And, like Forth, if it is run on a traditional processor, the calls to subroutines and the returns from subroutines make it seem slow and clumsy. Like Forth, I think that PostScript can benefit from processors that allow zero clock cycle returns. This is probably the single most important reason for using a Forth processor and writing PostScript in Forth. Thanks again for the exchange of ideas.