Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site gumby.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!uwvax!gumby!g-inners From: g-inners@gumby.UUCP Newsgroups: net.micro,net.micro.68k Subject: Re: Need 286 "C" benchmark Message-ID: <389@gumby.UUCP> Date: Wed, 29-May-85 12:58:12 EDT Article-I.D.: gumby.389 Posted: Wed May 29 12:58:12 1985 Date-Received: Fri, 31-May-85 02:42:41 EDT References: <426@oakhill.UUCP> <8745@microsoft.UUCP> <583@intelca.UUCP>, <433@oakhill.UUCP> <181@anwar.UUCP> Organization: U of Wisconsin CS Dept Lines: 20 Xref: linus net.micro:9293 net.micro.68k:771 > I'm currently porting a huge application program to the PC/AT and running > into brick walls every day due to the 286 archictecture. > Things like: An architecture has many more effects than realized. These problems can always be blamed (unfairly) on the compiler, but they are really architectural limitations "showing through" the veil. Architecture problems also "show through" operating systems. Lots of 360/370 limitations cropped up as arbitrary limits in various high-level language implementations also. I think it is fair to have benchmarks that exploit architectural weaknesses. There is a reason why so many compilers for the 286 don't support large data objects. Because the architecture makes it hard/slow/ugly. So don't dismiss the architectural debates as meaningless. Today's quible over instruction formats may show up as tommorow's compiler limit or bug. -- Michael Inners