hansen@mips.UUCP (11/12/87)
In article <197@m2.mfci.UUCP>, colwell@mfci.UUCP (Robert Colwell) writes: > I notice that nobody has taken up Wirth's challenge at the ASPLOS-II > conference concerning the dangers inherent in the current approach of > "performance above all else". He mentioned items like undetected > integer overflows and broken floating point processing as being the > norm. I bet he knows this, but he didn't mention it. The > problem is that when you've got several streams of floating point > operations in the air at the same time, you could have a royal mess > if any one of them takes an exception AND you have to handle it a la > IEEE. The MIPS R2010 floating-point coprocessor has _both_ precise floating-point exceptions, and overlapped execution of several floating-point operations. (Integer overflow exceptions, in fact all exceptions, are precise also.) All the required hooks to support full IEEE floating-point exception handling are present in the hardware and operating system environment; unfortunately, there aren't any standard language bindings for IEEE exception handling in the common languages. The hardware problems of handling exceptions adequately are easily solvable - the language design problems are much harder. As the title of Wirth's paper "Hardware Architectures for Programming Languages and Programming Languages for Hardware Architectures" imply, the hardware and software issues are inextricably linked. In fact, many of the lossages in existing instruction sets are echoes of common practice that has been buried in the definition of common languages. For example, the lack of overflow checking and array bounds checking in C may have started as a reflection of the hardware architectures in place at the time C was designed, but now to build a new machine that supports C, you must provide arithmetic operations without overflow checking, and the means to address arrays without bounds checking. A particular example that Wirth provides is the utterly stupid definition of integer division that gives mathematically useless answers for negative dividends - I've tried to specify division instructions that do it right on the last three architectures I've worked on, and was thwarted each time by the requirement to provide division the way the languages define it. Wirth then makes some comments to the effect that RISC design techniques that I personally think are way off the mark. In my mind at least, RISC has always meant a greater reliance on software technology, i.e., more complex compilers, and RISC designers have made conscious decisions to move complexity from hardware into software. To criticise RISC simply by saying that it doesn't fulfill the promise of simpler compilers is vacuous, because such a goal was never intended. In fact, compiler optimization techniques that RISC relies on so heavily are based on the notion that a computer program is "a static text amenable to mathmatical analysis and logical reasoning," the very notion he asserts that hardware designers have lost sight of. Wirth closes the paper by telling us that hardware designers was better stop relying on simulation and more on formal deductive reasoning and proofs of design correctness. However, he has lost sight of the prosaic fact that large hardware designs, like large software designs, aren't amenable to unassailable proofs of correctness of the entire design. OK, let's all see by an electronic show of hands, how many people manage to prove that all their software programs entirely meet the requirements of a bulletproof formal specification. (Uh huh. I though so.) Enough of the details; Wirth's basic argument is that architectures and programming languages should support each other, and basically be designed together. In the abstract, this possition is unassailable; however, the need for compatibility with old, badly designed languages will require that compromises be made in architectures. It is the saddest fact of life in the computer industry that the mistakes of the past will live virtually forever, because the wrong choices in language design will force continued wrong choices in architecture, which will perpetuate the bad choices in language design. My severe disappointment with Wirth's paper is that he chooses to place the blame on architecture designers, rather than take his fair share of the blame as a language designer. P.S.: Finding fault with the design of Pascal [yes, I know it's not his ultimate work] is shooting fish in a barrel. -- Craig Hansen Manager, Architecture Development MIPS Computer Systems, Inc. ...{ames,decwrl,prls}!mips!hansen or hansen@mips.com
alverson@decwrl.dec.com (Robert Alverson) (11/13/87)
I found Wirth's reference to DIV and MOD extremely ironic. In his book,
"Programming in Modula-2", he manages to define DIV the wrong way:
`Integer division is denoted by DIV and truncates the quotient.
For example
15 DIV 4 = 3
-15 DIV 4 = -3
15 DIV (-4) = -3
... x MOD y is defined for positive x and y only.'
If it wasn't for the examples, one could argue that he meant the
floor function when he said truncate, but the examples are explicit.
If one were to implement (-15 DIV 4) using shifts, the answer would
be -4, at least using a two's complement representation.
Bob
henry@utzoo.UUCP (Henry Spencer) (11/15/87)
> ... He mentioned items like undetected integer overflows... Sigh, I note that the SPARC architecture, which looks like it's going to be pretty popular, does not trap integer overflows. (At least, I don't recall it doing so -- I don't have the spec handy.) Of course, it sets the good old V bit, which you can check after every instruction if you don't mind the performance penalty... meaning that nobody who cares about performance will bother. Sigh. > ... For example, the lack of > overflow checking and array bounds checking in C may have started as a > reflection of the hardware architectures in place at the time... No, not correct. The "lack of overflow checking" is mythical -- C has *never* promised that except for unsigned integers, which exist partly for that specific purpose. Many implementations don't check overflow, and there is undoubtedly some code that depends on this, but this has little or nothing to do with the language. And array-bounds checking is (a) a little difficult to reconcile with the explicit pointer-based semantics of C's arrays, but nevertheless (b) possible in C, as witness at least one debugging-oriented implementation I know of. ([mount soapbox] Besides, run-time checking for such things is the wrong approach; no well-built program should ever do such things, and well- builtness is something that ought to be checkable at compile time -- a superior approach in every way except that implementation is harder and not entirely understood yet.) -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
bcase@apple.UUCP (Brian Case) (11/16/87)
Very early in the design of the Am29000, it was decided that instructions for integer arithmetic would be provided in both trap-on-overflow and no-trap-on-overflow versions. Without question, the thrust behind this decision came from Ole Moller, a Dane who has returned to his native Denmark. Ole was incredibly wonderful to work with: he had a real grasp of and desire for simplicity. He also had a real sensitivity to run-time checking. I am not trying to pigeon-hole people or sound negative in any way, but in general, I find that Europeans tend to have a real sympathy for run-time checking. I can't name one American, off the top of my head, to whom I would attribute the same concern. At least the concern would not, to me, be the distinguishing feature that, to me, it so often is in Europeans. Ole also first suggested that the Am29000 have assert instructions (many people can only think of them as "compare and trap" but the effect is really "trap if assertion is false") to support Ada-like constructs. This group of instructions became the cornerstone of the procedure-call mechanism we devised. The Am29000 has probably got way too many add and subtract instructions; while I was at AMD and making presentations to various groups, we got plenty of strange looks and laughingly-said remarks like "What the hell are these for?" In at least one case, the most caustic remarks came from some influential computer scientists. Whatever you think of these instrucdions, there is no incremental cost to trap 32-bit, two's complement, integer arithmeitc overflow. I guess the point is that while there is no less concern in America for correct programs, run-time checking is much more acceptable to the European mind-set. I hope I haven't offended anyone. Please feel free to set me straight if I deserve to be so set. I heard Wirth speak at ASPLOS, and although I really don't agree with him, I thought that it was good that he was there to represent the "other side." Comments?
roberts@cognos.uucp (Robert Stanley) (11/17/87)
In article <902@mips.UUCP> hansen@mips.UUCP writes: >Enough of the details; Wirth's basic argument is that architectures and >programming languages should support each other, and basically be designed >together. In the abstract, this possition is unassailable; however, the need >for compatibility with old, badly designed languages will require that >compromises be made in architectures. It is interesting to reflect on IBM's Project 801, where the RISC instructions were designed very much with the compiler writers in mind. In fact, if memory serves, it was the compiler writers who had the final say in a number of cases. What made this project so particularly interesting was that not only was it a PL/1 machine (in that PL/1 was the language for which the compiler was being developed in tandem with the hardware development), but that the compiler suite included a 370 (uh, 360) compatability mode. In the compatability mode, the target architecture was System/360 and optimized run-time code generated compared *extremely* favourably with output from the PL/1 Optimizer of the day. It is by no means obvious that the 801's architectural integrity had to be compromised to achieve this, with the caveat that perhaps 10 (or so) years ago there was less awareness..... Perhaps of more relevance was the PL/1 Optimizer, which maintained backwards compatability with the System/360 by steadfastly ignoring the System/370 extended instruction set. I forget just how long that particular piece of double-think was perpetuated. Robert_S -- Robert Stanley Cognos Incorporated S-mail: P.O. Box 9707 Voice: (613) 738-1440 (Research: there are 2!) 3755 Riverside Drive FAX: (613) 738-0002 Compuserve: 76174,3024 Ottawa, Ontario uucp: decvax!utzoo!dciem!nrcaer!cognos!roberts CANADA K1G 3Z4
lamaster@pioneer.arpa (Hugh LaMaster) (11/19/87)
In article <6743@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >Very early in the design of the Am29000, it was decided that instructions >for integer arithmetic would be provided in both trap-on-overflow and >no-trap-on-overflow versions. Without question, the thrust behind this >The Am29000 has probably got way too many add and subtract instructions; >while I was at AMD and making presentations to various groups, we got >plenty of strange looks and laughingly-said remarks like "What the hell >are these for?" In at least one case, the most caustic remarks came from >some influential computer scientists. Whatever you think of these >instrucdions, there is no incremental cost to trap 32-bit, two's complement, >integer arithmeitc overflow. Do the "trap" type instructions interact with a mask in the user context which sets which conditions will trap (one machine I know of allows users to specify their own routines for error handling of specific trapped errors); then, the user can turn error checking on for a specific process. I understand that some "non-trap" type instructions are there to support certain kinds of unsigned arithmetic, but there is virtually no cost even on a completely hardwired machine for some kind of system and user programmable control registers to give the user options on a per-process basis. Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov (Disclaimer: "All opinions solely the author's responsibility")
uday@mips.UUCP (11/19/87)
In article <6743@apple.UUCP>, bcase@apple.UUCP (Brian Case) writes: > I am not trying to pigeon-hole people or sound negative in any > way, but in general, I find that Europeans tend to have a real sympathy > for run-time checking. I can't name one American, off the top of my > head, to whom I would attribute the same concern. At least the concern > would not, to me, be the distinguishing feature that, to me, it so often > is in Europeans. Runtime checking is inefficient. The issue is efficiency vs.reliability. Wherever reliability is important, even Americans favor runtime checking. For example, ANNA- specification and verification project at Stanford. ANNA is a specification and verification language for Ada and it is intended to check program correctness at runtime. A rumor has it that the SDI software ( an American concern ) would be specified in ANNA. ..Uday-- uday@mips.com OR { ames, decwrl, prls, pyramid }!mips!uday
bcase@apple.UUCP (11/19/87)
In article <3440@ames.arpa> lamaster@ames.UUCP (Hugh LaMaster) writes: >Do the "trap" type instructions interact with a mask in the user context which >sets which conditions will trap (one machine I know of allows users to specify >their own routines for error handling of specific trapped errors); then, the >user can turn error checking on for a specific process. I understand that >some "non-trap" type instructions are there to support certain kinds of >unsigned arithmetic, but there is virtually no cost even on a completely >hardwired machine for some kind of system and user programmable control >registers to give the user options on a per-process basis. We asked ourselves essentially this question during the early days of 29000 design. No, there is no "trap on overflow" mode bit. The "non-trap" type instructions are there to support computations that you want to compute module 2^32; they were originally named "add modulo" or something like that (my compiler spit out "addm"). There are two add instructions that trap on overflow: add-signed-and-trap, and add-unsigned- and-trap (also add-with-carry-signed-and-trap and add-with-carry-unsigned- and-trap). As for the mode bit, we thought about it and discarded it as ugly. The same effect can be had by substituting the desired version of the add/sub instructions for the ones that are actually in the code when the program is loaded. Wait, before flaming, I know this sounds silly, but it can be done because all instructions are the same length (and have the same format in this case), and, something to which I have recently become sensitive, modes make simulation of architectures much more difficult (although the big jump in difficulty comes as you go from zero modes to one). We just didn't think there was really any justification for a mode bit. However, we were wrong at least once, so we could have been wrong on this one. Comments? Feelings? Experiences?
bcase@apple.UUCP (11/19/87)
In article <931@gumby.UUCP> uday@mips.UUCP (Uday Kurkure) writes: [Me saying that Europeans seem to be more concerned with runtime checking.] >Runtime checking is inefficient. The issue is efficiency vs.reliability. >Wherever reliability is important, even Americans favor runtime >checking. For example, ANNA- specification and verification project >at Stanford. ANNA is a specification and verification language for Ada and >it is intended to check program correctness at runtime. A rumor has it >that the SDI software ( an American concern ) would be specified in ANNA. I'm glad you brought up the issue of ADA. Disclaimer: it could very well be that I have my head relatively in the sand on ADA issues, but I do know a little bit about companies like Rational of Mountain View. I'll have to admit that they are examples of Americans who are concerned about runtime checking, and I should have thought of them off the top of my head. This is a pretty good example of what I mean. ADA is embraced much more affectionately in Europe than it is in the US, I would claim (in fact, isn't it true that ADA's design was influenced heavily by Eurpeans??? Correct me if I am wrong, but don't flame me.) As far as I know a lot of the sales by ADA-oriented companies have been in Europe! We were talking about the NOVA episode "How good is Soviet Science?" when it was mentioned that there, and in Europe, theoretical concerns are more important than practical concerns. This, I believe is the root. Ok, ok, you're right: this discussion belongs elsewhere.
uday@mips.UUCP (Uday Kurkure) (11/20/87)
>In article <931@gumby.UUCP> uday@mips.UUCP (Uday Kurkure) writes: > >[Me saying that Europeans seem to be more concerned with runtime checking.] > >>Runtime checking is inefficient. The issue is efficiency vs.reliability. >>Wherever reliability is important, even Americans favor runtime >>checking. For example, ANNA- specification and verification project >>at Stanford. ANNA is a specification and verification language for Ada and >>it is intended to check program correctness at runtime. A rumor has it >>that the SDI software ( an American concern ) would be specified in ANNA. > >This is a pretty good example of what I mean. ADA is embraced much more >affectionately in Europe than it is in the US, I would claim (in fact, >isn't it true that ADA's design was influenced heavily by Eurpeans??? You definitely have a point. Even, the chief designer of ANNA, Prof. Luckham is European- English. I just wanted to point out that the run-time checking has its place. ..Uday-- -- Disclaimer: My employer and me, have nothing to do with each other. It's a strictly business relationship. UUCP: uday@mips.com {ames,decwrl,prls,pyramid }!mips!uday
lamaster@pioneer.UUCP (11/20/87)
In article <6777@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: > >As for the mode bit, we thought about it and discarded it as ugly. The >same effect can be had by substituting the desired version of the add/sub >instructions for the ones that are actually in the code when the program >modes make simulation of architectures much more difficult (although the >big jump in difficulty comes as you go from zero modes to one). We just >didn't think there was really any justification for a mode bit. However, >we were wrong at least once, so we could have been wrong on this one. >Comments? Feelings? Experiences? I have the Feeling that a processor with floating point support is going to need mode bits anyway. But, I think it is a Good Idea to explicitly use different instructions for those cases where integer arithmetic is intended and those cases where modulo 32 bit arithmetic is intended. Sometimes when you are debugging something it sure is nice to be able to turn exceptions on and off at will, though, for the "normal" integer, and also floating point, arithmetic. But not, strictly speaking, Necessary. I must admit that while I worry about the cost of particular hardware features, I don't worry about the cost of designing, simulating, and testing them. My job is usually to worry about the cost of debugging the software. Hugh LaMaster, m/s 233-9, UUCP {topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov (Disclaimer: "All opinions solely the author's responsibility")
dupuy@amsterdam.columbia.edu (Alexander Dupuy) (11/23/87)
In article <1775@cognos.UUCP> Robert Stanley writes about IBM's 801 project: >... the compiler suite included a 370 (uh, 360) compatability mode. In the >compatability mode, the target architecture was System/360 and optimized >run-time code generated compared *extremely* favourably with output from the >PL/1 Optimizer of the day. It is by no means obvious that the 801's >architectural integrity had to be compromised to achieve this, with the caveat >that perhaps 10 (or so) years ago there was less awareness..... Perhaps I'm misunderstanding you, but do you mean to say that the 801 had a 360/370 emulation mode? My understanding was that the PL/I (actually, PL.8) compiler generated machine-independent intermediate code, which was transformed by a later pass into 801 machine code. A back-end to convert the intermediate code into 370 machine code existed, and there were other compilers which generated intermediate code in the same format (including a C compiler, if I recall rightly). I have no idea if any of these things ever saw the light of day outside IBM, though. @alex --- arpanet: dupuy@columbia.edu uucp: ...!seismo!columbia!dupuy
franka@mmintl.UUCP (Frank Adams) (11/26/87)
In article <6777@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >In article <3440@ames.arpa> lamaster@ames.UUCP (Hugh LaMaster) writes: >>Do the "trap" type instructions interact with a mask in the user context >>which sets which conditions will trap? > >We asked ourselves essentially this question during the early days of 29000 >design. No, there is no "trap on overflow" mode bit. I think 29000 got it right. To the person who sometimes enables trapping for debugging purposes: I would suggest that if you want the traps enabled for debugging, you should have them on in the finished product -- thus generating add-with-trap instructions instead of add-without-trap instructions. Performance is oft-times a good reason for disabling run-time error-checking, but the same does not apply to error-trapping. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
roberts@cognos.uucp (Robert Stanley) (11/29/87)
In article <5157@columbia.edu> dupuy@amsterdam.columbia.edu (Alexander Dupuy) writes: >Perhaps I'm misunderstanding you, but do you mean to say that the 801 had a >360/370 emulation mode? My understanding was that the PL/I (actually, PL.8) >compiler generated machine-independent intermediate code, which was transformed >by a later pass into 801 machine code. A back-end to convert the intermediate >code into 370 machine code existed ... I stand corrected - apologies to any misled by my earlier posting. Alexander Dupuy is quite right that intermediate code was output and then post-processed in various ways, including register allocation optimization (by graph colouring) and code generation for specific target machine. Amazing how quickly unused knowledge decays! >I have no idea if any of these things ever saw the light of day outside IBM Not in the form originally worked with in Building 801. However, the same RISC architecture became both the RT PC and the heart of a number of key pieces of the big mainframe systems. I have no idea what is currently used to program such equipment. -- R.A. Stanley Cognos Incorporated S-mail: P.O. Box 9707 Voice: (613) 738-1440 (Research: there are 2!) 3755 Riverside Drive FAX: (613) 738-0002 Compuserve: 76174,3024 Ottawa, Ontario uucp: decvax!utzoo!dciem!nrcaer!cognos!roberts CANADA K1G 3Z4
bcase@apple.UUCP (Brian Case) (12/02/87)
In article <1883@cognos.UUCP> roberts@cognos.UUCP (Robert Stanley) writes: [Talking about the Yorktown 801 simple machine architecture.] >Not in the form originally worked with in Building 801. However, the same RISC >architecture became both the RT PC and the heart of a number of key pieces of >the big mainframe systems. Just in the interest of accurate information, the RT PC processor architecture is *very* unlike the 801 processor architecture. The 801 had some influence on the RT PC, but the implementation constraints were different. I have heard only nth-hand information that the 801 in unadulterated form is used as an I/O processor in mainframes.
mash@mips.UUCP (John Mashey) (12/03/87)
In article <6877@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >Just in the interest of accurate information, the RT PC processor >architecture is *very* unlike the 801 processor architecture. The >801 had some influence on the RT PC, but the implementation constraints >were different. I have heard only nth-hand information that the 801 >in unadulterated form is used as an I/O processor in mainframes. Yes. They basically said that they felt they had to do an uncached design to getthe costs low enough. That led them to go for more dense instructions to cut down on the instruction bandwidth. That led them to cut the number of registers from 32 to 16 (before they did more studies that yielded the 24-28 register dropoff point). The 801s are supposed to be channel controllers for 3090s. However, you can buy 2 machines that are clearly 801-descendents: HP Precision and MIPS R2000, which, as far as I can tell, are the closest ones on the market to the 801. Whenever it comes out, the 78000 has a lot of similarities also. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
reggie@pdnbah.UUCP (George Leach) (12/03/87)
In article <6877@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >In article <1883@cognos.UUCP> roberts@cognos.UUCP (Robert Stanley) writes: > >[Talking about the Yorktown 801 simple machine architecture.] > >I have heard only nth-hand information that the 801 >in unadulterated form is used as an I/O processor in mainframes. About a year and a half ago I wrote an overview paper on RISC architecture for a class that I was taking in Computer Management. I asked Herbie Chong, from the Watson Research Center in Yorktown Heights, what had become of the 801. I paraphrased his e-mail responce as follows: "Finally, the 801 is used as the processor controller in the IBM 3090 mainframe. A processor controller monitors all memory, device controllers, I/O channels, and handles console interaction when the 3090 itself is unable to do so." I beleive since that time the UUCP machine at Yorktown Height, polaris, is no more. So I don't even know if anyone there is on the net and can offer their insights. George W. Leach Paradyne Corporation {gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207 Phone: (813) 530-2376 P.O. Box 2826 Largo, FL 34649-2826