🚀 go-pugleaf

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...