Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28798 > unrolled thread

intel 386 et al

Back to article view | Back to comp.arch.embedded

Contents

  intel 386 et al Hul Tytus <ht@panix.com> - 2019-09-11 21:06 +0000
    Re: intel 386 et al Paul Rubin <no.email@nospam.invalid> - 2019-09-11 14:27 -0700
      Re: intel 386 et al David Brown <david.brown@hesbynett.no> - 2019-09-12 10:37 +0200
        Re: intel 386 et al "Mat Nieuwenhoven" <mnieuw@zap.a2000.nl> - 2019-09-13 11:37 +0200
          Re: intel 386 et al David Brown <david.brown@hesbynett.no> - 2019-09-13 12:31 +0200
        Re: intel 386 et al George Neuner <gneuner2@comcast.net> - 2019-09-16 14:57 -0400
          Re: intel 386 et al Robert Wessel <robertwessel2@yahoo.com> - 2019-09-17 01:01 -0500
            Re: intel 386 et al upsidedown@downunder.com - 2019-09-17 09:40 +0300
            Re: intel 386 et al George Neuner <gneuner2@comcast.net> - 2019-09-17 17:51 -0400
              Re: intel 386 et al Robert Wessel <robertwessel2@yahoo.com> - 2019-09-17 21:43 -0500
      Re: intel 386 et al Hul Tytus <ht@panix.com> - 2019-09-12 20:28 +0000
    Re: intel 386 et al Herbert Kleebauer <klee@unibwm.de> - 2019-09-12 09:14 +0200
    Re: intel 386 et al Stefan Reuther <stefan.news@arcor.de> - 2019-09-12 18:42 +0200
      Re: intel 386 et al Hul Tytus <ht@panix.com> - 2019-09-12 20:33 +0000

#28798 — intel 386 et al

	Anyone know of a good handbook describing the machine code of Intel's 
386's? A page describing each instruction along with some text about the 
various sequences caused by interupts and descriptions of the various tables 
and "descriptors" and special purpose registers and the effects of "protected 
mode" is the hope. An older text that didn't describe the 64 bit versions 
would be ok, maybe preferable.
	Hummel's book I've seen, but it's more of a lengthy volume than a 
handbook. Any others that aren't so windy?

Hul

[toc] | [next] | [standalone]

#28799

Hul Tytus <ht@panix.com> writes:
> 	Anyone know of a good handbook describing the machine code of Intel's 
> 386's? A page describing each instruction along with some text about

I don't know if it's exactly the format you wanted, but I liked
"Programming the 80386" by John Crawford and Patrick Gelsinger, who were
involved with the 386's design.  It did a good job of explaining how
memory mapping, the protected mode segment registers, call gates for
crossing privilege domains etc. all worked.  I still don't understand
why today's OS's don't use those features.  They would also allow
application programs to be set up like miniature OS's with protected
memory regions, for things like in-memory databases.

[toc] | [prev] | [next] | [standalone]

#28801

On 11/09/2019 23:27, Paul Rubin wrote:
> Hul Tytus <ht@panix.com> writes:
>> 	Anyone know of a good handbook describing the machine code of Intel's 
>> 386's? A page describing each instruction along with some text about

I presume this is for some sort of history project?

> 
> I don't know if it's exactly the format you wanted, but I liked
> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
> involved with the 386's design.  It did a good job of explaining how
> memory mapping, the protected mode segment registers, call gates for
> crossing privilege domains etc. all worked.  I still don't understand
> why today's OS's don't use those features.  They would also allow
> application programs to be set up like miniature OS's with protected
> memory regions, for things like in-memory databases.
> 

It is a /long/ time since I have read details of the 386 - you are
talking about a processor that was outdated over 25 years ago.

However, if my memory and understanding is correct, many of these
advanced protection features were overly complex and extremely slow.

In the days of the 386, there were four main classes of operating
systems for it.  One was DOS - still popular.  Since MS at the time had
close to zero concern for security or reliability, it used very little
of the protection features, or memory mapping abilities.  It did not
even use 32-bit modes very much (32-bit DOS extenders were made by third
parties).  Then there was early Windows.  Again, security and protection
were not a concern for MS, though they used a couple of features to get
multi-tasking of DOS programs.  Then there was *nix type systems.  These
simply did not need the call gates and other bits and pieces for
security - all they need are a distinction between user mode and kernel
mode, and a way to switch between them.  And they didn't need any
"virtual" modes or other complications that the 386 provided to let you
use old binaries on newer protected systems - you just compiled your
*nix code anew for the new system.

The complexities of the call gates and other features of the 386 were
concepts from a bygone era by the time the 386 came out, and were never
of use in the kind of systems used by the 386.  And they have no use now
either - modern protection rings and hardware virtualisation are
massively more efficient, as well as being simpler and more flexible.

[toc] | [prev] | [next] | [standalone]

#28806

On Thu, 12 Sep 2019 10:37:40 +0200, David Brown wrote:

>On 11/09/2019 23:27, Paul Rubin wrote:
>> Hul Tytus <ht@panix.com> writes:
>>> 	Anyone know of a good handbook describing the machine code of Intel's 
>>> 386's? A page describing each instruction along with some text about
>
>I presume this is for some sort of history project?
>
>> 
>> I don't know if it's exactly the format you wanted, but I liked
>> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
>> involved with the 386's design.  It did a good job of explaining how
>> memory mapping, the protected mode segment registers, call gates for
>> crossing privilege domains etc. all worked.  I still don't understand
>> why today's OS's don't use those features.  They would also allow
>> application programs to be set up like miniature OS's with protected
>> memory regions, for things like in-memory databases.
>> 
>
>It is a /long/ time since I have read details of the 386 - you are
>talking about a processor that was outdated over 25 years ago.
>
>However, if my memory and understanding is correct, many of these
>advanced protection features were overly complex and extremely slow.
>
>In the days of the 386, there were four main classes of operating
>systems for it.  One was DOS - still popular.  Since MS at the time had
>close to zero concern for security or reliability, it used very little
>of the protection features, or memory mapping abilities.  It did not
>even use 32-bit modes very much (32-bit DOS extenders were made by third
>parties).  Then there was early Windows.  Again, security and protection
>were not a concern for MS, though they used a couple of features to get
>multi-tasking of DOS programs.  Then there was *nix type systems.  These
>simply did not need the call gates and other bits and pieces for
>security - all they need are a distinction between user mode and kernel
>mode, and a way to switch between them.  And they didn't need any
>"virtual" modes or other complications that the 386 provided to let you
>use old binaries on newer protected systems - you just compiled your
>*nix code anew for the new system.

>The complexities of the call gates and other features of the 386 were
>concepts from a bygone era by the time the 386 came out, and were never
>of use in the kind of systems used by the 386.  And they have no use now
>either - modern protection rings and hardware virtualisation are
>massively more efficient, as well as being simpler and more flexible.

32 bit OS/2 (and descendants like eCs or ArcaOS) definitely use the
call gates. This caused problems with some virtual machines which did
not expect that.
I don't know anything about the speed differences between call gates
and more modern mechanisms.
I don't think there were many compilers that supported segments in 32
bit mode (maybe Watcom), so 32 bit is always flat mode. Segments gave
you some protection too.

Mat Nieuwenhoven

[toc] | [prev] | [next] | [standalone]

#28807

On 13/09/2019 11:37, Mat Nieuwenhoven wrote:
> On Thu, 12 Sep 2019 10:37:40 +0200, David Brown wrote:
> 
>> On 11/09/2019 23:27, Paul Rubin wrote:
>>> Hul Tytus <ht@panix.com> writes:
>>>> 	Anyone know of a good handbook describing the machine code of Intel's 
>>>> 386's? A page describing each instruction along with some text about
>>
>> I presume this is for some sort of history project?
>>
>>>
>>> I don't know if it's exactly the format you wanted, but I liked
>>> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
>>> involved with the 386's design.  It did a good job of explaining how
>>> memory mapping, the protected mode segment registers, call gates for
>>> crossing privilege domains etc. all worked.  I still don't understand
>>> why today's OS's don't use those features.  They would also allow
>>> application programs to be set up like miniature OS's with protected
>>> memory regions, for things like in-memory databases.
>>>
>>
>> It is a /long/ time since I have read details of the 386 - you are
>> talking about a processor that was outdated over 25 years ago.
>>
>> However, if my memory and understanding is correct, many of these
>> advanced protection features were overly complex and extremely slow.
>>
>> In the days of the 386, there were four main classes of operating
>> systems for it.  One was DOS - still popular.  Since MS at the time had
>> close to zero concern for security or reliability, it used very little
>> of the protection features, or memory mapping abilities.  It did not
>> even use 32-bit modes very much (32-bit DOS extenders were made by third
>> parties).  Then there was early Windows.  Again, security and protection
>> were not a concern for MS, though they used a couple of features to get
>> multi-tasking of DOS programs.  Then there was *nix type systems.  These
>> simply did not need the call gates and other bits and pieces for
>> security - all they need are a distinction between user mode and kernel
>> mode, and a way to switch between them.  And they didn't need any
>> "virtual" modes or other complications that the 386 provided to let you
>> use old binaries on newer protected systems - you just compiled your
>> *nix code anew for the new system.
> 
>> The complexities of the call gates and other features of the 386 were
>> concepts from a bygone era by the time the 386 came out, and were never
>> of use in the kind of systems used by the 386.  And they have no use now
>> either - modern protection rings and hardware virtualisation are
>> massively more efficient, as well as being simpler and more flexible.
> 
> 32 bit OS/2 (and descendants like eCs or ArcaOS) definitely use the
> call gates. This caused problems with some virtual machines which did
> not expect that.

OS/2 was written by IBM (at least, those low-level bits were done by
IBM.  Some of the other bits were done by MS).  The IBM's came from a
background with bigger systems - mainframes - and liked this kind of
powerful hardware feature.  So it doesn't surprise me that they used it.

> I don't know anything about the speed differences between call gates
> and more modern mechanisms.
> I don't think there were many compilers that supported segments in 32
> bit mode (maybe Watcom), so 32 bit is always flat mode. Segments gave
> you some protection too.
> 

I think that is correct, in the days of the 386 at least.  But I don't
know details there.  My PC programming at that time was targetting
16-bit Windows or DOS (although I used OS/2 as the OS).

[toc] | [prev] | [next] | [standalone]

#28816

On Thu, 12 Sep 2019 10:37:40 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 11/09/2019 23:27, Paul Rubin wrote:
>> Hul Tytus <ht@panix.com> writes:
>>> 	Anyone know of a good handbook describing the machine code of Intel's 
>>> 386's? A page describing each instruction along with some text about
>
>I presume this is for some sort of history project?
> 
>> I don't know if it's exactly the format you wanted, but I liked
>> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
>> involved with the 386's design.  It did a good job of explaining how
>> memory mapping, the protected mode segment registers, call gates for
>> crossing privilege domains etc. all worked.  I still don't understand
>> why today's OS's don't use those features.  They would also allow
>> application programs to be set up like miniature OS's with protected
>> memory regions, for things like in-memory databases.
>> 
>
>It is a /long/ time since I have read details of the 386 - you are
>talking about a processor that was outdated over 25 years ago.
>
>However, if my memory and understanding is correct, many of these
>advanced protection features were overly complex and extremely slow.

That's true ... validating segment descriptors and segment limits when
loading the segment selector took > 1000 cycles.  This was so onerous
that the i486 and later included a small cache of validated
descriptors.  But the cache never was large enough to help programs
that needed to use many segments - IIRC, it held only 6 entries - and
as time went on it shrank to just 2 entries.

Another problem with segments was there were too few of them
available: 8K local (per process) segments is not really enough for
fine grain object protection, and 8K global segments is not a whole
lot when you consider all the uses the operating system might have.

But the biggest problem was that the segment selector was a visible
component of addressing.  This may have been acceptible on the 8086,
but segments there were purely for addressing and had no protection
dimension.  It became a debate issue starting with the i286, but that
chip had so many other issues that segment visibility was lost in the
noise.

When it was announced that the 80386 would include transparent paging,
many people hoped that its segmentation behavior would be rethought.
Segment advocates hoped that the conflation of segment selection with
addressing would be abandoned, that segments would become protection
domains only, that segments would be able to be defined and used more
dynamically, and that using them would be made much faster.

[I'm not taking any positions on this, I'm just recalling things I saw
in media and in Usenet discussions at the time.]


>In the days of the 386, there were four main classes of operating
>systems for it.  One was DOS - still popular.  Since MS at the time had
>close to zero concern for security or reliability, it used very little
>of the protection features, or memory mapping abilities.  It did not
>even use 32-bit modes very much (32-bit DOS extenders were made by third
>parties).  Then there was early Windows.  Again, security and protection
>were not a concern for MS, though they used a couple of features to get
>multi-tasking of DOS programs.  Then there was *nix type systems.  These
>simply did not need the call gates and other bits and pieces for
>security - all they need are a distinction between user mode and kernel
>mode, and a way to switch between them.  And they didn't need any
>"virtual" modes or other complications that the 386 provided to let you
>use old binaries on newer protected systems - you just compiled your
>*nix code anew for the new system.
>
>The complexities of the call gates and other features of the 386 were
>concepts from a bygone era by the time the 386 came out, and were never
>of use in the kind of systems used by the 386.  And they have no use now
>either - modern protection rings and hardware virtualisation are
>massively more efficient, as well as being simpler and more flexible.

Agreed, the i286/i386 ring mechanism was complicated to use, but that
was because the protected segment mechanism itself was complicated to
use.  And again, with only 8K global segments, there weren't enough
segments available to protect OS services using call gates unless you
seriously restricted the number of service entry points [there were a
few OSes that did].

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#28821

On Mon, 16 Sep 2019 14:57:38 -0400, George Neuner
<gneuner2@comcast.net> wrote:

>On Thu, 12 Sep 2019 10:37:40 +0200, David Brown
><david.brown@hesbynett.no> wrote:
>
>>On 11/09/2019 23:27, Paul Rubin wrote:
>>> Hul Tytus <ht@panix.com> writes:
>>>> 	Anyone know of a good handbook describing the machine code of Intel's 
>>>> 386's? A page describing each instruction along with some text about
>>
>>I presume this is for some sort of history project?
>> 
>>> I don't know if it's exactly the format you wanted, but I liked
>>> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
>>> involved with the 386's design.  It did a good job of explaining how
>>> memory mapping, the protected mode segment registers, call gates for
>>> crossing privilege domains etc. all worked.  I still don't understand
>>> why today's OS's don't use those features.  They would also allow
>>> application programs to be set up like miniature OS's with protected
>>> memory regions, for things like in-memory databases.
>>> 
>>
>>It is a /long/ time since I have read details of the 386 - you are
>>talking about a processor that was outdated over 25 years ago.
>>
>>However, if my memory and understanding is correct, many of these
>>advanced protection features were overly complex and extremely slow.
>
>That's true ... validating segment descriptors and segment limits when
>loading the segment selector took > 1000 cycles.  This was so onerous
>that the i486 and later included a small cache of validated
>descriptors.  But the cache never was large enough to help programs
>that needed to use many segments - IIRC, it held only 6 entries - and
>as time went on it shrank to just 2 entries.


Descriptor loading was slow, but I'm pretty sure it wasn't *that*
slow.  It's hard to imagine what it could be doing for that long.  I
remember times more like 40 clocks on a 286.

[toc] | [prev] | [next] | [standalone]

#28822

On Tue, 17 Sep 2019 01:01:22 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Mon, 16 Sep 2019 14:57:38 -0400, George Neuner
><gneuner2@comcast.net> wrote:
>
>>On Thu, 12 Sep 2019 10:37:40 +0200, David Brown
>><david.brown@hesbynett.no> wrote:
>>
>>>On 11/09/2019 23:27, Paul Rubin wrote:
>>>> Hul Tytus <ht@panix.com> writes:
>>>>> 	Anyone know of a good handbook describing the machine code of Intel's 
>>>>> 386's? A page describing each instruction along with some text about
>>>
>>>I presume this is for some sort of history project?
>>> 
>>>> I don't know if it's exactly the format you wanted, but I liked
>>>> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
>>>> involved with the 386's design.  It did a good job of explaining how
>>>> memory mapping, the protected mode segment registers, call gates for
>>>> crossing privilege domains etc. all worked.  I still don't understand
>>>> why today's OS's don't use those features.  They would also allow
>>>> application programs to be set up like miniature OS's with protected
>>>> memory regions, for things like in-memory databases.
>>>> 
>>>
>>>It is a /long/ time since I have read details of the 386 - you are
>>>talking about a processor that was outdated over 25 years ago.
>>>
>>>However, if my memory and understanding is correct, many of these
>>>advanced protection features were overly complex and extremely slow.
>>
>>That's true ... validating segment descriptors and segment limits when
>>loading the segment selector took > 1000 cycles.  

Sounds more about iAPX432, in which some instructions were real slow.

>This was so onerous
>>that the i486 and later included a small cache of validated
>>descriptors.  But the cache never was large enough to help programs
>>that needed to use many segments - IIRC, it held only 6 entries - and
>>as time went on it shrank to just 2 entries.
>
>
>Descriptor loading was slow, but I'm pretty sure it wasn't *that*
>slow.  It's hard to imagine what it could be doing for that long.  I
>remember times more like 40 clocks on a 286.

[toc] | [prev] | [next] | [standalone]

#28826

On Tue, 17 Sep 2019 01:01:22 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Mon, 16 Sep 2019 14:57:38 -0400, George Neuner
><gneuner2@comcast.net> wrote:
>
>>On Thu, 12 Sep 2019 10:37:40 +0200, David Brown
>><david.brown@hesbynett.no> wrote:
>>
>>>On 11/09/2019 23:27, Paul Rubin wrote:
>>>> Hul Tytus <ht@panix.com> writes:
>>>>> 	Anyone know of a good handbook describing the machine code of Intel's 
>>>>> 386's? A page describing each instruction along with some text about
>>>
>>>I presume this is for some sort of history project?
>>> 
>>>> I don't know if it's exactly the format you wanted, but I liked
>>>> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
>>>> involved with the 386's design.  It did a good job of explaining how
>>>> memory mapping, the protected mode segment registers, call gates for
>>>> crossing privilege domains etc. all worked.  I still don't understand
>>>> why today's OS's don't use those features.  They would also allow
>>>> application programs to be set up like miniature OS's with protected
>>>> memory regions, for things like in-memory databases.
>>>> 
>>>
>>>It is a /long/ time since I have read details of the 386 - you are
>>>talking about a processor that was outdated over 25 years ago.
>>>
>>>However, if my memory and understanding is correct, many of these
>>>advanced protection features were overly complex and extremely slow.
>>
>>That's true ... validating segment descriptors and segment limits when
>>loading the segment selector took > 1000 cycles.  This was so onerous
>>that the i486 and later included a small cache of validated
>>descriptors.  But the cache never was large enough to help programs
>>that needed to use many segments - IIRC, it held only 6 entries - and
>>as time went on it shrank to just 2 entries.
>
>
>Descriptor loading was slow, but I'm pretty sure it wasn't *that*
>slow.  It's hard to imagine what it could be doing for that long.  I
>remember times more like 40 clocks on a 286.

Protected mode segment switching on the i286 was fairly quick, but the
i386 (and later) behaved very differently.


Loading a segment register in protected mode could result in a long
sequence if the descriptor was not already in the descriptor cache:

   - read the descriptor from memory into the cache
   - validate the descriptor contents
And on the i386 and later
   - set the "Accessed" bit in the descriptor
   - write back the modified descriptor to memory

The i386 additionally performed an unnecessary limit check on the
current offset value, but did not throw any faults when the check was
done as part of the descriptor load - it just wasted additional
cycles.

Validating the descriptor was done in microcode and could take
hundreds of cycles.  The i286 did not define or check many of the
descriptor's control bits, whereas the i386 and later defined and
checked all the bits.

The i286 did /not/ modify and write back the descriptor - the
"Accessed" bit was defined for the i286 but was not set by the
hardware [if the OS used it, it had to deal with it manually].
The i386 and later automatically set the bit on load and wrote back
the descriptor to memory.  [The i486 and later had data caches to
absorb the write, but the i386 did not.]

The i286 and i386 had only one descriptor cache line per segment
register, so they took the full descriptor load hit every time the
register was modified. The caches became multi-way in later chips so
as to (try to) keep already-validated descriptors available in case
they were needed again.


I know that the slowness of protected mode segment switching has been
discussed at length in the past - if not here, then in the arch or x86
forums.  Unfortunately I can't easily locate an online reference for
segment switch times.  I figured Agner Fog would have something, but
he doesn't seem to have benchmarked the system instructions.  [Or if
he has, I stupidly can't seem to find his results].


George

[toc] | [prev] | [next] | [standalone]

#28829

On Tue, 17 Sep 2019 17:51:01 -0400, George Neuner
<gneuner2@comcast.net> wrote:

>On Tue, 17 Sep 2019 01:01:22 -0500, Robert Wessel
><robertwessel2@yahoo.com> wrote:
>
>>On Mon, 16 Sep 2019 14:57:38 -0400, George Neuner
>><gneuner2@comcast.net> wrote:
>>
>>>On Thu, 12 Sep 2019 10:37:40 +0200, David Brown
>>><david.brown@hesbynett.no> wrote:
>>>
>>>>On 11/09/2019 23:27, Paul Rubin wrote:
>>>>> Hul Tytus <ht@panix.com> writes:
>>>>>> 	Anyone know of a good handbook describing the machine code of Intel's 
>>>>>> 386's? A page describing each instruction along with some text about
>>>>
>>>>I presume this is for some sort of history project?
>>>> 
>>>>> I don't know if it's exactly the format you wanted, but I liked
>>>>> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
>>>>> involved with the 386's design.  It did a good job of explaining how
>>>>> memory mapping, the protected mode segment registers, call gates for
>>>>> crossing privilege domains etc. all worked.  I still don't understand
>>>>> why today's OS's don't use those features.  They would also allow
>>>>> application programs to be set up like miniature OS's with protected
>>>>> memory regions, for things like in-memory databases.
>>>>> 
>>>>
>>>>It is a /long/ time since I have read details of the 386 - you are
>>>>talking about a processor that was outdated over 25 years ago.
>>>>
>>>>However, if my memory and understanding is correct, many of these
>>>>advanced protection features were overly complex and extremely slow.
>>>
>>>That's true ... validating segment descriptors and segment limits when
>>>loading the segment selector took > 1000 cycles.  This was so onerous
>>>that the i486 and later included a small cache of validated
>>>descriptors.  But the cache never was large enough to help programs
>>>that needed to use many segments - IIRC, it held only 6 entries - and
>>>as time went on it shrank to just 2 entries.
>>
>>
>>Descriptor loading was slow, but I'm pretty sure it wasn't *that*
>>slow.  It's hard to imagine what it could be doing for that long.  I
>>remember times more like 40 clocks on a 286.
>
>Protected mode segment switching on the i286 was fairly quick, but the
>i386 (and later) behaved very differently.
>
>
>Loading a segment register in protected mode could result in a long
>sequence if the descriptor was not already in the descriptor cache:
>
>   - read the descriptor from memory into the cache
>   - validate the descriptor contents
>And on the i386 and later
>   - set the "Accessed" bit in the descriptor
>   - write back the modified descriptor to memory
>
>The i386 additionally performed an unnecessary limit check on the
>current offset value, but did not throw any faults when the check was
>done as part of the descriptor load - it just wasted additional
>cycles.
>
>Validating the descriptor was done in microcode and could take
>hundreds of cycles.  The i286 did not define or check many of the
>descriptor's control bits, whereas the i386 and later defined and
>checked all the bits.
>
>The i286 did /not/ modify and write back the descriptor - the
>"Accessed" bit was defined for the i286 but was not set by the
>hardware [if the OS used it, it had to deal with it manually].
>The i386 and later automatically set the bit on load and wrote back
>the descriptor to memory.  [The i486 and later had data caches to
>absorb the write, but the i386 did not.]
>
>The i286 and i386 had only one descriptor cache line per segment
>register, so they took the full descriptor load hit every time the
>register was modified. The caches became multi-way in later chips so
>as to (try to) keep already-validated descriptors available in case
>they were needed again.
>
>
>I know that the slowness of protected mode segment switching has been
>discussed at length in the past - if not here, then in the arch or x86
>forums.  Unfortunately I can't easily locate an online reference for
>segment switch times.  I figured Agner Fog would have something, but
>he doesn't seem to have benchmarked the system instructions.  [Or if
>he has, I stupidly can't seem to find his results].


The Intel 386 reference (copy available on Bitsavers) say 18 or 19
clocks for a MOV to a segment register.  As usual, that would be quite
optimistic and base on zero memory wait states, so would be rather
longer than that.

The Intel 486 manual says 9 clocks.

Perhaps you're thinking of a task switch via a task gate, which could
definitely be multiple hundreds of clocks.

[toc] | [prev] | [next] | [standalone]

#28804

Thanks Paul, I take a look at it.

Hul


Paul Rubin <no.email@nospam.invalid> wrote:
> Hul Tytus <ht@panix.com> writes:
> >       Anyone know of a good handbook describing the machine code of Intel's 
> > 386's? A page describing each instruction along with some text about

> I don't know if it's exactly the format you wanted, but I liked
> "Programming the 80386" by John Crawford and Patrick Gelsinger, who were
> involved with the 386's design.  It did a good job of explaining how
> memory mapping, the protected mode segment registers, call gates for
> crossing privilege domains etc. all worked.  I still don't understand
> why today's OS's don't use those features.  They would also allow
> application programs to be set up like miniature OS's with protected
> memory regions, for things like in-memory databases.

[toc] | [prev] | [next] | [standalone]

#28800

On 11.09.2019 23:06, Hul Tytus wrote:
> 	Anyone know of a good handbook describing the machine code of Intel's
> 386's? A page describing each instruction along with some text about the
> various sequences caused by interupts and descriptions of the various tables
> and "descriptors" and special purpose registers and the effects of "protected
> mode" is the hope. An older text that didn't describe the 64 bit versions
> would be ok, maybe preferable.
> 	Hummel's book I've seen, but it's more of a lengthy volume than a
> handbook. Any others that aren't so windy?
>

https://software.intel.com/en-us/articles/intel-sdm

[toc] | [prev] | [next] | [standalone]

#28803

Am 11.09.2019 um 23:06 schrieb Hul Tytus:
> 	Anyone know of a good handbook describing the machine code of Intel's 
> 386's? A page describing each instruction along with some text about the 
> various sequences caused by interupts and descriptions of the various tables 
> and "descriptors" and special purpose registers and the effects of "protected 
> mode" is the hope. An older text that didn't describe the 64 bit versions 
> would be ok, maybe preferable.

If you're really looking for just the 386 and not the gazillions of
extensions to the Intel 32-bit architecture: in the 90's, we were
passing around a file called "386intel.txt", titled "INTEL 80386
PROGRAMMER'S REFERENCE MANUAL 1986", which explains pretty much
everything about the 386.

A short search turns up this link for a copy:
http://cd.textfiles.com/freedom/CODE/TEXT/386INTEL.ZIP

Set your text encoding to cp437, like in the old days.


  Stefan

[toc] | [prev] | [next] | [standalone]

#28805

Thanks Stefan, that should be easy to look at.

Hul

Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 11.09.2019 um 23:06 schrieb Hul Tytus:
> >       Anyone know of a good handbook describing the machine code of Intel's 
> > 386's? A page describing each instruction along with some text about the 
> > various sequences caused by interupts and descriptions of the various tables 
> > and "descriptors" and special purpose registers and the effects of "protected 
> > mode" is the hope. An older text that didn't describe the 64 bit versions 
> > would be ok, maybe preferable.

> If you're really looking for just the 386 and not the gazillions of
> extensions to the Intel 32-bit architecture: in the 90's, we were
> passing around a file called "386intel.txt", titled "INTEL 80386
> PROGRAMMER'S REFERENCE MANUAL 1986", which explains pretty much
> everything about the 386.

> A short search turns up this link for a copy:
> http://cd.textfiles.com/freedom/CODE/TEXT/386INTEL.ZIP

> Set your text encoding to cp437, like in the old days.


>   Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web