Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch,net.lang.c,net.micro,net.micro.pc,net.micro.68k Subject: Re: Re: Re: Need 286 "C" benchmark Message-ID: <993@peora.UUCP> Date: Wed, 29-May-85 08:32:37 EDT Article-I.D.: peora.993 Posted: Wed May 29 08:32:37 1985 Date-Received: Thu, 30-May-85 06:02:03 EDT References: <426@oakhill.UUCP> <8745@microsoft.UUCP> <583@intelca.UUCP> <433@oakhill.UUCP> <589@intelca.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 46 Xref: watmath net.arch:1269 net.lang.c:5312 net.micro:10560 net.micro.pc:4071 net.micro.68k:824 > Here we are discussing compilers again, Microsoft has yet to > release a compiler that can deal with large arrays, the 286 has a > 1Gbyte virtual address space and hence plenty of room. I > personally can write the "benchmark" in assembly quite easily, > again the COMPILER can't hack it but the chip can. You were going along so well there, I was going to ignore your grossly irritating suggestion that C "short"s should be bytes, until you said this. You can't really blame the compiler writers for being unable to generate efficient code for a deficient architecture. You give someone an intractable problem, then complain that they can't solve it! The reason you can write the benchmark in assembly quite easily but the compiler can't is that doing it requires knowledge of the semantics of the program that are unavailable to the compiler. For example, you know when you need to change your segmentation registers and when you can leave them alone. The compiler can in some cases, if it's a compiler like our Fortran compiler that does complex flow analyses of the code; but there are very few such compilers out there, and especially not for microcomputers, yet. But it can't possibly do it in all cases. In particular, it probably can't do it in programs that make heavy and unstructured use of GOTOs. I think someone who is well-versed in complexity theory can show that the halting problem is equivalent to this segmentation-register-switching problem (just replace an arbitrary segmentation register use with a halt instruction), but that's not my specialty, so I will not try to do that rigorously. However, one other thing. Someone asked in here awhile back, "why should I care if it is hard for the compiler writers to write the compilers?" Well, I've seen that firsthand. It's because it increases the probability that you'll get a compiler with bugs. Now, anything, no matter how difficult, gets solved if you wait long enough (if it's solvable); but it's generally better to get it solved in a reasonable amount of time. DISCLAIMER: the above are just my opinions. They aren't necessarily Perkin-Elmer's. I don't even know if we use 808x's or not! -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "V'z bss gb gur Orezbbgurf, gb jngpu gur bavbaf na' gur rryf!" [Jryy, jbhyq lbh oryvrir Arj Wrefrl?]