Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2(pesnta.1.2) 9/5/84; site idsvax.UUCP
Path: utzoo!utcs!lsuc!pesnta!idsvax!steiny
From: steiny@idsvax.UUCP (Don Steiny)
Newsgroups: net.arch,net.lang.c,net.micro,net.micro.pc,net.micro.68k
Subject: Re: Re: Re: Re: Need 286 "C" benchmark
Message-ID: <142@idsvax.UUCP>
Date: Mon, 27-May-85 01:14:00 EDT
Article-I.D.: idsvax.142
Posted: Mon May 27 01:14:00 1985
Date-Received: Mon, 27-May-85 07:32:23 EDT
References: <426@oakhill.UUCP> <8745@microsoft.UUCP> <583@intelca.UUCP> <433@oakhill.UUCP>, <588@intelca.UUCP> <5631@utzoo.UUCP>
Organization: Personetics, Inc. - Santa Clara
Lines: 15
Xref: utcs net.arch:1240 net.lang.c:5202 net.micro:10188 net.micro.pc:4005 net.micro.68k:803

**

	The  articles that this one follows up discuss the
fairness or unfairness of using a benchmark that uses more
than 64K of data.

	To access data in a range greater that 64K a 286 program
needs to load the segement discriptor table to find the base 
of the segment.  This requires TWO register loads for each access,
even if the correct table is already loaded.   To make matters
worse, there are no registers that are truly general purpose.

	In short, no matter how fast an Intel chip gets, 
the segmentation and the lack of general purpose registers
are going to continue to be a limiting factor (unless they change).