Path: ...!news.nobody.at!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: antispam@fricas.org (Waldek Hebisch)
Newsgroups: comp.arch
Subject: Re: 80286 protected mode
Date: Sun, 5 Jan 2025 21:49:20 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vleuou$rv85$1@paganini.bofh.team>
References: <uigus7$1pteb$1@dont-email.me>   <vdkolv$3ed1r$3@dont-email.me> <vdlgl9$3kq50$2@dont-email.me> <2024Oct3.113903@mips.complang.tuwien.ac.at> <vdn55j$3ssv4$11@dont-email.me> <vdoc76$5cna$2@dont-email.me> <2024Oct4.193007@mips.complang.tuwien.ac.at> <vdtmv9$16lu8$1@dont-email.me> <2024Oct6.150415@mips.complang.tuwien.ac.at> <vl7m2b$6iat$1@paganini.bofh.team> <2025Jan3.093849@mips.complang.tuwien.ac.at> <vlcddh$j2gr$1@paganini.bofh.team> <2025Jan5.121028@mips.complang.tuwien.ac.at>
Injection-Date: Sun, 5 Jan 2025 21:49:20 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="916741"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 21432
Lines: 405

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
========== REMAINDER OF ARTICLE TRUNCATED ==========