Xref: utzoo comp.sys.mac.misc:12884 comp.windows.ms:13507
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ucla-cs!ucivax!orion.oac.uci.edu!ucsd!nosc!baron!ryptyde!dant
From: dant@ryptyde.UUCP (Daniel Tracy)
Newsgroups: comp.sys.mac.misc,comp.windows.ms
Subject: Re: Mac Vs. Windows? (sorry)
Message-ID: <20@ryptyde.UUCP>
Date: 5 Jun 91 10:47:50 GMT
References: <0E010021.e0mxxc@gla-aux.uucp> <1991Jun4.154854.19649@dbase.A-T.COM>
Reply-To: dant@ryptyde.UUCP (Daniel Tracy)
Followup-To: comp.sys.mac.misc
Organization: Ryptyde Timesharing
Lines: 19

Responding to the following:

"Correct me if I am wrong, but in small (or tiny) memory model apps,
the 80x86 is essentially a linear-addressing processor.  I would tend
to think it would be faster shuffling 16-bit addresses (since the
segment registers do not change) than a Motorola with (is it?) 32-bit
addresses."

Well, not really. I'm assuming that even though the segment "window" doesn't
have to be moved, the accessing routine is still slower. The window doesn't
change, but it's still there. In order to request a memory address, a segmented
chip must do an extra multiply (at least) every time. That is, it multiplies
the address location within any segment by the segment being used, so it doesn't act as linear-addressing at all. The 386+ DOES have a fairly good linear
memory mode, but this isn't used by any OS's except for Unix. Also, there are
many other factors in 680x0 vs 80x86. Intel's line doesn't even come close
in most cases to MC's chip line. Also, because the 80x86 began as 16-bit chips
internally, many kludges had to be performed in order to maintain compatibility
across the line, and thus the 680x0 line is also accelerating past the 80x86
at a faster clip because it isn't being held back by mode up mode implimentation. Sorry is this letter isn't spaced properly.