Xref: utzoo comp.arch:10540 comp.lang.misc:3050 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!ames!ncar!ico!ism780c!haddock!suitti From: suitti@haddock.ima.isc.com (Stephen Uitti) Newsgroups: comp.arch,comp.lang.misc Subject: Re: Double Width Integer Multiplication and Division Message-ID: <13970@haddock.ima.isc.com> Date: 7 Jul 89 20:04:14 GMT References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <13961@haddock.ima.isc.com> <1395@l.cc.purdue.edu> Reply-To: suitti@haddock.ima.isc.com (Stephen Uitti) Organization: Interactive Systems, Boston Lines: 133 >For division with remainder, the code should >be machine language, not C. Would you use C to do machine-independent >implementation of division? You would not think of it. Neither would >I think of making similar operations such as frexp, divrem, exponentiation, >absolute value, integer part, etc., machine independently coded in C. >I would not consider coding the =UP above in C. It is an additional >primitive operation, like +, *, /, &. Not only would i think of it, i've done it. A check is made to see that the compiler really generates the right instructions. >I consider the 205 hardware the best designed vector hardware I have >seen. No real debate here. The '205 was a real ambitious project. Very, very difficult and costly to maintain, but real nice. Current RISC machines are also ambitious, but in a differant way. The goal is to make something simple enough to support that is also fast enough to be viable. The '205 lost the commercial race. Mr Cray, who has been designing RISC architectures since the dawn of time, is one of the winners. > It is the C language which is inadequate. And there is a severe >limit to what should be portable. >> >I want to write >> > q,r = x/y; >> Unfortunately, this already means something in C. > >What does it mean? It means "evaluate the expression 'q', then the expression 'r = x/y'. The fact that 'q' is a variable doesn't mean anything. It is treated as an 'rvalue' (one that gives a result) rather than as an 'lvalue' (where to put a result). The comma operator is extremely basic to the language. It is probably a flaw in the language design that it is programmer visible. It is not a flaw that i would suggest fixing. >Would putting the q,r in parentheses or something else >avoid the conflict? Parenthesis will screw up something. There is probably a fix, but it won't be provable off the top of my head. >> >At the present time and in the future, loads and stores must slow things >> >down unless they can be overlapped. >> >> Or optimized out. > >I consider a programmer quite inept who does not know what is temporary and >what is not. A compiler evaluating an expression generally produces all sorts of temporary variables. These are typically kept in registers, but sometimes overflow - often to the stack. On a machine like the 205, with its near infinite register count, one would imagine that there would never be register overflow. >making this distinction and figure it out. A compiler is fast, but does >not compare in intelligence with a human imbecile. Sure it compares. The compiler is faster. The compiler is correct more often. The human probably knows how to breath and eat. The compiler has no need for breathing or eating. Of course, there's the 'idiot savant', but i've never met one who was actually much of an imbecile. >The value of a compiler and language is ease of programming. In this, >notation and flexibility are extremely important. If a mathematician >finds notation missing, he invents it for his paper. It may or may not >be adopted by others, but that does not prevent people from reading his >paper. While i find such papers hard to read (especially since the definition of the new notation syntax is seldom given), for programs it is worse. Even with the C preprocessor's limited capabilities, one can write code that doesn't bear any resemblence to C. Maintanence of this code is nearly impossible. Thus, sadly, notation flexibiltiy and maintainability are at odds. >A simple example of the lack of desirability >of C portability is the addition of two vectors. The good coding of this >depends on the costs of the *x++ in loading and storing and the use of >index in loading and storing. These depend both on the machine and the >storage classes of the adresses. The code sequence is: void lvecadd(a, b, c, s) /* a = b + c, length s */ long *a; long *b; long *c; long s; { do { *a++ = *b++ + *c++; } while (--s != 0); } or: void lvecadd(a, b, c, s) /* a = b + c, length s */ long *a; long *b; long *c; long s; { register long t; for (t = 0; i < s; t++) a[t] = b[t] + c[t]; } A '205 C compiler should (doesn't but should) take either piece of code and translate it into the instruction. I've seen a C compiler which did better for the second example than the first. What was odd was that the target machine, a 68000, does better with the first algorithm. Worse, the second peice of code was effectively translated into the first, using redundant temporary variables for the pointers. Somehow, the compiler thought that extra work had to take place for the first example. The point, though, is that the programmer visible syntax need not bear any resemblence to the quality of the produced code. Portability has its costs - usually about 10 to 20% of the optimum machine speed. Compiler technology has been attempting to narrow this. However, it has enourmous benifits. UNIX, being somewhat portable, allows new architectures to become useful in an extremely short time after manufacture (something like a year). The speed penalty that comes from UNIX not being designed for the architecture is offset by the years of development that it takes to create a new OS. By that time, the architecture may well be obsolete. User applications are the same way. The value of using a portable language is more than just being able to use code that was written on one machine on another. It takes time for programmers to become proficient in a language. If you write a new language for every program you write, no one will be able to make heads or tails of what you've done.