Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!SCFVM.GSFC.NASA.GOV!ZMLEB From: ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman) Newsgroups: comp.lang.forth Subject: Re: Floating Point stack Message-ID: <9008280255.AA26241@ucbvax.Berkeley.EDU> Date: 28 Aug 90 02:49:52 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 115 >> This proposal [making a floating point stack optional] seems to >> guarantee that anyone wishing to write a "Standard" application >> using floating-point will have to write everything twice. Then, >> of course, at the beginning of your standard program you can test >> the environment and decide which copy of the application to run. >> (I invite counter-examples.) > >That is what I used to think too, until I figured out the "trick". > >The solution turns out to be remarkably simple: > >Suppose that we have a function FSTKCELLS > > FSTKCELLS ( n -- ncells ) > ncells is the number of data stack items occupied > by a n floating point numbers. > >Given this function, mixed stack operations can be portably expressed as >a (usually trivial) calculation involving FSTKCELLS and PICK . > >Of course, this is more cumbersome than doing nothing at all, but in >an absolute sense, it is reasonably simple, effective, and less trouble >than maintaining 2 versions of the code. > >Fortunately, mixed-stack operations turn out to be relatively infrequent, >and can often be avoided altogether by judicious use of variables. > >Mitch Sorry, Mitch, I have to disagree strongly on this one. There is a big difference between floating point code that uses a separate stack and that which doesn't. The end result of the compromise in the proposal that was adopted is that, rather than some of the existing floating point code needing to be rewritten to be portable, ALL OF IT WILL HAVE TO BE. From the standpoint of portability, all existing floating point code is broken. Period. I admired the handling of the Floored vs. Truncated division compromise, but this one sucks hot rocks from hell. Mixed stack operations are quite common in astrophysical applications, especially image processing, where, in our system here at Goddard, the image is stored in an indexed N-dimensional array. The indices are integers kept on the data stack, the floating point array data on a separate floating point stack. The indices may be computed in another word entirely (e.g. a word to convert celestial coordinates to pixel location), therefore the ordering of the words in a program is very dependant on knowing if a separate stack exists. To illustrate the difference in coding style consider data stored in an array defined like so: F_IMAGE ( rows cols -- ) compiling ( row col -- addr ) executing Allocate a two-dimensional floating point array of width 'cols' and heigth 'rows'. At runtime, the defined array takes the index values 'row' and 'col' and converts them to the appropriate memory address of the element in that row and column. Say we want a 3-by-3 pixel box average of the data in order to generate a smoothed image. For most of the image, one just adds up the values of the 3 pixels immediately above the reference pixel, the three pixels below it, the pixels to either side and the reference pixel itself, then divide by 9.0. At the borders, 2-by-3 and 3-by-2 pixels boxes are averaged. 512 512 F_IMAGE Galaxy ( This is the image array used below. Assume ) ( an image has already been loaded into it. ) ( Central routine for computing a 3-by-3 pixel box average of the image in array Galaxy. To complete the actual box averaging, similar routines are used that compute averages of 2-by-3 and 3-by-2 boxes at the borders. ) : _box-average ( F: -- Ave-Value D: i0 j0 --- ) ( Total the values for the three pixels in the row above ) over 1- over 1- ( i0-1 j0-1 ) Galaxy F@ over 1- over ( i0-1 j0 ) Galaxy F@ F+ over 1- over 1+ ( i0-1 j0+1 ) Galaxy F@ F+ ( Total the values for the three pixels in the row below ) over 1+ over 1- ( i0+1 j0-1 ) Galaxy F@ F+ over 1+ over ( i0+1 j0 ) Galaxy F@ F+ over 1+ over 1+ ( i0+1 j0-1 ) Galaxy F@ F+ ( Total pixels to left and right and finally center, divide by 9 ) 2dup 1- ( i0 j0-1 ) Galaxy F@ F+ 2dup 1+ ( i0 j0+1 ) Galaxy F@ F+ ( i0 j0 ) Galaxy F@ F+ 9.0 F/ ; As you can see, with the separate floating point stack, the pixel values accumulate in the FP stack and don't interfere with the calculations of the index values. Writing the same code for FP values on the data stack would result in much more complex set of stack manipulations, or the intermediate value would have to be stored in a variable. Either way, it would be much less efficient. I scanned several dozen screens of code with various floating-point calculations and encountered many instances where the existence of a separate stack is vital to running the code. There is also the problem of programmers, like myself, that get a little sloppy about fetch and store operations, seeing as how with a separate stack it doesn't matter what order the value and address are referenced, e.g. 12.0 XVAL F! is precisely equivalent to XVAL 12.0 F! when there is a separate FP stack, but not when floats are stored on the data stack. This kind of thing can get very hard to find and fix if both methods are allowed and have to be planned for. Testing for whether there is or isn't an FP stack, and writing code to operate on either, just will not be worth the effort. The end result will be a lot of code that depends on one method alone. All hope of portability is lost, in my opinion. This is one area where the TC should have bitten the bullet and made a definite decision for or against a separate stack. Obviously I would prefer the former, but I could live with the latter, as long as it was definite. This time the move to an all-encompassing compromise may well prove disastrous. The division question provided a simple answer that leaves current code portable with a few simple definitions for / , MOD , etc. This latest decision will require rewrites of ALL floating point code, regardless. What could the rational have possibly been? -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM Internet: zmleb@scfvm.gsfc.nasa.gov -- I'm only a contractor, don't blame me for the tax rates and don't blame -- the government for my statements.