Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!SUN.COM!wmb From: wmb@SUN.COM Newsgroups: comp.lang.forth Subject: Re: Multiple Stacks Message-ID: <8906010150.AA11289@jade.berkeley.edu> Date: 1 Jun 89 01:42:40 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Forth Interest Group International List Organization: The Internet Lines: 51 > I was trying to think of a way to separate out the > different types of PostScript objects instead of putting them all on > the operand stack. I don't know a lot about the innards of PostScript, If you separate the PostScript object stack into several "single data type" stacks, you will run into the problem that a "generic" operator like "+" can no longer easily determine which values to operate on. Solutions: a) keep a separate "type stack" which maps the single "logical stack" into several other stacks. This is undoubtedly more expensive both in space and time than having 8-byte stack entries. b) Eliminate generic operators, using either 1) A full set of mixed-type operators, 1 for each pair of types or 2) A set of type conversion operators which "promote" objects of one type to the "higher" type, so that the operator for the higher type can be used. This is what Forth does when you want to add an integer to a floating point number; you convert the integer to a float and then add with F+ In some cases, it may be possible to determine the data types at compile time, thus allowing the use of generic operators at the source code level, which compile to single-type operators. In a full PostScript environment, this is clearly not always possible, because name binding is done very very late in PostScript. The overhead for 8-byte stack entries in PostScript is no big deal. Run-time switching of generic operators is worse. > I don't know if a stack has to be pushed and popped by > the same increment all the time or if it can somehow handle different > sized objects directly. It is certainly possible to deal with different-sized objects on the same stack. It is probably not worthwhile though. > but I'd like to create a graphic language for > artists that is faster and takes less memory than PostScript. My gut feel is that the PostScript language interpreter and the stacks aren't prohibitively large. The large number of wonderful graphics operators is what takes up the space. James Gosling, the implementor of the NeWS window system (which was probably the first non-Adobe implementation of PostScript), told me that he spent about a week on the PostScript language interpreter and about a year on the graphics.