hrubin@pop.stat.purdue.edu (Herman Rubin) (04/30/91)
In article <1991Apr29.155945.29907@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes: > hrubin@pop.stat.purdue.edu (Herman Rubin) wrote ..................... > And I described how it could be done, using Fortran 77 and pretty > standard optimization (value numbering and peephole optimization). > > hrubin@pop.stat.purdue.edu (Herman Rubin) replies: > > >Any specific instance of this can be added to the compiler's ken, but > >until it does, the compiler cannot take advantage of it. The point is > >that the compiler must be instructed to look for them. > > Yes indeed. That's the job of the compiler writer. > If he does a bad job in using the instruction set of the machine, > you should complain to him. Is it the compiler writer's job to recognize combinations of expressions in a language which really represent an operation not contained in that language? How do you separate a float into the exponent and the significand? What is needed for the user to be able to communicate what operations are wanted. It is even necessary to do this in cases in which the language supports the desired effect in multiple ways. Looking for the code and making sure it has no side effects which would make the supposed improvement more costly is no simple task, but it is easier if the compiler is told what is wanted, instead of having to guess. > >The real2int conversion still has to be done on most machines, and also > >an integerize of real. But suppose that the machine has integer hardware > >comparable to floating hardware, and can also handle unnormalized floats. > Well, we can suppose all sorts of things. Nevertheless, my solution > handles your first set of suppositions. If you change the machine, > you need to change compilers. This newsgroup is comp.arch. How are the computer architects to recognize these situations and others? > I thought your original question was posed in an attempt to show that > many languages don't have the facilities you consider necessary > to control the machine. I just tried to show that the effect you > wanted could be achieved. What you have shown is that a compiler can, in effect, extend a language by looking for certain code patterns. I fail to see that this procedure, which will always be limited by the information given to the compiler writers, and which can also sometimes lead to difficulties, is better than allowing the user to extend the language and pass the information to the compiler in such a way that it can use more of the machine capabilities. It is also by having these situations laid out in the open that subsequent language designers, compiler writers, and hardware designers will be likely to know about them and include them. No matter how great these are, there are plenty of "obvious" things which will be missed. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
preston@ariel.rice.edu (Preston Briggs) (04/30/91)
hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >Is it the compiler writer's job to recognize combinations of expressions in >a language which really represent an operation not contained in that >language? It's the compiler writer's job to write code that recognizes combinations of expressions that are supported by machine instructions. It's one of the significant tasks of instruction selection. I don't know how to handle everything (e.g., recognizing a routine that computes square root), but many of the combinations you (and others) give as examples _are_ easily handled. >What is needed for the user to be able to communicate what operations are >wanted. I agree that the user should be able to instruction the computer. However, I don't think I want to specify the assembly operations. Instead, I want to manipulate numbers, sets, sequences, and objects in a somewhat high-level fashion. Then I want the compiler to make very good code out of my specification. >> If you change the machine, you need to change compilers. > >This newsgroup is comp.arch. How are the computer architects to recognize >these situations and others? I expect they learn from reading and by experience. It seems that one of the major accomplishments of the RISC evolution was a recognition that architects and compiler people should talk more often than in the past. >What you have shown is that a compiler can, in effect, extend a language >by looking for certain code patterns. I disagree. The language (Fortran 77) didn't change when I added my optimization. The compiler translates exactly the same set of programs; some programs simply ran slightly faster. > I fail to see that this procedure, >which will always be limited by the information given to the compiler >writers, and which can also sometimes lead to difficulties, is better >than allowing the user to extend the language and pass the information >to the compiler in such a way that it can use more of the >machine capabilities. The difference is that we (computer science community in general) know how to do optimizing compilers. You pose a much harder problem. Preston Briggs
hrubin@pop.stat.purdue.edu (Herman Rubin) (04/30/91)
In article <1991Apr30.025904.13028@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes: > hrubin@pop.stat.purdue.edu (Herman Rubin) writes: ...................... > >What is needed for the user to be able to communicate what operations are > >wanted. > > I agree that the user should be able to instruction the computer. > However, I don't think I want to specify the assembly operations. > Instead, I want to manipulate numbers, sets, sequences, and objects in a > somewhat high-level fashion. Then I want the compiler to make very good > code out of my specification. But what if I find Boolean operations useful in dealing with floats, which I do for certain purposes? There are other operations which I can use for useful purposes, but only if they are fast. You do not know these operations, and the language community has seen fit to ignore what those who are capable of versatility can envision. > >> If you change the machine, you need to change compilers. > > > >This newsgroup is comp.arch. How are the computer architects to recognize > >these situations and others? > > I expect they learn from reading and by experience. > It seems that one of the major accomplishments of the RISC evolution > was a recognition that architects and compiler people should talk > more often than in the past. But what about getting input from those users who do not find what they want? That multiply and add could be easily combined in hardware was known BC (before computers); it was routine in desk calculatore (now essentially extinct). The only reason I can think of that the early computers did not have this feature is that it would have taken another register to hold the multiplier. One of the reasons why, in the late 50s and early 60s, binary was settled on (there are many others) was that multiplication by powers of 2 was rather common. Only a few machines have this very important operation in floating hardware, and instead have to bring in the multiplier and use the relatively slow multiplication. It is true that with pipelined hardware this is not so much of a problem, but I know of only a few machines which had it before then. > >What you have shown is that a compiler can, in effect, extend a language > >by looking for certain code patterns. > > I disagree. The language (Fortran 77) didn't change when I added my > optimization. The compiler translates exactly the same set of > programs; some programs simply ran slightly faster. > > > I fail to see that this procedure, > >which will always be limited by the information given to the compiler > >writers, and which can also sometimes lead to difficulties, is better > >than allowing the user to extend the language and pass the information > >to the compiler in such a way that it can use more of the > >machine capabilities. > > The difference is that we (computer science community in general) > know how to do optimizing compilers. You pose a much harder problem. I agree that you know how to do certain types of optimizations. I suggest that you make these optimizations available to those who have a more varied collection of things to optimize. You (the computer science community) know how to optimize, but have only a limited knowledge of what it is useful to optimize. I do not criticise you for this lack of knowledge, but only for failing to realize that you should be looking for input on this from others. We, and I include all of mankind, do not know enough about to design a good system of communicating between people and computers now. We can design a fair one by realizing this and allowing the users to extend the language, and to communicate to the compiler this extension. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
jkw@genrad.com (J. Kyle Wilson) (05/01/91)
In article <11609@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >In article <1991Apr30.025904.13028@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes: >> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > >> >What is needed for the user to be able to communicate what operations are >> >wanted. >> >> I agree that the user should be able to instruction the computer. >> However, I don't think I want to specify the assembly operations. >> Instead, I want to manipulate numbers, sets, sequences, and objects in a >> somewhat high-level fashion. Then I want the compiler to make very good >> code out of my specification. > >But what if I find Boolean operations useful in dealing with floats, which >I do for certain purposes? There are other operations which I can use for >useful purposes, but only if they are fast. You do not know these operations, >and the language community has seen fit to ignore what those who are capable >of versatility can envision. The language community has been providing the greatest good for the greatest number where possible. If you have need of an optimization that no one has seen fit to add to a compiler you are using your best bet may be to hire a compiler writer to tweak it to handle that case. If you can find a large enough segment of the user community to support your modification you may even be able to get this new twist adopted as a standard. If your time spent optimizing the interior of critical loops in your code is worth enough, your employer should gladly fund the rewriting of whatever compiler you use to optimize in any way you wish. Satisfying your requests would require the compiler to recognize a large number of special cases each of which would likely be used by a small segment of the user community, while requiring signifigant work to support as the compiler incorporates new technology. This would have an overall greater cost to the community at large than allowing the user to code oddball cases in #ifdef'd asm statements for each machine. One could add #pragma statements to the compiler (or equivalents for those using other languages) containing clues regarding optimization of the code. Why should you specify a boolean operation on a float when this is really not the operation you wish to perform? Have your hired compiler writer add a pragma that indicates to the compiler that the following line of code may be implemented in some odd way, and stick with that. Kyle Wilson jkw@gnerad.com Kyle Wilson GenRad Inc. 300 Baker Ave Concord MA 01742
dik@cwi.nl (Dik T. Winter) (05/01/91)
In article <11609@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > But what if I find Boolean operations useful in dealing with floats, which > I do for certain purposes? Can you also specify the floating point format please? Should the language require a specific format? And if it does *not* depend on the format, what kind of Boolean operations are you thinking of? Or should there be a different language for every architecture? Yes, I know you have mumbled about user extensible languages. Upto now I have seen no specification of the things you want. Algol 68 is very powerful, you can add all kinds of infix operators, but I have this idea that that is not what you want. > One of the reasons why, in the late 50s and early 60s, binary was settled on > (there are many others) was that multiplication by powers of 2 was rather > common. I have heard many reasons, but never this one. Can you give a reference please? > Only a few machines have this very important operation in floating > hardware, and instead have to bring in the multiplier and use the relatively > slow multiplication. It is true that with pipelined hardware this is not so > much of a problem, but I know of only a few machines which had it before then. Mm, some 360's had it I think, but that was completely micro code, and if my memory is right, later versions did it through a straight multiplication. There must be some reason. Also, multiplication by 2 is *not* easy on IEEE conformant machines (think gradual underflow). Kahan had some (good) reasons to include gradual underflow. But IEEE machines might use the 'adjust exponent' primitive. On the other hand, IEEE says nothing about what has to be done in hardware and what can be done in software. And on your favorite machine (Cyber 205) DP multiplication by 2.0 need not even be exact! > > I agree that you know how to do certain types of optimizations. I suggest > that you make these optimizations available to those who have a more varied > collection of things to optimize. You (the computer science community) know > how to optimize, but have only a limited knowledge of what it is useful to > optimize. I do not criticise you for this lack of knowledge, but only for > failing to realize that you should be looking for input on this from others. Not so limited in fact. They use several tools to asses the suitability of different optimizations. There is no lack of knowledge, they use input from others: the programs that are normally run on their systems. > > We, and I include all of mankind, do not know enough about to design a good > system of communicating between people and computers now. We can design a > fair one by realizing this and allowing the users to extend the language, and > to communicate to the compiler this extension. As has been asked before: give examples. How would you like to write in your favorite language your favorite examples: 1. Check bit in a bit stream and mark as seen. 2. Calculate length of a run of 0's or 1's in a bit stream and mark them as seen. HINTS: They could be done along the lines of: bitstream b; bit b1; int count; /* another gripe of you */ external end_of_bits(); trap_at_bits_end(b, end_of_bits); b1 = nextbit(b); /* I hear you about infix operators */ count = countbits(b); /* should it count the bit just consumed? */ Next question: how do you envisage an *efficient* hardware implementation? If there is one, compilers are quite able to translate the above code to that implementation. If you know of that *efficient* hardware implementation and if it is present on a current architecture, just convince your compiler vendor to put that optimization in your compiler. If not, convince your hardware vendor to put the operations required in the hardware (and show how it can be done efficiently), and next convince your compiler vendor. I am not entirely against you. But both hardware designers and compiler writers have their reason to do things. At first I was disgusted to hear that the new SPARC architecture provides an integer division instruction without at the same time giving a remainder. Now I know the reasons, and I respect them. Contrary to the WE32000 which also has a division without remainder, *and* a remainder without quotient, without apparent reasons. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
peter@ficc.ferranti.com (peter da silva) (05/01/91)
If you want to specify a boolean operation on a float, do the following: f * 2.0 It's up to the compiler to determine if this multiplication by a constant two can be handled by incrementing the exponent or if you have to do a real floating multiply (say, for example, that it's m * e ^ 16). -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
hrubin@pop.stat.purdue.edu (Herman Rubin) (05/02/91)
In article <41279@genrad.UUCP>, jkw@genrad.com (J. Kyle Wilson) writes: > In article <11609@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > >In article <1991Apr30.025904.13028@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes: > >> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > >> >What is needed for the user to be able to communicate what operations are > >> >wanted. > >> I agree that the user should be able to instruction the computer. > >> However, I don't think I want to specify the assembly operations. > >> Instead, I want to manipulate numbers, sets, sequences, and objects in a > >> somewhat high-level fashion. Then I want the compiler to make very good > >> code out of my specification. > >But what if I find Boolean operations useful in dealing with floats, which > >I do for certain purposes? There are other operations which I can use for > >useful purposes, but only if they are fast. You do not know these operations, > >and the language community has seen fit to ignore what those who are capable > >of versatility can envision. > The language community has been providing the greatest good for the > greatest number where possible. If you have need of an optimization > that no one has seen fit to add to a compiler you are using your best > bet may be to hire a compiler writer to tweak it to handle that case. ....................... > Satisfying your requests would require the compiler to recognize a > large number of special cases each of which would likely be used by a > small segment of the user community, while requiring si ........................... Satisfysing my requests would require nothing of the sort. I see no reason why I should have to hire a compiler writer for each augmentation. I am asking the compiler writers and language designers to do what is normally done in other fields; do not freeze the language, and allow the user to augment it with convenient notation. Essentially this means that the user can put translations of his method of code into HLL or machine instructions, or even into other espressions. In some cases, even alternate translations should be giver, and the optimizer decide, again using user- supplied information. An optimal route to travel does not have to be restricted to major highways. Using lesser highways or even city streets may be more efficient. The route could also be dependent on the time of day and the type of vehicle. Do not deprive the driver of the gas pedal and the steering wheel. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
hrubin@pop.stat.purdue.edu (Herman Rubin) (05/02/91)
In article <3429@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes: > In article <11609@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: ....................... > > One of the reasons why, in the late 50s and early 60s, binary was settled on > > (there are many others) was that multiplication by powers of 2 was rather > > common. > I have heard many reasons, but never this one. Can you give a reference > please? An explicit place where I saw this was in a paper discussing the design of the MANIAC 2. > > Only a few machines have this very important operation in floating > > hardware, and instead have to bring in the multiplier and use the relatively > > slow multiplication. It is true that with pipelined hardware this is not so > > much of a problem, but I know of only a few machines which had it before then. > Mm, some 360's had it I think, but that was completely micro code, and if my > memory is right, later versions did it through a straight multiplication. > There must be some reason. Also, multiplication by 2 is *not* easy on IEEE > conformant machines (think gradual underflow). Kahan had some (good) reasons > to include gradual underflow. But IEEE machines might use the 'adjust exponent' > primitive. On the other hand, IEEE says nothing about what has to be done in > hardware and what can be done in software. And on your favorite machine (Cyber > 205) DP multiplication by 2.0 need not even be exact! On the 360 this would have been difficult, because the machine was base 16 rather than base 2. The machine has a floating instruction to halve. One machine which had this instruction was the CDC 3600. The instruction was ADX, add to exponent, and it managed overflows and underflows exactly the way that they would be for other floating operations. Clearly this can be a fast operation. I did not state that the 205 was a really well-designed machine, just that it is the most versatile vector machine I know. I am even inclined to agree that the virtual memory is not all that great. Not only may DP multiplication by 2.0 fail to be exact, even by 1.0. But compare this to the total nuisance to do DP operations on a CRAY, for example! In fact, it is not common for DP operations to be exact in general on most machines. ......................... > As has been asked before: give examples. How would you like to write in your > favorite language your favorite examples: > 1. Check bit in a bit stream and mark as seen. > 2. Calculate length of a run of 0's or 1's in a bit stream and mark them as > seen. > HINTS: > They could be done along the lines of: > bitstream b; > bit b1; > int count; > /* another gripe of you */ > external end_of_bits(); > trap_at_bits_end(b, end_of_bits); > b1 = nextbit(b); /* I hear you about infix operators */ > count = countbits(b); /* should it count the bit just consumed? */ This is the best I have been able to do for 1. In the envisioned applications, I would not be counting the bits, but transferring on them. Pardon the somewhat clumsier notation, as I am not used to trap pragmas. I am assuming registers are 32 bits. initialize pointers, etc. double int *end_of_bits, *loc; int left; registerpair r; if (left -= 1 < 0){ if(loc >= end_of_bits){ refill(); loc = start_of_bits;} left = 64; r = *loc++;} else r <<= 1; if (r < 0) goto ... For 2, I have not done as well even on scalar machines. On vector machines, allowing collapse of vectors, it can be done fairly easily by having the input bitstream act as a selection for consecutive integers, with appropriate handling of ends. It could be done by counting here, but generally there are faster methods, although they are tricky. I doubt that they would be recognized even if these are. > Next question: how do you envisage an *efficient* hardware implementation? Have hardware hold bitstreams, and have faults on end_of_bits, just as there are now page faults. The operations are not at all difficult from a hardware viewpoint. > If there is one, compilers are quite able to translate the above code to > that implementation. If you know of that *efficient* hardware implementation > and if it is present on a current architecture, just convince your compiler > vendor to put that optimization in your compiler. If not, convince your > hardware vendor to put the operations required in the hardware (and show > how it can be done efficiently), and next convince your compiler vendor. Do you really see a compiler writer recognizing that sequence of code, or one of its alternatives, as this operation? Especially since I, knowing that tests are bad, might use a slightly different code for such situations where I have some control on how many times the operation will be used between tests. This would enable the use of left -= 1; if (r<<=1 < 0) goto ... and the reloading of registers becomes much more complicated. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
peter@ficc.ferranti.com (peter da silva) (05/02/91)
In article <11713@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > I am asking the compiler writers and language designers to do what is > normally done in other fields; do not freeze the language, and allow the > user to augment it with convenient notation. There have been languages with that capability: Lisp, or Forth, or Smalltalk, for example. Why not look there for your needs? > Do not deprive the driver of the gas pedal and the steering wheel. No problem, but should the driver want to add a supercharger he should be expected to learn something about the engine. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
hrubin@pop.stat.purdue.edu (Herman Rubin) (05/02/91)
In article <WK=A6.G@xds13.ferranti.com>, peter@ficc.ferranti.com (peter da silva) writes: > If you want to specify a boolean operation on a float, do the following: > > f * 2.0 > > It's up to the compiler to determine if this multiplication by a constant > two can be handled by incrementing the exponent or if you have to do a real > floating multiply (say, for example, that it's m * e ^ 16). This is a boolean operation? I do not even see how to express it as one. It is a useful operation, however. But unless the appropriate hardware is there, the compiler better ask the user for permission. On most machines, adding to the exponent is safe only if neither overflow not underflow can occur, and if floats are automatically normalized, even positive numbers cannot be added to the exponent of 0. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
jimp@cognos.UUCP (Jim Patterson) (05/02/91)
In article <WK=A6.G@xds13.ferranti.com> peter@ficc.ferranti.com (peter da silva) writes: >If you want to specify a boolean operation on a float, do the following: > > f * 2.0 > >It's up to the compiler to determine if this multiplication by a constant >two can be handled by incrementing the exponent or if you have to do a real >floating multiply (say, for example, that it's m * e ^ 16). The problem with this is that the compiler rarely has enough information to determine if it's "safe" to just bump the exponent. Therefore it's left with the choice of doing a number of runtime checks (is f equal to zero? Is exponent already at upper limit?), or just punting and generating the naive "multiply by 2.0" instruction. I suspect most compilers will do the latter because it's ultimately more important to get the right answer. -- Jim Patterson Cognos Incorporated UUCP:uunet!mitel!cunews!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 x6112 3755 Riverside Drive Ottawa, Ont K1G 3Z4
ian@sibyl.eleceng.ua.OZ (Ian Dall) (05/03/91)
In article <11609@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >We, and I include all of mankind, do not know enough about to design a good >system of communicating between people and computers now. We can design a >fair one by realizing this and allowing the users to extend the language, and >to communicate to the compiler this extension. This is available. The best example I can think of is gcc/g++. I seem to recall someone (Chris Torek?) posting an example of gcc asm's before in this thread (or one of its many reincarnations). If the machine has an instruction you can use it! Certainly the syntax is a bit arcane, but you can't expect to "extend" a compiler without some knowledge of both the machine language and the compiler. This syntax need only be tackled once per function per machine. The results of your efforts can be hidden inside macros or inline functions in an include file. If you can find a few other people with like requirements, you can share your effort. Eventually your group might be able to settle on a proposal for a formal standard. In short the tools are available now if you don't mind a little effort. -- Ian Dall I'm not into isms, but hedonism is the most harmless I can think of. -- Phillip Adams ACSnet: ian@sibyl.eleceng.ua.oz internet: ian@sibyl.eleceng.ua.oz.au
wcs) (05/13/91)
In article <9596@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
]The problem with this is that the compiler rarely has enough
]information to determine if it's "safe" to just bump the exponent.
]Therefore it's left with the choice of doing a number of runtime
]checks (is f equal to zero? Is exponent already at upper limit?), or
]just punting and generating the naive "multiply by 2.0" instruction.
Of course, if your compiler includes the library support for it, it
COULD do a table lookup to find the new exponent, or to find that it
needs to do a real multiply. Similarly, this is usually the
fastest way to do bit-twiddling operations without (or even with)
special machine ops. Sure, with a PDP-11 you didn't want to waste
2K or 4K for a table, but on a 4MB machine with shared libraries it's cheap.
--
Pray for peace; Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
# I never wanted to be a hacker! I wanted to be --- a lumberjack!hrubin@pop.stat.purdue.edu (Herman Rubin) (05/13/91)
In article <1991May13.054124.8193@cbnewsh.att.com>, wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes: > In article <9596@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes: > ]The problem with this is that the compiler rarely has enough > ]information to determine if it's "safe" to just bump the exponent. > ]Therefore it's left with the choice of doing a number of runtime > ]checks (is f equal to zero? Is exponent already at upper limit?), or > ]just punting and generating the naive "multiply by 2.0" instruction. > > Of course, if your compiler includes the library support for it, it > COULD do a table lookup to find the new exponent, or to find that it > needs to do a real multiply. I suggest we look at the steps involved in carrying out this suggestion. First, we need to extract the exponent. Second, we need to do the table lookup. Third, we need to check for overflow/underflow and take the appropriate acticts. Fourth, we need to put the exponent back. It would probably be cheaper not to do the table lookup but to just include the instructions to check for overflow/underflow in the integer part of the operation. But this checking, plus the extraction/insertion, are likely to be considerably more expensive than the floating multiply. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)