home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!ariel!davidsen
- From: davidsen@ariel.crd.GE.COM (william E Davidsen)
- Newsgroups: comp.arch
- Subject: Re: What's in a name?
- Message-ID: <1992Jul28.153347.23415@crd.ge.com>
- Date: 28 Jul 92 15:33:47 GMT
- References: <1992Jul25.075130.7192@spool.cs.wisc.edu> <1992Jul27.165807.29014@adobe.com> <1992Jul27.214015.4138@kithrup.COM>
- Sender: usenet@crd.ge.com (Required for NNTP)
- Reply-To: davidsen@crd.ge.com (bill davidsen)
- Organization: GE Corporate R&D Center, Schenectady NY
- Lines: 26
- Nntp-Posting-Host: ariel.crd.ge.com
-
- In article <1992Jul27.214015.4138@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
-
- | The segmentation scheme is crucial to the chip; you can, for example, have a
- | task with 16-bit and 32-bit segments. I.e., there isn't a "32-bit mode,"
- | instead, there are 32-bit *segments*.
- |
- | The chip would have been far worse had they come up with two seperate modes
- | for the '386.
-
- Please clarify what you mean by this one. If you mean data access
- modes, I seem to remember using 32 bit prefixes to select 32 bit data
- access operation (real mode), so it's not that. Does that mean a 16 bit
- segment is a data segment and data accesses in it are 16 bit, or that
- addresses relative to that segment are only 16 bit offsets, or that I
- have 16 bit code segments where addresses and data access both behave
- differently, or what?
-
- I will have to see if I can find my processor manual, because this
- doesn't fit with anything I remember about the chip. Bear in mind I only
- did assembler for this chip for a few months until a 32 bit o/s came out
- (about 1987).
- --
- bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
- It never ceases to amaze me that otherwise rational people, able to
- understand calculus, compound interest, and the income tax form, can
- continue to believe that poker is a game of chance.
-