Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Byte ordering
Date: Sun, 5 Jan 2025 08:54:29 +0100
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <vlddrm$ubkq$1@dont-email.me>
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>
 <vlcddh$j2gr$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 05 Jan 2025 08:54:30 +0100 (CET)
Injection-Info: dont-email.me; posting-host="cc47f5b1fc276b342bb983d03e3d3fbe";
	logging-data="994970"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+ZTV9h4ZNgEsVtM+aJtctYHWdmz31ktwtMEuiKjwZ32g=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.19
Cancel-Lock: sha1:rQNa8FJieJk5Dx9liIKE5b20/VQ=
In-Reply-To: <vlcddh$j2gr$1@paganini.bofh.team>
Bytes: 3924

Waldek Hebisch wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 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.

As someone who wrote megabytes of that asm, I feel qualified to comment:

Turbo Pascal itself 1.0 ran in Small model (64kB code & data) afair, but 
since the compiler/editor/linker/loader/debugger only used 35 kB (37 kB 
if you also loaded the text error messages), it had enough room left 
over for the source code it compiled.

 From the very beginning it supported Medium as you state, with separate 
code in the CS reg and data+stack (DS+SS) sharing a single segment.

This way you had to use ES for all cross-segment operations, 
particularly REP MOVSB block moves.

Later versions supported the Large model where all addresses were 
segment+offset pairs, as well as Huge where the segment was pointing at 
the object, rounded down to the nearest 16-byte boundary, and the offset 
(typically BX) was always [0-15].
> 
> 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.

Protected could only be fast if segment reloads were rare, in my own 
code I would allocate arrays of largish objects as the max number that 
would fit in 64K, then grab the next.

Terje
PS. Happy New Year!

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"