Why was Intel a no-show on No Execute?

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:e4Kwc.39667$bVw1.9931@news01.bloor.is.net.cable.rogers.com...
> Patrick Schaaf <mailer-daemon@bof.de> wrote:
> > The only way I know of which could in theory give a single process
> > more than 32 bits of accessible address space, is the constant making
> > present / nonpresent of segments, with the kernel fault handler for
> > nonpresent segments fiddling with the page directory. However, as you
> > can imagine, that means a user/kernel/user switch whenever a
> > nonpresent segment is used, accompanied by TLB invalidation stuff on
> > page directory reloading.
>
> Which is the method I was actually thinking of. However, as you said it is
a
> slow process. It would be a less slow process if the data and code
segments
> occupied different locations in linear memory, therefore they could share
> the same page table directories without requiring special OS-based
software
> page table switching techniques.

That would have been possible if linear addresses had been expanded to
36-bit along with physical addresses, but they weren't 🙁

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Jerry Peters wrote:

(snip)

> ??? You're confused. That's how Linux works now, each process has its
> own page tables and hence address space. Oh, except Linux doesn't use
> a task gate, since 1) it's slow, & 2) limits you to something like
> 4000 total processes. This still doesn't get you a _single_ AS that's
> greater then 4GB. AFAIK x86 has no facilities like IBM's S3X0 has to
> have access to multiple address spaces at once.

Isn't that what segment selectors are for?

One problem, though, is that segment descriptors, as far
as I know, aren't cached. On S/3x0 TLB entries include the
STO (segment table origin) in such a way that they don't need
to be invalidated on STO change.

Well, that isn't quite right. Using segment selectors
and the invalid bits in the right way should allow the OS
to update page tables as needed such that segment selectors
can be used as address space selectors. There are
compilers that will generate large model 32 bit code.

-- glen

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Jerry Peters wrote:

(snip)

> No, that still doesn't get you an address space > 4GB.

Yes, it does. Virtual address space doesn't mean it is all
addressable in fast RAM at once.

> "Each segment could could have its own separate page entries in the
> page directory." What the heck does this mean? A segment doesn't "have"
> any entries in the page directory, the linear address which results
> from segmentation gets translated to a physical address using the
> page directory & page table entries. A linear address is 32 bits,
> that's 4GB of address space.

The OS can update page tables and segment valid bits at the
appropriate time. It might be that no OS does that, but the
virtual address space is still 45 bits (not counting ring
bits or global/local bit).

-- glen

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Jerry Peters wrote:


> Yeah, just what the world needs, a swapping system for segments. Can
> you say _slow_? Given the context of this discussion, about using NX
> segments, can you imagine the thrashing with disjoint 4GB code & data
> segments? That's what Yousef's proposing you realize.

If it were done some years ago, it might have made sense.
Now there is x86-64 at a reasonable price.

With reasonably locality, a program won't require updating
page tables all that often. It is only important on
machines with more than 4GB of real RAM, otherwise it
is always virtual, anyway.

-- glen

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Stephen Sprunk wrote:

(snip)

> While the physical address space can be 36-bit, isn't the linear address
> space still limited to 32-bit? If that's correct, all segments must have
> the same base (zero) if they're to have a 4GB limit.

Since most programs don't have 4GB of code, make the code
segment smaller. Segment descriptors have a limit field
that indicates the length of the segment for that reason.

-- glen

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Jerry Peters wrote:

(snip)

> In a function, automatic local variables are on the stack. I can pass
> the address of one of these to any function which is expecting a
> pointer of that type, I could also pass an address of a global or an
> address returned by malloc, all in the same function call; think
> printf and friends and character string arguments. In fact, with a
> literal format string and using gcc defaults, I'd also be passing a
> pointer in the text area of the program since gcc defaults to putting
> ro strings in the code area.

In large model code, the contents of SS or DS would be passed.
Otherwise, SS=DS but DS != CS can still be done.

-- glen

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Jerry Peters wrote:
>
> (snip)
>
> > ??? You're confused. That's how Linux works now, each process has its
> > own page tables and hence address space. Oh, except Linux doesn't use
> > a task gate, since 1) it's slow, & 2) limits you to something like
> > 4000 total processes. This still doesn't get you a _single_ AS that's
> > greater then 4GB. AFAIK x86 has no facilities like IBM's S3X0 has to
> > have access to multiple address spaces at once.
>
> Isn't that what segment selectors are for?
>
> One problem, though, is that segment descriptors, as far
> as I know, aren't cached. On S/3x0 TLB entries include the
> STO (segment table origin) in such a way that they don't need
> to be invalidated on STO change.
>
> Well, that isn't quite right. Using segment selectors
> and the invalid bits in the right way should allow the OS
> to update page tables as needed such that segment selectors
> can be used as address space selectors. There are
> compilers that will generate large model 32 bit code.
>
> -- glen
>
Yeah, I thought of that, but the tlb design on the x86 would make
things very slow; every time you switched segments, the tlb would need
to be flushed.
On S3xo, there are instructions to move to/from a secondary address
space, the OS isn't involved except to set up the bind to the
secondary space. Normal paging occurs in both AS's as needed, of
course.
Actaully I believe segment descriptors are cached, I vaguely remember
some old DOS tricks that essentially used the cached descriptors
from protected mode in real mode.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Jerry Peters wrote:
>
> (snip)
>
> > In a function, automatic local variables are on the stack. I can pass
> > the address of one of these to any function which is expecting a
> > pointer of that type, I could also pass an address of a global or an
> > address returned by malloc, all in the same function call; think
> > printf and friends and character string arguments. In fact, with a
> > literal format string and using gcc defaults, I'd also be passing a
> > pointer in the text area of the program since gcc defaults to putting
> > ro strings in the code area.
>
> In large model code, the contents of SS or DS would be passed.
> Otherwise, SS=DS but DS != CS can still be done.
>
> -- glen
>
In the context of Linux, there is no such thing as "large model code".
There's a flat 4GB AS. According to Linus, gcc doesn't support
segments (from a recent thread on LKML about NX on X64).

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:k6Swc.12684$4S5.10405@attbi_s52...
> Jerry Peters wrote:
>
> (snip)
>
> > ??? You're confused. That's how Linux works now, each process has its
> > own page tables and hence address space. Oh, except Linux doesn't use
> > a task gate, since 1) it's slow, & 2) limits you to something like
> > 4000 total processes. This still doesn't get you a _single_ AS that's
> > greater then 4GB. AFAIK x86 has no facilities like IBM's S3X0 has to
> > have access to multiple address spaces at once.
>
> Isn't that what segment selectors are for?

Selectors or not, the linear address space is still 32-bit, so a single task
cannot immediately access more than 4GB of RAM no matter how many selectors
it uses.

> Well, that isn't quite right. Using segment selectors
> and the invalid bits in the right way should allow the OS
> to update page tables as needed such that segment selectors
> can be used as address space selectors. There are
> compilers that will generate large model 32 bit code.

It may be possible to play tricks like this, but a latency in the hundreds
to thousands of cycles for an address space change makes it infeasible.
You'll get a lot more bang for your buck upgrading to a 64-bit system.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Stephen Sprunk wrote:
>
> (snip)
>
> > While the physical address space can be 36-bit, isn't the linear address
> > space still limited to 32-bit? If that's correct, all segments must have
> > the same base (zero) if they're to have a 4GB limit.
>
> Since most programs don't have 4GB of code, make the code
> segment smaller. Segment descriptors have a limit field
> that indicates the length of the segment for that reason.

So what happens when I mmap a file and later use mprotect to make
part of it executable?

>
> -- glen
>

--
Sander

+++ Out of cheese error +++

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Stephen Sprunk <stephen@sprunk.org> wrote:
>> Well, that isn't quite right. Using segment selectors
>> and the invalid bits in the right way should allow the OS
>> to update page tables as needed such that segment selectors
>> can be used as address space selectors. There are
>> compilers that will generate large model 32 bit code.
>
> It may be possible to play tricks like this, but a latency in the
> hundreds to thousands of cycles for an address space change makes it
> infeasible. You'll get a lot more bang for your buck upgrading to a
> 64-bit system.

Nobody is debating that, the only thing that was debated was whether it was
possible to do. It was just the ultimate limits of the segmented memory
model in an academic exercise.

Yousuf Khan

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

> "Each segment could could have its own separate page entries in the
> page directory." What the heck does this mean?

I think that Yousuf Khan is proposing having a separate
page table for each segment (which I am assuming
is an x86 segment - I'm coming into the middle of this).
That's an architectural change,
but a relatively minor one. If one of the x86
page table formats that produces >32 bit physical
addresses is used, this would allow each of the
2^32 addresses in a segment to map to some subset
of the, say, 2^40 physical addresses.

The architectural change might have been as simple
as having the Page Table Base Register, PTBR/CR3,
point to a memory region, each of which is the
page table base for a segment. (Taken to the extreme,
this is just another form of page table, with segment number
concatenated to the 32 bit virtual address.)

As you might imagine, Intel looked at this.
IIRC Novel seriously wanted it.

But I am rather glad that Intel did not implement
this for the x86. AMD64 is better.

Actually, in some ways I *like* 2D memory.
But it is a greater departure from the conventional
C memory model. it would have caused much more
pain than simply extending the virtual address
the way AMD64 did.

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:k6Swc.12684$4S5.10405@attbi_s52...
> One problem, though, is that segment descriptors, as far
> as I know, aren't cached.

The Intel P5 (original Pentium) had a segment descriptor cache.
Caused minor incompatibilities because it was not snooped;
i.e. it had "TLB semantics".

 

[Guest]

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Andy Glew wrote:
[having per-segment page tables]
> As you might imagine, Intel looked at this.
> IIRC Novel seriously wanted it.

I assume you meant Novell, right?

The official Novell Netware compiler for many years was Watcom, this
happens to be the only compiler I've ever used that supported 'large'
(i.e. 48-bit) pointers in 32-bit mode, not just for 16-bit segments.

> But I am rather glad that Intel did not implement
> this for the x86. AMD64 is better.

Oh, Yes!

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"