Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP Path: utzoo!utcsri!greg From: greg@utcsri.UUCP (Gregory Smith) Newsgroups: comp.arch Subject: Re: 64 Vs 32 (386 addressing) Message-ID: <4372@utcsri.UUCP> Date: Mon, 16-Mar-87 11:58:40 EST Article-I.D.: utcsri.4372 Posted: Mon Mar 16 11:58:40 1987 Date-Received: Tue, 17-Mar-87 00:46:48 EST References: <3810013@nucsrl.UUCP> <28200016@ccvaxa> Reply-To: greg@utcsri.UUCP (Gregory Smith) Organization: CSRI, University of Toronto Lines: 103 Summary: You want modes? we got MODES!! In article <28200016@ccvaxa> aglew@ccvaxa.UUCP writes: > >...> 64 bit machines > >One respondent seemed to be under the impression that a "64 bit machine" >implied that the minimum addressible unit was 64 bits. That's another ?maximum? >tradeoff entirely. What I mean, and what I think is being talked about, >is machines that have address sizes (and integers, etc.) of 64 bits. I discussed in my last posting machines with >32 bit addresses. Out of context, though, I take '64-bit-machine' to imply a 64-bit wide data path and memory system. I suspect the practice of giving the size of the address originated when IBM called the 8088 a 16-bit CPU and Apple retaliated by calling the 68000 a 32-bit CPU. Remember (back around '83 or so) when 8080 (CP/M) and 8088 (IBM PC) software were distinguished in the consumer mags simply by being called '8-bit' and '16-bit' software? Bizarre market. > >>32 bit machines are already here: the IBM RT ROMP has a 40 bit >virtual address and I've seen articles saying that the 80386 has a 16T >address space (Milutinovc in last month's computer). What are the >exact specs on the 80386? This is largely marketingese. The 386 has ten 32-bit registers, corresponding to ten 16-bit registers on the 86/286 (and six of them corresponding to six 16-bit registers on the 8080 hee hee haw haw). It also has six 16-bit segment registers. Four of these correspond to the 86's registers; two are just extra extra segments (FS and GS). Like on the 286, these are 'magic' registers; when you load a number into one of them in any way, the CPU goes off behind your back and reads the segment descriptor for that segment. Thus there are six sets of hidden registers, one for each segment: A 'physical base' register, giving the base address of the segment (unlike the 86, this can be specified down to the byte); A 'size' register, giving the length of the segment ( stack segments can grow backwards, like on the 286 ); and access information. The access information indicates whether you can read, write, or execute the segment (in a nutshell, anyway). Intel calls all these registers a 'segment cache', although the loading of the registers is under program control. If you load the same segment number twice into a segment reg, it will load the info twice ( at least on the 286 ). The difference between the 286 and the 386 in this area is this: The 286 allows segment bases to be specified as a 24-bit quantity, and segment lengths to be given in 16 bits. This gives 64K segments within a 16 Meg address space. The 386 extends both by 8 bits; thus the segment base is specified in 32 bits and the length in 24. This allows 16-meg segments in a 4 GIG physical space. (This is gleaned from a 286 book and a glossy article (Micro Dec 85) on the 386). The article says that 4-Gig segments are possible, so there must be an option in the 386 segment descriptor to select 'huge' segments where the size is given in units of 256 bytes. Or something. The article says that the virtual address space is 2^46, or 64 Terabytes. This is arrived at as follows: A virtual address is given by a 32-bit offset and a 16-bit segment selector. Two of the selector bits are a privilege level, and do not contribute to the selection process, so you get 14+32 = 46. If you are using segmentation, you will probably have <1000 segments active per process, and segment sizes varying from a few bytes to a few 100k. Thus this 64TB address space is extremely sparse in practice, which can be seen as a good thing in terms of fault protection. It is obtained at the expense of constantly loading the segment registers whenever you have to look at something you may not have looked at recently (and the associated cost of reading 2 doublewords of descriptor). Another difference: the 386 has a conventional paging unit, which can be used to translate the 32-bit address produced by the segmentation unit into a physical memory address. Thus you can scrap the segment registers (by pointing them all to the same huge segment and ignoring them) and just use paging, e.g. to run BSD. Under this model, the virtual address space is 4 Gig. Of course, you can use the segment registers as intended and use the paging unit too (It slices, it dices...) An inference: from the description in the article, I have to conclude that the 386 has its own instruction set ( the 286 opcode space is too full, and does not contain the kind of instructions that you would want in a 32-bit machine, or the addressing modes described in the article). Thus the 386 has two instruction modes (386/286 opcodes). I imagine the 286 instructions are available with different encoding (and probably different addressing) within the 386 set. Maybe they'll make one that runs 6502 code too so we can make Apple-compatible PC's. One of the problems with the 286 is that, although it can emulate the 86's segmentation (base = 16*seg #, length = 64k, access = any), it can only do so when the more powerful segmentation (and task switching) stuff is disabled ( I.e. in Real Address Mode). This means that you can run an 8086 OS on your 286, but you can't run an 8086 program under an operating system which uses the 286's features. The 386 has a mode (VM86) which can be selected to provide 8086 segment emulation on a per-process basis, and presumably protect the rest of the system from the internally unprotected 8086 process. The 386, like the 286, powers up in 'global' 86 mode. -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...