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.