Re: 80286 protected mode

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

antispam@fricas.org (Waldek Hebisch) writes:

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

antispam@fricas.org (Waldek Hebisch) writes:

From my point of view main drawbacks of 286 is poor support for
large arrays and problem for Lisp-like system which have a lot
of small data structures and traverse then via pointers.

 
Yes.  In the first case the segments are too small, in the latter case
there are too few segments (if you have one segment per object).

>
In the second case one can pack several objects into single
segment, so except for loct security properties this is not
a big problem.

 
If you go that way, you lose all the benefits of segments, and run
into the "segments too small" problem.  Which you then want to
circumvent by using segment and offset in your addressing of the small
data structures, which leads to:
 

But there is a lot of loading segment registers
and slow loading is a problem.

 
...

Using 16-bit offsets for jumps inside procedure and
segment-offset pair for calls is likely to lead to better
or similar performance as purely 32-bit machine.

 
With the 80286's segments and their slowness, that is very doubtful.
The 8086 has branches with 8-bit offsets and branches and calls with
16-bit offsets.  The 386 in 32-bit mode has branches with 8-bit
offsets and branches and calls with 32-bit offsets; if 16-bit offsets
for branches would be useful enough for performance, they could
instead have designed the longer branch length to be 16 bits, and
maybe a prefix for 32-bit branch offsets.

>
At that time Intel apparently wanted to avoid having too many
instructions.

 
Looking in my Pentium manual, the section on CALL has a 20 lines for
"call intersegment", "call gate" (with priviledge variants) and "call
to task" instructions, 10 of which probably already existed on the 286
(compared to 2 lines for "call near" instructions that existed on the
286), and the "Operation" section (the specification in pseudocode)
consumes about 4 pages, followed by a 1.5 page "Description" section.
 
9 of these 10 far call variants deal with protected-mode things, so
Intel obviously had no qualms about adding instruction variants.  If
they instead had no protected mode, but some 32-bit support, including
the near call with 32-bit offset that I suggest, that would have
reduced the number of instruction variants.

I wrote "instructions".  Intel clearly used modes and variants,
but different call would lead to new opcode.
 

I used Xenix on a 286 in 1986 or 1987; my impression is that programs
were limited to 64KB code and 64KB data size, exactly the PDP-11 model
you denounce.

>
Maybe.  I have seen many cases where sofware essentiallt "wastes"
good things offered by hardware.

 
Which "good things offered by hardware" do you see "wasted" by this
usage in Xenix?

Medimu mode and shared segments.  Plus escape for programs needing
bigger memory (traditional Unix programs by neccesity fit in 64kB
limits).

To me this seems to be the only workable way to use
the 286 protected mode.  Ok, the medium model (near data, far code)
may also have been somewhat workable, but looking at the cycle counts
for the protected-mode far calls on the Pentium (and on the 286 they
were probably even more costly), which start at 22 cycles for a "call
gate, same priviledge" (compared to 1 cycle on the Pentium for a
direct call near), one would strongly prefer the small model.

I have found instruction list on the web which claims 26 + m cycles
where m in "length of next instruction" (whatever that means) for
protected mode call using segement.  Real mode call using segement
is 13 + m cycles.  Near call call is 7 + m cycles.

Intel clearly expected that segment-changing calls are infrequent.
AFAICS this was better than system conventions on IBM mainframes
where "standard" call normally called memory allocation function
to allocate stack frame.  I do not have data for VAX handy, but
VAX calls were quite complex, so probably also not fast.

And modern data at least partially confirms Intel beliefs.  When
AMD introduced 64-bit mode thay also introduced complex calling
convention intended to optimize speed of calls.  Later there
was a paper by Intel folks essentially claiming that this
calling convention does not matter: C compilers inline small
routines, so cost of calls relatively to other things is quite
small.  I think that what was inlined in 2010 would be called
using near calls in 1982.

Every successful software used direct access to hardware because of
performance; the rest waned.  Using BIOS calls was just too slow.
Lotus 1-2-3 won out over VisiCalc and Multiplan by being faster from
writing directly to video.

>
For most early graphic cards direct screen access could be allowed
just by allocating appropriate segment.  And most non-games
could gain good performance with better system interface.
I think that variaty of tricks used in games and their
popularity made protected mode system much less appealing
to vendors.  And that discouraged work on better interfaces
for non-games.

 
MicroSoft and IBM invested lots of work in a 286 protected-mode
interface: OS/2 1.x.  It was limited to the 286 at the insistence of
IBM, even though work started in August 1985, when they already knew
that the 386 was coming soon.  OS/2 1.0 was released in April 1987,
1.5 years after the 386.
 
OS/2 1.x flopped, and by the time OS/2 was adjusted to the 386, it was
too late, so the 286 killed OS/2; here we have a case of a software
project being death-marched by tying itself to "good things offered by
hardware" (except that Microsoft defected from the death march after a
few years).
 
Meanwhile, Microsoft introduced Windows/386 in September 1987 (in
addition to the base (8086) variant of Windows 2.0, which was released
in December 1987), which used 386 protected mode and virtual 8086 mode
(which was missing in the "brain-damaged" (Bill Gates) 286).  So
Windows completely ignored 286 protected mode.  Windows eventually
became a big success.

What I recall is a bit different.  IIRC first successful version of
Windows, that is Windows 3.0 had 3 modes of operation: 8086 compatible,
286 protected mode and 386 protected mode.  Only later Microsoft
dropped requirement for 8086 compatiblity.  I think still later
it dropped 286 support.  Windows 95 was supposed to be 32-bit,
but contained quite a lot of 16-bit code.  IIRC system interface
to Windows 3.0 and 3.1 was 16-bit and only later Microsoft
released extention allowing 32-bit system calls.

I have no information about Windows internals except for some
public statements by Microsoft and other people, but I think
it reasonable to assume that Windows was actually a succesful
example of 8086/286/386 compatibility.  That is their 16 bit
code could use real mode segmentation or protected mode
segmentation the later both for 286 and 386.  For 32-bit
version they added translation layer to transform arguments
between 16-bit world and 32-bit world.  It is possible
that this translation layer involved a lot of effort.  IIUC
DEC when porting VMS to Alpha essentially gave up using
32-bit pointers as main interface.

Anyway, it seems that Windows was at least as tied to 286
as OS/2 when it became sucessful and dropped 286 support
later.  And for long time after dropping 286 support
Windows massively used 16-bit segments.

Also, Microsoft started NT OS/2 in November 1988 to target the 386
while IBM was still working on 286 OS/2.  Eventually Microsoft and IBM
parted ways, NT OS/2 became Windows NT, which is the starting point of
all remaining Windowses from Windows XP onwards.
 
Xenix, apart from OS/2 the only other notable protected-mode OS for
the 286, was ported to the 386 in 1987, after SCO secured "knowledge
from Microsoft insiders that Microsoft was no longer developing
Xenix", so SCO (or Microsoft) might have done it even earlier if the
commercial situation had been less muddled; in any case, Xenix jumped
the 286 ship ASAP.
 
The verdict is: The only good use of the 286 is as a faster 8086;
small memory model multi-tasking use is possible, but the 64KB
segments are so limiting that everybody who understood software either
decided to skip this twist (MicroSoft, except on their OS/2 death
march), or jumped ship ASAP (SCO).

As I mentioned above I do not believe your claim about Microsoft.
There were DOS-extenders which allowed use of 286 protected mode
under DOS.  They were used by several software vendors.  Clearly,
programming for flat 32-bit mode is easier and on software market
that matters more than other factors.

I think that 286 protected mode is good for its intended use, that
is protected multitasking systems having more than 64 kB but less
than say 4 MB.  Of course, if you have a lot of hardware resources,
than 32-bit system using paging may be easier to create.  Also,
speed is tricky: on 486 (and possibly 386) hardware task switch
was easy to use, but slower than tuned purely software
implementation.  In other parts reloading of segment registers
could slow down things quite a lot, so 16-bit protected mode
required a lot of tuning to minimize number of times when
segement registers were reloaded.

I do not know if people used 286 in this way, but natural use
of 286 is as a debugger for 8086 programs.  That is use segment
protection to catch stray accesses.  Once program works OK
deliver it as a real mode program on 8086 gaining speed and
bigger market.

AFAIK Linux started using 32-bit mode but heavily depending on
386 segmentation.  Rater quickly dependence on segments was
limited and what remained was well isolated.  But I think that
Linux shows that _creating_ simple multitasking system is
easier using hardware properties coming together with 286
segmentation.

Intel misjudged what is typical in programs.  But they were not
alone in this.  I have translation of Tanenbaum book on computer
architecture from 1976 (original, translation is from 1983).
Tanenbaum is very posivite about segmentation, descriptors and
"high level machines".  He gave simple examples where descriptors
and microprogrammed "high level machine" are supposed to give
better performance than more conventianal machine.

And as I already wrote, Intel misjudged market for 286.  They
could guess that 286 system will be too expensive for home
market for long time.  They probably did not expect that
286 will find its way into PC-s.

More generally, vendors could release separate versions of
programs for 8086 and 286 but few did so.

 
Were there any who released software both as 8086 and a protected-mode
80286 variants?  Microsoft/SCO with Xenix, anyone else?

IIUC Microsoft Windows up to 3.0 and probably everbody who wanted
to say "supported on Windows".  That is Windows 3.0 on 286 almost
surely used 286 protected mode and probably run "Windows" programs
in protected mode.  But Windows also supported 8086 and Microsoft
guidelines insisted that proper "Windows program" should run on
8086.

On DOS I do not remember names of specific programs.  I remember
Phar Lap who provided 286 DOS extender and quite a few programs
used it.  Browsing trough binaries on machines that I used I saw
the name several times.  Sometimes program using DOS extender
would clearly say that it requires 286, but I vaguely remember
cases with separate 286 binaries and 8086 binaries where startup
code loaded right binary.  Probably there were also cases whare
needed switching was hidden inside a single binary.

And users having
only binaries wanted to use 8086 on their new systems which
led to heroic efforts like OS/2 DOS box and later Linux
dosemu.  But integration of 8086 programs with protected
mode was solved too late for 286 model to gain traction
(and on 286 "DOS box" had to run in real mode, breaking
normal system protection).

 
Linux never ran on a 80286, and DOSemu uses the virtual 8086 mode,
which does not require heroic efforts AFAIK.

Well, baside virtual 8086 mode there is tricky code to get
right effect.  A lot of late "DOS" programs dependend on DOS
extenders and significant fraction of such programs run fine
under dosemu.  I do not know if Windows ever got its DOS box
to level of dosemu, but when I used dosemu I heard that
various things did not work in Windows DOS box.

There was various segmented hardware around, first and foremost (for
the designers of the 80286), the iAPX432.  And as you write, all the
good reasons that resulted in segments on the iAPX432 also persisted
in the 80286.  However, given the slowness of segmentation, only the
tiny (all in one segment), small (one segment for code and one for
data), and maybe medium memory models (one data segment) are
competetive in protected mode compared to real mode.

>
AFAICS that covered wast majority of programs during eighties.

 
The "vast majority" is not enough; if a key application like Lotus
1-2-3 or Wordperfect did not work on the DOS alternative, the DOS
alternative was not used.  And Lotus 1-2-3 and Wordperfect certainly
did not limit themselves to 64KB of data.

I do not know if they offered protected mode versions.  But it
is likely that they did once machines with more than 640 kB
formed resonable fraction of the PC market.

Turbo Pascal offered only medium memory model

 
Acoording to Terje Mathiesen, it also offered the large memory model.
On its Wikipedia page, I find: "Besides allowing applications larger
than 64 KB, Byte in 1988 reported ... for version 4.0".  So apparently
Turbo Pascal 4.0 introduced support for the large memory model in
1988.

I am not entirely sure, but probaly I used 4.0.  I certainly used
5.0 and later versions.  AFAIR all versions that I used limited
"static" data to 64 kB, that together with no such limit for code
I take as definition of "medium" model.  I do not remeber explicit
model switches which were common on PC C compilers.  PC compilers
allowed far/near qualifiers on pointers and I do not rememeber
significant restrictions on this (but other folks reported that
some combinations did not work): for data model set defaults,
but programmer could override it.  So in Turbo Pascal one could
use large pointers if desired (or maybe even by default), but
static data was in a single 64 kB segment.

Intel apparently assumed that programmers are willing to spend
extra work to get good performance and IMO this was right
as a general statement.  Intel probably did not realize that
programmers will be very reluctant to spent work on security
features and in particular to spent work on making programs
fast in 286 protected mode.

 
80286 protected mode is never faster than real mode on the same CPU,
so the way to make programs fast on the 286 is to stick with real
mode; using the small memory model is an alternative, but as
mentioned, the memory limits are too restrictive.

Well, if program needs more than 1 MB total workarounds on 286
may be more expensive than cost of protected mode.  More to
the point, if one needs security features, then doing them
in real mode via sofware is likely to take more time than 286
version.  Intel clearly did not anticipate that large fraction
of 286-s will be used in PC-s and that in PC vendors/developers
will prefer speed gain (modest when protected mode version
has enough tuning) to protection.

Intel probably assumend that 286 would cover most needs,

 
As far as protected mode was concerned, they hardly could have been
more wrong.
 

especially
given that most system had much less memory than 16 MB theoreticlly
allowed by 286.

 
They provided 24 address pins, so they obviously assumed that there
would be 80286 systems with >8MB.  64KB segments are already too
limiting on systems with 1MB (which was supported by the 8086),
probably even for anything beyond 128KB.
 

IMO this is partially true: there
is a class of programs which with some work fit into medium
model, but using flat address space is easier.  I think that
on 286 (that is with 16 bit bus) those programs (assuming enough
tuning) run faster than flat 32-bit version.

 
Maybe in real mode.  Certainly not in protected mode.  Just run your
tuned large-model protected-mode program against a 32-bit small-model
program for the same task on a 386SX (which is reported as having a
very similar speed to the 80286 on 16-bit programs).

My instruction table show _longer_ times for several intructions
on 386 compared to 286.  For example real mode far call on 286
has 13 clocks + penalty, on 386 17 clocks + the same penalty,
protected mode call on 286 has 26 clocks + penalty, on 386 has
34 clocks + penalty.  Near call on both is 7 clocks + penalty.

Anyway, if program consists of several procedures (or clusters
of closely related procedures) each having few kilobytes then
it can easily happen that there are thousends of instructions
between far calls, so cost of far calls is going to be
negligible (19 clocks per thousends of instructions).  If
program manages to do its work in single 64 kB data (not
unreasonable for 1 MB code), than it will be faster than
program using 32-bit addresses.  More relevant, in multitaking
situation with each task having its own data segment there
will be reloading of segment registers on task switch,
which is likely to be negligible.  Again, each task will
gain due to smaller pointers.  With OS present there will
be segment reloading due to system calls and this may
be more significant.  However, this mostly due to protection
and not segmentation.

And even if you
find one case where the protected-mode program wins, nobody found it
worth their time to do this nonsense.

That is largely true.  I wonder what will happen with x32 mode
on x86_64.  AFAIK x32 mode showed measurable performance gains,
20-30% smaller programs and similar speed gains.  In principle
it should be cheap to support it as it is "just another 32-bit
target".  But some (for me important) programs do not work
in this mode and there are voices to completly drop it.

And so OS/2 flopped despite
being backed by IBM and, until 1990, Microsoft.
 

But I think that Intel segmentation had some
attractive features during eighties.

 
You are one of a tiny minority.  Even Intel finally saw the light, as
did everybody else, and nowadays segments are just a bad memory.

Well, 16-bit segments clearly are too limited when one has several
megabytes of memory.  And consistently 32-bit segmented system
increases memory use which is nontrivial cost.  OTOH there is
question how much customers are going to pay for security
features.  I think recent times show that secuity has significant
costs.  But lack of security may lead to big losses.  So
there is no easy choice.

Now people talk more about capabilities.  AFAICS capabilities
offer more than segments, but are going to have higher cost.
So abstractly, for some systems segments still may look
attractive.  OTOH we now understand that software ecosystem
is much more varied than prevalent view in seventies, so
system that fit well to segments are a tiny part.

And considering bad memory, do you remember PAE?  That had
similar spirit to 8086 segmentation.  I guess that due
to bad feeling for segments among programmers (and possibly
more relevant compatiblity troubles) Intel did not extend
this to segments, but spirit was still there.

--
                              Waldek Hebisch