Path: ...!weretis.net!feeder9.news.weretis.net!3.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: Byte ordering
Date: Sat, 4 Jan 2025 22:40:51 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vlcddh$j2gr$1@paganini.bofh.team>
References: <uigus7$1pteb$1@dont-email.me>   <0194054dac788f7e3a163726e84d72ac@www.novabbs.org> <vdi152$2u3v4$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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 4 Jan 2025 22:40:51 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="625179"; 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: 10970
Lines: 200

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.  But there is a lot of loading segment registers
and slow loading is a problem.
 
>>Concerning code "model", I think that Intel assumend that
>>most procedures would fit in a single segment and that
>>average procedure will be of order of single kilobytes.
>>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.

> That would be faster than
> what you outline, as soon as one call happens.  But apparently 16-bit
> branches are not that beneficial, or they would have gone that way on
> the 386.

For machine with 32-bit bus benefit is much smaller.

> Another usage of segments for code would be to put the code segment of
> a shared object (known as DLL among Windowsheads) in a segment, and
> use far calls to call functions in other shared objects, while using
> near calls within a shared object.  This allows to share the code
> segments between different programs, and to locate them anywhere in
> physical memory.  However, AFAIK shared objects were not a thing in
> the 80286 timeframe; Unix only got them in the late 1980s.

IIUC shared segments were widely used on Multics.

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

>>What went wrong?  IIUC there were several control systems
>>using 286 features, so there was some success.  But PC-s
>>became main user of x86 chips and significant fraction
>>of PC-s was used for gaming.  Game authors wanted direct
>>access to hardware which in case of 286 forced real mode.
> 
> 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.

More generally, vendors could release separate versions of
programs for 8086 and 286 but few did so.  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).

>>But IIUC first paging Unix appeared _after_ release of 286.
> 
> From
> <https://en.wikipedia.org/wiki/History_of_the_Berkeley_Software_Distribution#3BSD>:
> 
> |The kernel of 32V was largely rewritten by Berkeley graduate student
> |Ã?zalp BabaoÄ?lu to include a virtual memory implementation, and a
> |complete operating system including the new kernel, ports of the 2BSD
> |utilities to the VAX, and the utilities from 32V was released as 3BSD
> |at the end of 1979.
> 
> The 80286 was introduced on February 1, 1982.

OK

>>In 286 time Multics was highly regarded and it heavily depended
>>on segmentaion.  MVS was using paging hardware, but was
>>talking about segments, except for that MVS segmentation
>>was flawed because some addresses far outside a segment were
>>considered as part of different segment.  I think that also
>>in VMS there was some taliking about segments.  So creators
>>of 286 could believe that they are providing "right thing"
>>and not a fake possible with paging hardware.
> 
> 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.
Turbo Pascal offered only medium memory model and was quite
popular.  Its code generator produced mediocre output, but
real Turbo Pascal programs used a lot of inline assembly
and performance was not bad.

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.

> So if they really had wanted protected mode to succeed, they should
> have designed in 32-bit data segments (and maybe also 32-bit code
> segments).  Alternatively, if protected mode and the 32-bit addresses
> do not fit in the 286 transistor budget, a CPU that implements the
> 32-bit feature and leaves away protected mode would have been more
> popular than the 80286; and (depending on how the 32-bit extension was
> implemented) it might have been a better stepping stone towards the
> kind of CPU with protected mode that they imagined; but the alt-386
> designers probably would not have designed in this kind of protected
> mode that they did.

Intel probably assumend that 286 would cover most needs, especially
given that most system had much less memory than 16 MB theoreticlly
allowed by 286.  And for bigger systems they released 386.

> Concerning paging, all these scenarios are without paging.  Paging was
> primarily a virtual-memory feature, not a memory-protection feature.

Yes, exactly.

> It acquired memory protection only as far as it was easy with pages
> (i.e., at page granularity).  So paging was not designed as a
> competition to segments as far as protection was concerned.  If
> computer architects had managed to design segmentation with
> competetive performance, we would be seeing hardware with both paging
> and segmentation nowadays.  Or maybe even without paging, now that
> memories tend to be big enough to make virtual memory mostly
> unnecessary.
> 
>>And I do not think thay could make
>>32-bit processor with segmentation in available transistor
>>buget,
> 
> Maybe not.
> 
>>and even it they managed it would be slowed down by too
>>long addresses (segment + 32-bit offset).
> 
> On the contrary, every program that does not fit in the medium memory
> model on the 80286 would run at least as fast on such a CPU in real
> mode and significantly faster in protected mode.

I think that Intel considerd "programs that do it in the medium
memory model" as tiny minority.  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.  But naive compilation
in large (or huge) model leads to worse speed than flat mode.

In a bit different spirit, for programs that do not fit in
64kB, but are not too large there is natural temptation to
have some "compression" scheme for pointers and use mostly
========== REMAINDER OF ARTICLE TRUNCATED ==========