Why was Intel a no-show on No Execute?

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

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 comp.sys.ibm.pc.hardware.chips glen herrmannsfeldt 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.

In comp.sys.ibm.pc.hardware.chips glen herrmannsfeldt 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).

"glen herrmannsfeldt" 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

In comp.arch glen herrmannsfeldt 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 +++

Stephen Sprunk 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

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

"glen herrmannsfeldt" 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".

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

--
-
"almost all programming can be viewed as an exercise in caching"