Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!cica!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
Summary: Contribution from Phil
Message-ID: <5471@pt.cs.cmu.edu>
Date: 10 Jul 89 23:37:34 GMT
References: <5470@pt.cs.cmu.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 110

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