aglew@ccvaxa.UUCP (12/05/87)
>> I believe that a combination of two things makes the mode bit >> unnecessary. First, intentional overflow is not terribly common, >> so the performance hit for a null trap handler would be small. > >> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) > >Unfortunately, there has been a tendency to denigrate the use of useful >hardware capabilities, and even to advocate eliminating them. The >use of condition codes and traps falls into this category. I have no >difficulty in producing examples in which the deliberate use of overflow >is the easiest and quickest way of accomplishing the desired result. >I suspect this does not occur more often _because programmers are taught >to think in regimented manners_ which do not include such things. > >Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Please, produce those examples where the deliberate use of overflow is best. And then let us discuss how portable the techniques are, what their performance impact is, how allowing overflow in such cases affects the rest of the language system, how safe permitting this is, etc. I am not being facetious. Providing the examples could lead to a useful discussion. But do not get hurt if you are shot down. The problem is that a combinatoric explosion of features leads to a slower or less safe system. The whole trend in recent computer architecture has been to make the most frequently used features faster, sometimes at the cost of making things that you would imagine to be more primitive *much* more expensive. Unfortunately, this sometimes means making things prohibitive, or impossible. But anyway, there is a tradeoff, and it has to be explored. By the way, I am not of the school "only put stuff used by 90% of your target audience in the system". I use frequency of use PLUS ease of implementation AND effect on the overall system as my guides. EG some infrequently used instructions should be included because (1) they are easy to implement, (2) they do not slow the system down, (3) some people can use them, and (4) it is possible that tomorrows compilers may be able to use them. But all these criteria have to be applied not only to the current target technology, but also to the technology over the lifetime of the architecture. And, beacuse you always have to be conservative, sometimes it's best to err on the side of not including features in early days. But then, when I'm programming a library, I try to implement all logically necessary functions, not just the ones I need today. Because I usually need them all in the long run. Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801 aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa My opinions are my own, and are not the opinions of my employer, or any other organisation. I indicate my company only so that the reader may account for any possible bias I may have towards our products.