Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.unix.xenix,comp.sys.intel,comp.sys.ibm.pc
Subject: Re: XENIX 386 benchmark results
Message-ID: <2413@hoptoad.uucp>
Date: Mon, 13-Jul-87 08:04:52 EDT
Article-I.D.: hoptoad.2413
Posted: Mon Jul 13 08:04:52 1987
Date-Received: Tue, 14-Jul-87 02:43:53 EDT
References: <127@spdcc.COM> <225@m10ux.UUCP> <139@spdcc.COM> <130@bby-bc.UUCP> <826@mipos3.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 24
Xref: mnetor comp.unix.xenix:468 comp.sys.intel:303 comp.sys.ibm.pc:5629

kds@mipos3.UUCP (Ken Shoemaker) wrote:
>         My guess as to why 32-bit code seems to run so much faster than 16-bit
>code on the 386 has to do with the differences in the programming model between
>16-bit and 32-bit code: 32-bit code is always "small" mode (i.e., no segment
>register reloads), ...
> -- 
> The above views are personal.

I construe this as a "personal" statement by an Intel chip designer
that the whole concept of memory models and segment registers is wrong
-- not only did it make life hell for programmers [who bought Intel
machines], but he points out that the generated code using those models
is much slower, even on their whizziest new chip.

The statement that 32-bit code is always "small mode" belies the
waffling in the 386 architecture manuals that extolls the virtues of
segment registers even in a 32-bit address space.  They should have
been honest enough to describe them as a hack for 8086 compatability,
useless in other modes.

Welcome to reality, Intel!  Glad to have you with us.  And thanks for fixing it.
-- 
{dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu	     gnu@postgres.berkeley.edu
Alt.all: the alternative radio of the Usenet.