Need 286 "C" benchmark

[J. Eric Roskos]

> 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?]