Re: Byte ordering

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"