rcd@ico.isc.com (Dick Dunn) (12/28/89)
woody@rpp386.cactus.org (Woodrow Baker) writes: > Actually, a Compiled version of PS is not unreasonable. Given a good > BNF of the language, YACC and LEX should make the parser a snap. The BNF of PostScript is so trivial it's (a) uninteresting and (b) unhelpful. The parser is a snap; it would be kinda dumb to use YACC for it. (Of *course* the parser is simple--that's one of the arguments for using a postfix stack-oriented language!) What you'll find if you really look at compiling PostScript (assuming you know about compilation) is that you aren't likely to gain much. All the good stuff happens in the operators. Given dynamic binding (which begets latent types as well), things are inexorably pushed off to run time. You can find lots of special cases, and make up a slew of special rules, and make a little headway. (For example, something common like "3 1 roll" can be generated inline since the operands are constants, if you know or make a rule that "roll" can't be redefined and can deduce that you won't get a stack underflow...) You might speed up typical processing by a few percent, no more, because the work all happens in the operators. But this is all old stuff to people who know about language implementation (including, apparently, the Adobe folk who designed the language). Lan- guages intended for interpretive execution are characteristically syntax- poor and operator-rich...and compiling them seldom gives you much. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
woody@rpp386.cactus.org (Woodrow Baker) (12/29/89)
In article <1989Dec28.000745.6265@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > woody@rpp386.cactus.org (Woodrow Baker) writes: > > > Actually, a Compiled version of PS is not unreasonable. Given a good > > BNF of the language, YACC and LEX should make the parser a snap. > > The BNF of PostScript is so trivial it's (a) uninteresting and (b) > unhelpful. The parser is a snap; it would be kinda dumb to use YACC for > it. (Of *course* the parser is simple--that's one of the arguments for > using a postfix stack-oriented language!) > > What you'll find if you really look at compiling PostScript (assuming you > know about compilation) is that you aren't likely to gain much. All the > good stuff happens in the operators. Given dynamic binding (which begets > latent types as well), things are inexorably pushed off to run time. You > can find lots of special cases, and make up a slew of special rules, and > make a little headway. (For example, something common like "3 1 roll" can > be generated inline since the operands are constants, if you know or make > a rule that "roll" can't be redefined and can deduce that you won't get a > stack underflow...) You might speed up typical processing by a few > percent, no more, because the work all happens in the operators. Amen. Being that we are dealing with a language that is not a context-free grammer, It does not make much sense to compile it. The language is idealy suited to interpretation. . > But this is all old stuff to people who know about language implementation > (including, apparently, the Adobe folk who designed the language). Lan- > guages intended for interpretive execution are characteristically syntax- > poor and operator-rich...and compiling them seldom gives you much. > -- > Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 > ...Mr. Natural says, "Use the right tool for the job."
pollack@toto.cis.ohio-state.edu (Jordan B Pollack) (12/30/89)
I just want to note that it is completely inconsequential whether or not the syntax of a programming language is context-free. The important thing for compiling is that run-time dependencies can be effectively circumscribed. Since postscript is most likely already implemented as threaded code, like forth, it is already compiled in some trivial sense. At the other end of the trivial spectrum, postscript is "compiled" when a showpage is executed, where the bitmap image of a page has lost all symbolic information about its own construction. However, there are many other notions of "Compiling" which are not captured by these simplistic notions. In particular, most modern compilers worry more about optimization than translation. Threaded code can be speeded up by being expanded into machine language control, in-line expansions and subroutine calls, which can lead to a time gain of 10% (in avoiding procedure calls and returns). Variables could be detected and replaced with stack operations. Invariant operations can be moved outside of loops. Short loops can be unrolled. Efficient registers could be allocated instead of stack space, and so on. However, postscript is a "throwaway" language, and any effort at such optimization probably wouldnt be very cost effective. To justify such a tremendous project (other than as a long-term way to silence an arrogant undergraduate hacker!) one would at least need a very large and slow postscript program which had to be run lots of times with complex and varying input. The only such program I could think of would be a postscript compiler written in postscript... -- Jordan Pollack Laboratory for AI Research CIS Dept/OSU 2036 Neil Ave email: pollack@cis.ohio-state.edu Columbus, OH 43210 Fax/Phone: (614) 292-4890
woody@rpp386.cactus.org (Woodrow Baker) (12/31/89)
In article <POLLACK.89Dec29135027@toto.cis.ohio-state.edu>, pollack@toto.cis.ohio-state.edu (Jordan B Pollack) writes: > I just want to note that it is completely inconsequential whether or > not the syntax of a programming language is context-free. The > important thing for compiling is that run-time dependencies can be > effectively circumscribed. true enough. > However, postscript is a "throwaway" language, and any effort at such > optimization probably wouldnt be very cost effective. To justify such > a tremendous project (other than as a long-term way to silence an > arrogant undergraduate hacker!) one would at least need a very large > and slow postscript program which had to be run lots of times with complex and > varying input. The only such program I could think of would be a > postscript compiler written in postscript... Right. An impossiblity. You can't generate machine language if you wanted to. Several other of the net readers have suggested that a PS compiler written in PS would be the real test. When someone writes one let me know. Go find an undergraduate hacker somewhere and give him the job. My degree was issued in 1980.....
rcd@ico.isc.com (Dick Dunn) (12/31/89)
woody@rpp386.cactus.org (Woodrow Baker) writes: [deleted 14 included lines of my comments about how simple a PostScript grammar would be] > Amen. Being that we are dealing with a language that is not a context-free > grammer, It does not make much sense to compile it... Woody, if you're going to agree with me, could you at least agree with something I said (instead of the exact opposite)?!? It's trivial to write a context-free grammar for PostScript. And that's not the reason for not compiling it. Assume a lexer which will recognize the tokens (identifiers, names, strings, numbers, etc.) of PostScript. The grammar, in some typical eBNF, probably looks about like this: <PostScript-program> = <chunk>* <chunk> = <token> | '{' <chunk>* '}' I was profligate of rules, using two where one would suffice, in order to show the likely two-state character of the parser (which corresponds to the interpreter) and make things look nicer. Not that no attempt is made to identify or parse operators, since in the general case none can be made. Also note that the grammar only matches braces, not brackets, since brackets need not match in the textual structure of the program...their matching is dynamic. [Noted in passing: Probably the "bind" operator does the most useful part of what a PostScript compiler might do.] -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
woody@rpp386.cactus.org (Woodrow Baker) (01/01/90)
An interesting problem was just described to me. It seems that the fileforall operator has a minor bug in it. As it enumerates the files on the disk (if you have a NTX), it leaves a copy of the file name on the stack. 512 files later, kablooie. The solution of course is to redifine it so that it does a pop after each call to get the filename. The problem apparently does not show up unless you have over 512 files of the disk. One of Don's clients got bit by that one, and Don dug around until hi found it. Watch for a ***VERY*** interesting article to appear shortly in Byte magazine. Something to experiment with: proc caching. you can fool the font machinery into caching the result of a proc, and depending on the amount of memory that you have, it seems possible to cache an ENTIRE page bitmap. The ENTIRE page bitmap however takes a LOT of cache, so may or may not work unless you have megabytes and megabytes of memory, or a hard disk. Cheers Woody a
woody@rpp386.cactus.org (Woodrow Baker) (01/02/90)
In article <17524@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > > An interesting problem was just described to me. It seems that the > filenaameforall operator has a minor bug in it. As it enumerates the files > on the disk (if you have a NTX), it leaves a copy of the file name on > the stack. 512 files later, kablooie. The solution of course is to > redifine it so that it does a pop after each call to get the filename. > The problem apparently does not show up unless you have over 512 files > of the disk. > I have not tested this filenameforall problem out, as I don't have a printer with a hd on it. Seems that the mac utilities take advantage of it. It may be a part of the description for all I know, as I don't have a manual dealing with the filestuff, but Don reports it as a bug. At the least, it is an annoyance. T Cheers Woody
jmr@nada.kth.se (Jan Michael Rynning) (01/02/90)
In article <17524@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >An interesting problem was just described to me. It seems that the >fileforall operator has a minor bug in it. As it enumerates the files >on the disk (if you have a NTX), it leaves a copy of the file name on >the stack. 512 files later, kablooie. The solution of course is to >redifine it so that it does a pop after each call to get the filename. >The problem apparently does not show up unless you have over 512 files >of the disk. > >One of Don's clients got bit by that one, and Don dug around until hi >found it. Watch for a ***VERY*** interesting article to appear shortly >in Byte magazine. In article <17529@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: >I have not tested this filenameforall problem out, as I don't have a >printer with a hd on it. Seems that the mac utilities take advantage of it. >It may be a part of the description for all I know, as I don't have >a manual dealing with the filestuff, but Don reports it as a bug. At the >least, it is an annoyance. Your description of your friend's problem is very poor, but it seems like the filenameforall operator works the way it is described in the manual. My experiences from playing around with the filenameforall operator (I don't have a PostScript printer with a hard disk to try it on right now) is that it works the way it is described, which is both reasonable and analogous to the way the forall operator works. The forall operator pushes one or two things (depending on whether you apply it to an array, a dictionary, or a string) on the stack, before invoking the procedure you passed as an argument. It's your responsibility to pop those things, unless you want to leave them on the stack. The filenameforall pushes a filename (it doesn't create a new string for each filename, it uses the string you passed it for a buffer) on the stack, before it invokes the procedure. It's your responsibility to pop that string, unless you want to leave it on the stack. Jan Michael Rynning, jmr@nada.kth.se Department of Numerical Analysis If you can't fully handle domains: and Computing Science, ARPA: jmr%nada.kth.se@uunet.uu.net Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr S-100 44 Stockholm, BITNET: jmr@sekth Sweden. Phone: +46-8-7906288
amanda@mermaid.intercon.com (Amanda Walker) (01/03/90)
In article <17518@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > The only such program I could think of would be a > > postscript compiler written in postscript... > Right. An impossiblity. Oh, come on. Sure you could write a PostScript compiler in PostScript. As you are so fond of saying, PostScript is a real computer language... Don Hopkins has written a pretty nifty PostScript debugger in PostScript, the heart of which is a PostScript interpreter written in PostScript. Glenn Reid's PostScript "distillery" is a more pertinent example. The problem is what to generate as output. Glenn's stuff generates PostScript. Someone with your willingness to depend on implementation details could generate strings containing 68000 machine code to link into the interpreter with "cexec" on a Redstone controller... I doubt it would be of any practical use, since, at least on printers with old controllers (like the LW or LW+), I'd wager that most of the time is spent doing actual imaging, not in parsing the input or walking through an executable array. Amanda Walker InterCon Systems Corporation --
amanda@mermaid.intercon.com (Amanda Walker) (01/03/90)
In article <17524@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > It seems that the > fileforall operator has a minor bug in it. As it enumerates the files > on the disk (if you have a NTX), it leaves a copy of the file name on > the stack. Well, according to all of the supplements for printers with file systems that I have, this is what it is supposed to do. Documentation exists for a reason. It prevents many cases of pilot error... Amanda Walker InterCon Systems Corporation --
amanda@mermaid.intercon.com (Amanda Walker) (01/03/90)
In article <17529@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > It may be a part of the description for all I know, as I don't have > a manual dealing with the filestuff, but Don reports it as a bug. At the > least, it is an annoyance. Does anyone else find this as amusing as I do ...? Amanda --
woody@rpp386.cactus.org (Woodrow Baker) (01/03/90)
In article <1666@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > In article <17518@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) > > Oh, come on. Sure you could write a PostScript compiler in PostScript. > As you are so fond of saying, PostScript is a real computer language... > Don Hopkins has written a pretty nifty PostScript debugger in PostScript, > the heart of which is a PostScript interpreter written in PostScript. > > The problem is what to generate as output. sure enough. The real problem with trying to do anything in 68000 is the total lack of public information about CEXEC, and how to structure assembly language files so that the relocation info is right. > > I doubt it would be of any practical use, since, at least on printers with Come, come now, you just gave a perfect examply of a practical use for it. (see the paragraph above) > > Amanda Walker > InterCon Systems Corporation Cheers Woody
amanda@mermaid.intercon.com (Amanda Walker) (01/04/90)
In article <17533@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes: > > I doubt it would be of any practical use, since, at least on printers with > Come, come now, you just gave a perfect examply of a practical use for it. > (see the paragraph above) Recursion doesn't count :-). As several people have noted in email to me, there is a class of operation that could arguably benefit from compilation, namely, operations that are very compute-intensive, such as Gouraud & Phong shading, things that keep changing the CTM, and so on. I say arguably because I tend to do this kind of thing on the host and then ship the output to the printer. I admit it gets a little sticky when your host has less computing power than your printer (for example, Don and his Apple II and LW NTX), but that's more of a misfeature of your setup than of the printer itself... --Amanda --
woody@rpp386.cactus.org (Woodrow Baker) (01/04/90)
In article <1673@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > > As several people have noted in email to me, there is a class of operation > that could arguably benefit from compilation, namely, operations that are > very compute-intensive, such as Gouraud & Phong shading, things that keep > changing the CTM, and so on. > > I say arguably because I tend to do this kind of thing on the host and then > ship the output to the printer. I admit it gets a little sticky when your > host has less computing power than your printer (for example, Don and his > Apple II and LW NTX), but that's more of a misfeature of your setup than > of the printer itself... There most definitly are some VERY slow parts of Postscript. Why in the BLEEP the floatingpoint math is done in software is totaly beyond me. The original controller should have had an 68881 or something similar. To my knowledge none of the smaller lasers have a math co-procoessor. That one simple hardware addition would make a significant impact on through put. I use a '286 at 10 and 12 Mhz for most of what I do, and as far as it goes it's a lot less powerful than the printer as well. Why do you think that the 68000 was the platform of choice for Adobe and Apple. It has the power to do it and do it right, but still it would have been far better to have included a hardware fp processor, or at least made provision for it on the mb and in the software. Cheers Woody
dkelly@npiatl.UUCP (Dwight Kelly) (01/05/90)
woody@rpp386.cactus.org (Woodrow Baker) writes: >There most definitly are some VERY slow parts of Postscript. Why in the BLEEP >the floatingpoint math is done in software is totaly beyond me. The original >controller should have had an 68881 or something similar. To my knowledge >none of the smaller lasers have a math co-procoessor. That one simple >hardware addition would make a significant impact on through put. My VT600Ps and the CG 400dpi lasers have a Motorola FP chip. Dwight Kelly Network Publications, Inc.
gaynor@busboys.rutgers.edu (Silver) (01/05/90)
I stress the benefit that a PostScript compiler would encourage programmers to program in PostScript itself (i.e., not just as a display medium) instead of more primitive languages. Regards, [Ag]
amanda@mermaid.intercon.com (Amanda Walker) (01/05/90)
woody@rpp386.cactus.org (Woodrow Baker) writes: >To my knowledge >none of the smaller lasers have a math co-procoessor. That one simple >hardware addition would make a significant impact on through put. Well, a hardware FPU will add several hundred dollars to the price. Since for most applications (churning out pages of text), the speed is limited by the marking engine, it's probably a reasonable compromise. Amanda Walker InterCon Systems Corporation --
woody@rpp386.cactus.org (Woodrow Baker) (01/05/90)
In article <1681@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > woody@rpp386.cactus.org (Woodrow Baker) writes: > > >To my knowledge > >hardware addition would make a significant impact on through put. > Well, a hardware FPU will add several hundred dollars to the price. Since > for most applications (churning out pages of text), the speed is limited > by the marking engine, it's probably a reasonable compromise. Yep, it is more expensive. But consider that approx $1000 of the price of a postscript (Adobe) printer goes directly to adobe, both through royalties and overhead, if it had been made an option, and the software written to support both the FPU and compiled software simulations of the FPU, those who needed it could purchase it as an upgrade. I think that the world would have been better off putting a little less money in Adobe's pocket and more money into the functionality of the printer. Yes Adobe has to make a profit. That is what they are in business for. That is what every one is in business for. The royalties on the PS interpreter used to be something like $5.00 for EACH face , ie Courier cost a total of $20.00 and the base royalty was about $300.00 for the interpreter, not counting the royalty on the controler CPU design that was provided, nor the $2.5 million up front licence agreement. This has perhaps changed, but in the early days this was prettymuch normal. The base engine cost was about $600.00 from Canon. The controller cost was about $800 the total font cost was $175, The adobe royalty was about 300, so the cost to make the printer was about $1900 or so. Double that for standard manufacture overhead and profit, and you get an out of factory cost about $3600. Wholesale was about 33% of 5495, or $3626. The factory overhead includes the amortization of the licence fee. Now given the doubling for standard manufactering overhead, the portion attributable directly and easily to Adobe's monopoly of the PS world, was $950. Somewhere here, there is room for a $200 math co-processor, or at the least a $10.00 socket for one. Cheers Woody. P.S. I'd like for someone who has a true 300 dpi Adobe Ps implementation WITH a FPU, if there is one, to try the following and tell me how long it takes. Select and scale ALL 35 fonts to 20 points, one at a time, and print the entire UPPERCASE, LOWERCASE, and numbers on a single line for each font. This goodie takes upwards of 30 min on most printers, because it effectivly disables the caching of the fonts. In addition, Amanda, the major thing is that you use PS DIFFRENTLY than I do. I don't know what you do, but while we use the same PS, we work in vastly diffrent domains of it's usage. > Amanda Walker > InterCon Systems Corporation > --
amanda@mermaid.intercon.com (Amanda Walker) (01/06/90)
In article <Jan.4.17.55.27.1990.662@busboys.rutgers.edu>, gaynor@busboys.rutgers.edu (Silver) writes: > I stress the benefit that a PostScript compiler would encourage programmers to > program in PostScript itself (i.e., not just as a display medium) instead of > more primitive languages. > > Regards, [Ag] Well... I dunno. I mean, interpreted PostScript is plenty quick (in NeWS, for example), but it has it's share of primitive aspects. Dictionaries are a particularly nice way of having dynamic binding environments available as first class data structures, but the rest of the language leaves some things to be desired when it comes to general programming, and programming in the large scale in particular. It's kind of like Forth in this respect--writing code to handle single operations is fine, but I wouldn't want to write a large application in it, even though it could be done. Amanda Walker InterCon Systems Corporation --
baffico@adobe.COM (Tom Baffico) (01/06/90)
In article <17564@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: >In article <1681@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: >> woody@rpp386.cactus.org (Woodrow Baker) writes: >> >> >To my knowledge >> >hardware addition would make a significant impact on through put. >> Well, a hardware FPU will add several hundred dollars to the price. Since >> for most applications (churning out pages of text), the speed is limited >> by the marking engine, it's probably a reasonable compromise. > >Yep, it is more expensive. But consider that approx $1000 of the price of >a postscript (Adobe) printer goes directly to adobe, both through royalties How does Adobe make $1,000 on PostScript royalties when TI is selling their microLaser PostScript upgrade board for $505? (Which includes the usual 35 Adobe PostScript fonts.) As to the benefit of having a FPU, for most controllers the performance increase is actually quite small. Tom Baffico Adobe Systems
gaynor@busboys.rutgers.edu (Silver) (01/06/90)
Ag> I stress the benefit that a PostScript compiler would encourage programmers Ag> to program in PostScript itself (i.e., not just as a display medium) Ag> instead of more primitive languages. AW> I mean, interpreted PostScript is plenty quick (in NeWS, for example), but AW> it has it's share of primitive aspects. Primitive aspects? Hee hee, unlike C, right? The speed of the interpreter is relative. Sure, it will fairly fly for `reasonable' requests, but this is not a reasonable world. AW> It's kind of like Forth in this respect I tend to think of PostScript as the offspring of a wild fling between Lisp, Forth, and a bunch of graphics primitives. There is just as much Lisp `in' PostScript as there is Forth. AW> writing code to handle single operations is fine, but I wouldn't want to AW> write a large application in it, even though it could be done. This is kind of contradictory, as single operations can be the combination of other single operations. At some point, a combination of single operations will take on the aspects of (thus become) a large application. There's no question that PostScript has at least the minimum functionality to do so. The question you raise concerns the Ease and Convenience of developing such applications in PostScript. Now, it's fair to say that NeWS is an elegant upgrade from page description to the graphical application/interface realm. Examining historical precedent, GNU Emacs is an elegant upgrade from a text editor to the terminal application/interface realm. There are many parallels between the two, although I would hesitate say that NeWS is to PostScript what GNU Emacs is to Lisp. They are certainly similar enough at the lower levels, and the underlying languages are very high level and similar in expressive power (once one becomes accustomed to the world of postfix notation). Given these relationships, its not inconceivable that they might follow the same path. It would make things immensely easier if there was a development platform for PostScript under NeWS as good as the one for Lisp under Emacs. Just pipe-dreaming, [Ag] gaynor@topaz.rutgers.edu
woody@rpp386.cactus.org (Woodrow Baker) (01/07/90)
> Well... I dunno. I mean, interpreted PostScript is plenty quick (in NeWS, > for example), but it has it's share of primitive aspects. Dictionaries are a > particularly nice way of having dynamic binding environments available as > first class data structures, but the rest of the language leaves some things > to be desired when it comes to general programming, and programming in the > large scale in particular. It's kind of like Forth in this respect--writing > code to handle single operations is fine, but I wouldn't want to write a > large application in it, even though it could be done. There have been some mighty large and powerful systems written in FORTH. because of it's extensibility, which it shares with PS, you can literaly build layer upon layer, until you can write an entire GL package with just 1 screen of code. I'n not a fan of FORTH, but it is a very capable language. It seems that most people are unwilling to look at PS as anything other than a fancy printer controler command set. I have found no major or minor deficiences in the language, other than some limited I/O and the lack of arctan, arcsin, and arccos. With the addition of a disk, we have a full computer. I challenge you to pinpoint *ANY* major deficiency of PS for general purpose programming. There is no reason, other than predjudice, that one could not implement say a mailing list manager, using the hard disk, and generating forms and labels within the printer. Or a GL package, or anyother program. Considering that you can write ANY program in this world with a computer that has one instruction, and 8 data constants, you certainly can write it for ps. P.S. The one instruction subjne address1,address2,address3 subtract address contents 1 from address contents 2 and jump to address 3 on non-zero. The constants, 1,2,4,8,16,32,64,128,0xff, and 0. Cheers Woody 2 > Amanda Walker > InterCon Systems Corporation > --
woody@rpp386.cactus.org (Woodrow Baker) (01/07/90)
In article <1589@adobe.UUCP>, baffico@adobe.COM (Tom Baffico) writes: > In article <17564@rpp386.cactus.org> woody@rpp386.cactus.org (Woodrow Baker) writes: > >In article <1681@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > >> woody@rpp386.cactus.org (Woodrow Baker) writes: > >> > >> >To my knowledge > >> >hardware addition would make a significant impact on through put. > >> Well, a hardware FPU will add several hundred dollars to the price. Since > >> for most applications (churning out pages of text), the speed is limited > >> by the marking engine, it's probably a reasonable compromise. > > > >Yep, it is more expensive. But consider that approx $1000 of the price of > >a postscript (Adobe) printer goes directly to adobe, both through royalties > > How does Adobe make $1,000 on PostScript royalties when TI is selling > their microLaser PostScript upgrade board for $505? (Which includes the > usual 35 Adobe PostScript fonts.) > > As to the benefit of having a FPU, for most controllers the performance > increase is actually quite small. > > Tom Baffico > Adobe Systems Tom, If you'll re-read the post you will see that I indicated that things might have changed. I indicated the context that these figures came from. The $1000 is the INCREMENTAL cost. The Adobe royalties are less than that, and it has been my understanding that they have gone down somewhat. I understand where you are coming from, but I believe that I was amply clear about the breakdown of the figures, and the fact that they were from about 1986. AS to the benifits of a FPU, I am certain that the speedup would matter. Software floating point has to be slower than hardware floatingpoint, and unless I am mistaken, the PS controller does most of it's stuff in floating point. Perhaps it uses scaled fixed point, and then I would agree. Cheers Woody
kchen@Apple.COM (Kok Chen) (01/08/90)
woody@rpp386.cactus.org (Woodrow Baker) writes: > ... I challenge you to pinpoint *ANY* major deficiency of PS for >general purpose programming. And I challenge you to pinpoint *ANY* major deficiency of a using big piece of rock for general purpose hammering. You can also drive your car to visit your neighbour who lives across the street from you. In such a case, would you complain to Detroit, Tokyo or Stuttgart (or rec.auto :-) that it is slower than simply walking across the street? Kok Chen kchen@apple.COM, kk6dp Disclaimer: naturally this has nothing to do with Apple's position.
woody@rpp386.cactus.org (Woodrow Baker) (01/08/90)
In article <37662@apple.Apple.COM>, kchen@Apple.COM (Kok Chen) writes: > woody@rpp386.cactus.org (Woodrow Baker) writes: > > > And I challenge you to pinpoint *ANY* major deficiency of a using big > piece of rock for general purpose hammering. > Just thought I'd let you know that I am a flint knapper. I use ONLY rocks and deer antlers to make stone tools. Anything much harder than a Quartz cobble does not work. The surface has no give, on say a steel hammer, and this it causes multiple hinge fractures, and uncontrolled flaking. True, sometimes the rock breaks, but then so does ps. Memory management stinks in postscript, and the fact that you can't decouple multiply copies of strings easily are the only 2 minor drawbacks to it that I can find. Cheers Woody
amanda@intercon.com (Amanda Walker) (01/09/90)
In article <17581@rpp386.cactus.org>,ntwoody@rpp386.cactus.org (Woodrow Baker) writes: > [I wrote:] > It's kind of like Forth in this respect--writing > code to handle single operations is fine, but I wouldn't want to write a > large application in it, even though it could be done. There have been some mighty large and powerful systems written in FORTH. because of it's extensibility, which it shares with PS, you can literaly build layer upon layer, until you can write an entire GL package with just 1 screen of code. As I said, you can certainly do it, I just wouldn't want to. I mean, people have written airline reservations system in APL, too. I wasn't asking for an existence proof :-). It seems that most people are unwilling to look at PS as anything other than a fancy printer controler command set. Well, I look at it as a quite nice two-dimensional imaging language. It does an extremely good job of making the physical characteristics of the imaging medium irrelevant to the task of describing the image itself. Now, it is a lot like Lisp in being a ball of mud language (i.e., whatever you add to a ball of mud, it's still a ball of mud), principally because it has a very simple syntax balanced by often complex semantics. Sun, for example, has added some marvelous extensions for event handling and lightweight processes, as well as multiple imaging surfaces (called "canvases") and object-oriented method dispatching (which will also work just fine in vanilla PostScript). I challenge you to pinpoint *ANY* major deficiency of PS for general purpose programming. - Named and lexically scoped local variables and parameters. These can be simulated by using anonymous dictionaries that are patched into executable arrays, but this is a hack. - A more sophisticated model of memory management. A garbage-collecting storage management subsystem would make it much easier to implement complex data structures using dictionaries (a la NeWS) and to use persistent data structures in general. 'save' and 'restore' work great for throwaway code, or code that is executed on the fly (as most PostScript code is), but it suffers when you are using more persistent data structures, especially if they can change in size. To take a concrete example, I would find it much easier and more pleasant to write a B*-tree manipulation package in C or Lisp than I would in PostScript. The 'right' way to write something in PostScript that used a database would be to add primitives to the interpreter I was using to do the low-level memory and file management. - A more sophisticated I/O model. Things like random access to file contents become important for general purpose programming. The file system primitives provided with PostScript so far are designed for storing hunks of PostScript code (be they fonts or whatever), and they are pretty good at it, but sometimes you need more than simple text streams. There is no reason, other than predjudice, that one could not implement say a mailing list manager, using the hard disk, and generating forms and labels within the printer. There is no reason that one *could* not, but there are many reasons why one *would* not, not the least of which is that since you probably are using a computer of some sort to give the printer commands, you may as well use it for what it's good at. Drawing labels and forms is quite appropriate for PostScript. Database management, however possible in a theoretical sense, is not, given the current set of primitives that are defined as "PostScript." The fact that many languages are Turing-equivalent does not mean that they are equally suited for any given task :-). Imagine describing pages in assembler, for example...
lpw@jvc.UUCP (Lance Welsh) (01/09/90)
If these people think that parsing PS and writing grammars is a trivial snap: woody@rpp386.cactus.org (Woodrow Baker) writes: > Actually, a Compiled version of PS is not unreasonable. Given a good > BNF of the language, YACC and LEX should make the parser a snap. From: rcd@ico.isc.com (Dick Dunn) > The BNF of PostScript is so trivial it's (a) uninteresting and (b) > unhelpful. The parser is a snap; it would be kinda dumb to use YACC for > it. (Of *course* the parser is simple--that's one of the arguments for > using a postfix stack-oriented language!) From: rcd@ico.isc.com (Dick Dunn) > It's trivial to write a context-free grammar for PostScript. And that's > not the reason for not compiling it. then why have we never seen anyone post a BNF for postscript or a public domain parser? I'll bet it's harder than they think. -Lance P. Welsh uunet!jvc!lpw JVC Laboratory of America
rcd@ico.isc.com (Dick Dunn) (01/09/90)
woody@rpp386.cactus.org (Woodrow Baker) writes: > ... I challenge you to pinpoint *ANY* major deficiency of PS for > general purpose programming... The language has latent types and dynamic binding. This introduces an inherent inefficiency which will become objectionable in any program for which the execution time of the average primitive operator reaches the same order of magnitude as the execution time required to determine the types of operands and construct the result descriptor. If you fuss about formal checking, you'll also note that the type-correctness of a program cannot be checked until execution time. These limitations are inherent. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
woody@rpp386.cactus.org (Woodrow Baker) (01/09/90)
In article <1690@intercon.com>, amanda@intercon.com (Amanda Walker) writes: > In article <17581@rpp386.cactus.org>,ntwoody@rpp386.cactus.org (Woodrow Baker) writes: > > Well, I look at it as a quite nice two-dimensional imaging language. It > does an extremely good job of making the physical characteristics of the > imaging medium irrelevant to the task of describing the image itself. true enough. some times to irrelevant. > Now, it is a lot like Lisp in being a ball of mud language (i.e., whatever > you add to a ball of mud, it's still a ball of mud), principally because I suppose that you would classify APL as a mud-ball language as well. Extensible langues (of which APL is not) could fall into that catagory. I'm sure the Lisp people are gonna love you. u > I challenge you to pinpoint *ANY* major deficiency of PS for > general purpose programming. > > - Named and lexically scoped local variables and parameters. These can > > - A more sophisticated model of memory management. A garbage-collecting > storage management subsystem would make it much easier to implement > > The 'right' way to write something in PostScript that used > a database would be to add primitives to the interpreter I was using to > do the low-level memory and file management. That is another oversight in the design of the language. > - A more sophisticated I/O model. Things like random access to file > contents become important for general purpose programming. The file > There is no reason that one *could* not, but there are many reasons why > one *would* not, not the least of which is that since you probably are > using a computer of some sort to give the printer commands, you may as > well use it for what it's good at. Why tie up your computer doing something that the printer is perfectly capable of doing. I agree the file handleing does lack a LOT, but it is not unusable. g > > Drawing labels and forms is quite appropriate for PostScript. Database > management, however possible in a theoretical sense, is not, given > the current set of primitives that are defined as "PostScript." > > The fact that many languages are Turing-equivalent does not mean that > they are equally suited for any given task :-). Imagine describing > pages in assembler, for example... I can, because I have done it. Everyone who has done any kind of screen graphics package has done it either in assemlber, or in 'C' or perhaps some other non-PS language. One of the first programs I ever wrote was a cassete label printing program in assembler. It did shadowprinting, bolding, underlining, etc, and used a 4800 baud JPC interface (it was a SWTP 6800 system with 4k of ram) for a cassette based file system. It does not perhaps sound like describing a page, but it essentialy was is some sense. It was neither pretty, nor easy, so I certainly. You have definitly hit the problem areas of postscript. These are definitly deficiencies, but with the exception of the I/O primatives, can be gotten around. I think that "hacks" are just fine, if they accomplish their desired end. As long as they are well documented. Cheers Woody s
gaynor@busboys.rutgers.edu (Silver) (01/09/90)
amanda> A more sophisticated model of memory management. A garbage-collecting amanda> storage management subsystem would make it much easier to implement amanda> complex data structures using dictionaries (a la NeWS) and to use amanda> persistent data structures in general. Hmph. Since most of my PostScript programming has been relatively small (but not trivial), I have not been worrying about memory management issues. It's such a fun little language, even without the grafix ops! Seeing your light, I realize that this is probably the biggest drawback in the language. The dynamic lookup I can live with. This? Maybe not... Regards, [Ag]
amanda@mermaid.intercon.com (Amanda Walker) (01/10/90)
In article <Jan.9.03.18.12.1990.1470@busboys.rutgers.edu>, gaynor@busboys.rutgers.edu (Silver) writes: > Seeing your light, I > realize that this is probably the biggest drawback in the language. The > dynamic lookup I can live with. This? Maybe not... Well, it is my biggest gripe (see, Woody, I'm not completely an Adobe cheerleader :-)). I don't find dynamic binding quite so annoying, since I'm used to it from Lisp, and it can be very useful. Also, the facts that you can (a) explicitly manipulate dynamic binding environments and (b) use the "bind" operator to look things up in the current environment stack at definition time mean that it's not as limiting as it could otherwise be (cf. the NeWS object extensions, which can be implemented in vanilla PostScript). I do agree that it is a pretty fun little language, though; much nicer than Forth, for example... Amanda Walker InterCon Systems Corporation --
amanda@mermaid.intercon.com (Amanda Walker) (01/10/90)
In article <17601@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes in response to my article <1690@intercon.com>: > > [PostScript] > > does an extremely good job of making the physical characteristics of the > > imaging medium irrelevant to the task of describing the image itself. > > true enough. some times to irrelevant. NO!! [there, now I feel better :-)]. This device independence is one of the biggest strength of PostScript. If you absolutely need to "get around" one of the principal design features of PostScript, then maybe you should be using another kind of printer. > I suppose that you would classify APL as a mud-ball language as well. No, not particularly. Change anything, and it's not APL any more... More like a "diamond" language. The main characteristic of a ball-of-mud languages is that they are syntax-poor and semantics-rich (relatively speaking). > I'm sure the Lisp people are gonna love you. Hey, I *am* a Lisp people :-). I take that as a compliment. > > The 'right' way to write something in PostScript that used > > a database would be to add primitives to the interpreter I was using to > > do the low-level memory and file management. > > That is another oversight in the design of the language. To paraphrase Monty Python, "The *language* don't enter into it." My approach would probably be to recompile the interpreter, since I wouldn't be running my DBMS on my printer :-). These extensions would be outside the PostScript language per se just as much as the color separation conventions or NeWS's event handling are. > Why tie up your computer doing something that the printer is perfectly > capable of doing. Why tie up your printer doing something that the computer is perectly capable of doing? I don't know about you, but my computers are useful for more things than being PostScript terminals... > I agree the file handleing does lack a LOT, but it is > not unusable. You did ask for deficiencies, dear, not things that were completely unusable :-). We've already established than you *can* write damn near anything in PostScript if you really want to... You'd probably have a lot of fun with NeWS, for example. > > Imagine describing > > pages in assembler, for example... > > I can, because I have done it. So have I, but I tend not to do it these days, because there are better tools for the job available. > You have definitly hit the problem areas of postscript. These are > definitly deficiencies, but with the exception of the I/O primatives, > can be gotten around. I won't argue with that. > I think that "hacks" are just fine, if they accomplish > their desired end. As long as they are well documented. Sigh. Woody, if they were documented, they'd be features, not hacks :-). Complaining that what Adobe documents as "PostScript" isn't enough for what you want to do (or how you think is the best way to do it) is silly. It's like buying a Corvette and complaining that it doesn't have enough leg room in the back seat. However true it may be, it's more of a problem with how you are trying to use it as with the manufacturer's design. Maybe we should agree to disagree. I agree with whoever said that this kind of fla... er, discussion is more approriate to comp.laser-printers than comp.lang.postscript. Getting a little tired of this, Amanda Walker Speaker to PostScript InterCon Systems Corporation --
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (01/10/90)
In article <1698@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >In article <17601@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) >writes in response to my article <1690@intercon.com>: >> > [PostScript] >> > does an extremely good job of making the physical characteristics of the >> > imaging medium irrelevant to the task of describing the image itself. >> >> true enough. some times to irrelevant. > >NO!! [there, now I feel better :-)]. This device independence is one of the >biggest strength of PostScript. If you absolutely need to "get around" >one of the principal design features of PostScript, then maybe you should >be using another kind of printer. > I simply HAVE to respond to this. Postscript, as a language, is device dependent (by definition - the device dependent parts are simply DEFINED as NOT Postscript.) BUT, that doesn't mean that a given Postscript program can be used in a device dependent manner. Different devices produce different output. Take two examples: Adobe Postscript fonts simply look different on a 300 d.p.i. laser printer and a 2540 d.p.i. typesetter. Many fonts look "fatter" on a laser printer. To get best advantage of either device a typesetting language might want to make spacing changes - or even use different fonts - for different devices, to get the best effect. As even better example, consider printing bitmapped images. Perhaps you have an image that has a grid of, say, 600x600 pixels. You might want to print it at 2x2 inches on a 300 d.p.i. printer, 1.5x1.5 on a 400 d.p.i. printer, and 1.88... inches on a 1270 d.p.i. printer, changing page layout to compensate. TRUE device independence probably starts at some number of dots per inch greater than 1200. It is impossible to get really good results at 300 d.p.i. without designing for that. Doug McDonald
batcheldern@hannah.enet.dec.com (Ned Batchelder) (01/10/90)
> If these people think that parsing PS and writing grammars is a trivial snap: > > ...[other quotes deleted]... > > then why have we never seen anyone post a BNF for postscript or a > public domain parser? I'll bet it's harder than they think. I think someone just did post a BNF for PostScript, in an earlier article in this thread. Basically, the syntax of PostScript is that you have tokens, and you have procs, which are tokens or procs in curly braces: thing ::= token | { thing* } PSprogram :== thing* Not much of a grammar! It doesn't really shed any light on anything, or help understand the language in any way. Of course, you have to scan the tokens, and that can get a little interesting, what with the "#" notation and all, but that's a lexical issue, which is usually considered separately from syntax. The fact is that as a postfix operator-based language (as opposed to an infix statment-and-expression-based language), PostScript just doesn't lend itself to "parsing". Ned Batchelder, Digital Equipment Corp., BatchelderN@Hannah.enet.DEC.com
amanda@mermaid.intercon.com (Amanda Walker) (01/10/90)
In article <1990Jan9.191937.14208@ux1.cso.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > TRUE device independence probably starts at some number of dots > per inch greater than 1200. It is impossible to get really good > results at 300 d.p.i. without designing for that. Quite true; I realized I left that out after I posted my article. Nobody's perfect :-). PostScript does have perfectly documented ways to discover device resolution and printing area boundaries (it even includes primitives for transforming into and out of device coordinates), without having to stoop to the lengths Woody advocates. The single thing I can think of which has no documented way to be discovered is pixel shape (write- white vs. write-black, for example, or elliptical pixels on a laser recorder). This seems more of an oversight than a design flaw, though. --Amanda --
amanda@mermaid.intercon.com (Amanda Walker) (01/10/90)
In article <550@jvc.UUCP>, lpw@jvc.UUCP (Lance Welsh) writes: > then why have we never seen anyone post a BNF for postscript or a > public domain parser? I'll bet it's harder than they think. The biggest problem is not with the actual parsing per se, it's that since a PostScript interpreter is actually executing its input stream (rather than reading a file and then executing it), you cannot statically analyze a PostScript program (take an 'image' command or a font download, for example). This is one of the reasons that the PostScript Document Structuring Conventions use comments instead of parsing the file. Comments are at least unambiguous. The only way I can see of doing a PostScript compiler is to write an interpreter which compiles executable arrays once they are constructed by the interpreter. I'd probably start with compiling to subroutine- threaded code, much in the way of a Forth compiler. Besides, there are several publically available PostScript parsers, they're just embedded in interpreters: GhostScript, Xps, and so on. Amanda Walker Speaker To PostScript InterCon Systems Corporation --
ed@DTG.COM (Edward Jung) (01/10/90)
Display Postscript has a garbage collection memory manager and
multiple threads of control. Deliberate discards, undef, shared VM
and other features add to the usefulness of the new memory management
model. Multiple execution contexts are also supported by locks and
conditions. Multiple storage devices, named files, and file
positioning control are also available.
In short, DPS adds many features that make it a more useful language
for general-purpose programming. Note, however, that it is still
designed as a rather niche-specific language, and should be treated as
such.
--
Edward Jung The Deep Thought Group, L.P.
BIX: ejung 3400 Swede Hill Road
NeXT or UNIX mail Clinton, WA. 98236
UUCP: uunet!dtgcube!ed Internet: ed@dtg.comwoody@rpp386.cactus.org (Woodrow Baker) (01/10/90)
In article <1701@intercon.com>, amanda@mermaid.intercon.com (Amanda Walker) writes: > to stoop to the lengths Woody advocates. The single thing I can think > of which has no documented way to be discovered is pixel shape (write- > white vs. write-black, for example, or elliptical pixels on a laser > recorder). This seems more of an oversight than a design flaw, though. true enough. One can sort of find the info, but it is not really totaly reliable because it can be changed by the user, but if you characterize a list of machines as to their rendering modes, and then look the printer name up, you can indirectly obtain this info. It is *NOT* inherent in either the printer or the lanuage, short of peeking into the roms. Indeed, there are some very fundamental reasons to need the knowlege of whether it is a black-writer vs a white-writer. Due to the the techniques used, a blackwriter has more resolution on fine detail, and a white writer can lose single pixels. one often needs to alter a screen, for example, darken it for a white-writer etc. Currently the only solution seems to be the name lookup, provided someone has not changed it. Cheers Woody > > --Amanda > --
rcd@ico.isc.com (Dick Dunn) (01/14/90)
In article <550@jvc.UUCP>, lpw@jvc.UUCP (Lance Welsh) writes: > If these people think that parsing PS and writing grammars is a trivial snap: [...I had written...] > > The BNF of PostScript is so trivial it's (a) uninteresting and (b) > > unhelpful. The parser is a snap;... ... >...then why have we never seen anyone post a BNF for postscript or a > public domain parser? I'll bet it's harder than they think. If you knew, you wouldn't have to bet! I posted the BNF, but I'm not surprised you missed it, since it was only two lines long (and even that was loquacious). -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."