"Stephen Sprunk" writes:
> I've read of people trying to implement things like bounded pointers
> via segmentation, but the limitation of 8192 objects quickly stymies
> that approach in practice.

and i thot i was raising an issue with only 16 (concurrent) objects in
801/romp/rios. 801 post collection
http://www.garlic.com/~lynn/subtopic.html#801

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

From:	George Neuner
Subject:	Re: increasing addressable memory via paged memory?
Date:	Sun, 16 Jan 2005 02:59:22 -0500

On 14 Jan 2005 17:05:43 -0800, "joshc" wrote:

>
>B.Crowhurst wrote:
>> I Think it's clear you are confusing virtual memory concepts with
>> segment:offset methods.
>
>How so? Extrapolate, please.

Look at Intel's 32-bit MMU. The physical address space is the usual
4GB of RAM, but in protected mode the MMU uses both segmenting and
paging to provide a 64 terabyte virtual address space.

The segmenting architecture was a holdover from the 80286 design which
based virtual memory entirely on segmenting. Paging was know to be
faster and more efficient, so when Intel introduced the 80386, paging
capability was added to the MMU.

However, once paging was introduced, OS designers mostly ignored
segmenting entirely in favor of the much faster paging. If they used
segmenting at all they only created 2 segments: user space and kernel
space. As long as the total address space was limited to 4GB
(enormous at the time), it was more efficient to use paging alone so
most 32 bit operating systems made no use of segmenting.

32 bit x86 software can still do protected mode segmenting, but I
believe it is now very slow to use ... I have a vague recollection
that Intel reduced the on-chip translation tables to just 2 entries
due to the lack of interest in using more. Intel long ago deprecated
use of segmenting and did not include it at all in their 64 bit
designs.

George
--
for email reply remove "/" from address

From:	Grumble
Subject:	Re: increasing addressable memory via paged memory?
Date:	Wed, 19 Jan 2005 09:37:14 +0100

George Neuner wrote:

> Intel long ago deprecated use of segmenting and did not include it at
> all in their 64-bit designs.

(I don't think you mean IA-64.)

Aside from IA-64, there is no 64-bit design you can call Intel's.

--
Regards, Grumble

From:	George Neuner
Subject:	Re: increasing addressable memory via paged memory?
Date:	Wed, 19 Jan 2005 14:30:49 -0500

On Wed, 19 Jan 2005 09:37:14 +0100, Grumble
wrote:

>George Neuner wrote:
>
>> Intel long ago deprecated use of segmenting and did not include it at
>> all in their 64-bit designs.
>
>(I don't think you mean IA-64.)
>
>Aside from IA-64, there is no 64-bit design you can call Intel's.

IA-64 is a common instruction set. I was referring to the sense that
each differently featured chip is a different design.

George
--
for email reply remove "/" from address

From:	John Dallman
Subject:	Re: increasing addressable memory via paged memory?
Date:	Wed, 19 Jan 2005 23:43 +0000 (GMT Standard Time)

In article ,
gneuner2/@comcast.net (George Neuner) wrote:

> Intel long ago deprecated use of segmenting and did not include
> it at all in their 64 bit designs.

It's there, I think. People on comp.arch have referred to it. Nobody uses
it at at present, because there's little need with 64-bit addressing
within segments, but it does allow for more than 64-bit address space per
process.

---
John Dallman jgd@cix.co.uk
"Any sufficiently advanced technology is indistinguishable from a
well-rigged demo"

From:	Terje Mathisen
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 20 Jan 2005 08:12:01 +0100

John Dallman wrote:

> In article ,
> gneuner2/@comcast.net (George Neuner) wrote:
>
>
>>Intel long ago deprecated use of segmenting and did not include
>>it at all in their 64 bit designs.
>
> It's there, I think. People on comp.arch have referred to it. Nobody uses
> it at at present, because there's little need with 64-bit addressing
> within segments, but it does allow for more than 64-bit address space per
> process.

No, it isn't (more or less):

AMD have specifically disallowed/disabled segment registers in 64-bit
mode, with a single exception: FS & GS are still sort of working to make
it easier to support Windows which use these for some kind of
process-private data store.

My guess would be that this is specifically to allow a 64-bit windows to
have 32-bit clients, without forcing the OS to switch in&out of 32-bit
mode to be able to setup these memory areas.

I would be _very_ surprised if they support anything but the 32-bit
maximum address range for these segments though, even in 64-bit mode.

Terje

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

From:	Stephen Sprunk
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 20 Jan 2005 11:59:28 -0600

"Terje Mathisen" wrote in message
news:csnlk1$2cd$1@osl016lin.hda.hydro.com...
> John Dallman wrote:
>
> > In article ,
> > gneuner2/@comcast.net (George Neuner) wrote:
> >
> >
> >>Intel long ago deprecated use of segmenting and did not include
> >>it at all in their 64 bit designs.
> >
> > It's there, I think. People on comp.arch have referred to it. Nobody
uses
> > it at at present, because there's little need with 64-bit addressing
> > within segments, but it does allow for more than 64-bit address space
per
> > process.

How could it, with a 64-bit linear address space? Same problem that 32-bit
x86 had -- the virtual address space is the same size as the linear address
space.

> No, it isn't (more or less):
>
> AMD have specifically disallowed/disabled segment registers in 64-bit
> mode,

They're not quite disabled, but the segment override prefixes are ignored
and the base/limit are assumed to be fixed values for CS, SS, DS, ES.

> with a single exception: FS & GS are still sort of working to make
> it easier to support Windows which use these for some kind of
> process-private data store.

FS and GS are still used, which is odd, but perhaps that's because they must
be explicitly used instead of implied by various instructions. Linux uses
FS for thread-local storage and GS for per-processor information in AMD64
(whereas it used GS for thread-local in x86 and FS for nothing). I haven't
bothered looking up what Windows x64 does.

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

From:	Eric P.
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 20 Jan 2005 10:16:05 -0500

Terje Mathisen wrote:
>
> John Dallman wrote:
>
> > In article ,
> > gneuner2/@comcast.net (George Neuner) wrote:
> >
> >
> >>Intel long ago deprecated use of segmenting and did not include
> >>it at all in their 64 bit designs.
> >
> > It's there, I think. People on comp.arch have referred to it. Nobody uses
> > it at at present, because there's little need with 64-bit addressing
> > within segments, but it does allow for more than 64-bit address space per
> > process.
>
> No, it isn't (more or less):
>
> AMD have specifically disallowed/disabled segment registers in 64-bit
> mode, with a single exception: FS & GS are still sort of working to make
> it easier to support Windows which use these for some kind of
> process-private data store.

In 64 bit (aka Long) mode on WNT

FS points to the Thread Environment Block, a record containing all
sorts interesting stuff about the current thread like a pointer to
the current exception handler and Thread Local Store pointers.
This is for both User and Kernel mode (different records of course).

In kernel mode GS points at the Processor Control Region for the
current cpu, a record containing info on this cpu's state like
interrupt mask or priority level, pending DPC's (aka driver forks).
Each cpu in an SMP system has a record at a different virtual
address in system space.

The fields in these records are accessed using a segment override
prefix which adds the seg base to a field offset:

mov eax, fs:[0x14]

I believe Linux uses them for similar purpose.

> My guess would be that this is specifically to allow a 64-bit windows to
> have 32-bit clients, without forcing the OS to switch in&out of 32-bit
> mode to be able to setup these memory areas.
>
> I would be _very_ surprised if they support anything but the 32-bit
> maximum address range for these segments though, even in 64-bit mode.

It is a bit of a dogs breakfast. The manual takes 66 pages to
cover just segmentation. The simplified description is:

In 64 bit Long mode segmentation is present and descriptors
are loaded though it is mostly disabled.

CS code segment descriptor base and limit values are ignored.
It contains the L bit that enables Long mode.

SS, DS and ES descriptors the base and limit values are ignored.
Only the Present bit is looked at.

FS and GS the 64 bit base field is added to the effective address.
To allow loading all 64 bits of the base address, the FS.base and
GS.base hidden descriptor-register fields are mapped to MSRs.
Privileged software (CPL=0) can load the 64-bit base address
into FS.base or GS.base using a single WRMSR instruction.

The LDT and TSS system-segment descriptors expand to 128 bits
and have changed layouts. Interrupt, Trap and Call Gates all
get 64 bit bases.

Eric

From:	Terje Mathisen
Subject:	Re: increasing addressable memory via paged memory?
Date:	Thu, 20 Jan 2005 18:08:01 +0100

Eric P. wrote:

> Terje Mathisen wrote:
>>My guess would be that this is specifically to allow a 64-bit windows to
>>have 32-bit clients, without forcing the OS to switch in&out of 32-bit
>>mode to be able to setup these memory areas.
>>
>>I would be _very_ surprised if they support anything but the 32-bit
>>maximum address range for these segments though, even in 64-bit mode.
>
> It is a bit of a dogs breakfast. The manual takes 66 pages to
> cover just segmentation. The simplified description is:
[Nice explanation snipped]

Thanks!

Terje

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

From:	John Dallman
Subject:	Re: increasing addressable memory via paged memory?
Date:	Fri, 21 Jan 2005 20:31 +0000 (GMT Standard Time)

> It's there, I think. People on comp.arch have referred to it.

Gnah! I was thinking about IA-64.

---
John Dallman jgd@cix.co.uk
"Any sufficiently advanced technology is indistinguishable from a
well-rigged demo"

From:	Patrick Schaaf
Subject:	Re: increasing addressable memory via paged memory?
Date:	16 Jan 2005 10:26:08 GMT

George Neuner writes:

>Look at Intel's 32-bit MMU. The physical address space is the usual
>4GB of RAM, but in protected mode the MMU uses both segmenting and
>paging to provide a 64 terabyte virtual address space.

No, not really. Only by a play of words. What everybody else calls
a virtual address, Intel calls a linear address. Linear addresses
are converted by the MMU to physical addresses, through hardware
TLBs, and OS provided page tables.

Linear addresses are 32 bit.

Segmentation is a completely orthogonal feature of the x86 instruction set.
When addressing memory, an x86 code can specify a segment register number,
along with the address itself. Through a table lookup mechanism similar
to the TLB / page table setup, the segment register number is converted
into a - 32 bit - linear base address. The address given by the memory
addressing instruction, is added (mod 2^32) to this linear base address,
giving the - 32 bit - linear address to look up through the usual paging
mechanism.

Without OS intervention to modify segment table contents AND paging table
contents at the same time, the application has no more than 32 bit of virtual
addressing at its hands. Even with such OS intervention, and its cost,
really using a lot more than the 32 bit space given, will continually
modify vast parts of the process' page tables, making the segments
formerly referring to these parts 'invalid' (for later trapping and
transparent vast remodification of page tables). If the application
happens to work on several 2^32 bit segments at once, things will
thrash quite a bit...

Does anybody know a contemporary, real world application, which uses
segmentation in this way?

best regards
Patrick

From:	George Neuner
Subject:	Re: increasing addressable memory via paged memory?
Date:	Mon, 17 Jan 2005 13:33:24 -0500

On 16 Jan 2005 10:26:08 GMT, mailer-daemon@bof.de (Patrick Schaaf)
wrote:

>George Neuner writes:
>
>>Look at Intel's 32-bit MMU. The physical address space is the usual
>>4GB of RAM, but in protected mode the MMU uses both segmenting and
>>paging to provide a 64 terabyte virtual address space.
>
>No, not really. Only by a play of words. What everybody else calls
>a virtual address, Intel calls a linear address. Linear addresses
>are converted by the MMU to physical addresses, through hardware
>TLBs, and OS provided page tables.
>
>Linear addresses are 32 bit.

Yes I know. Virtual addresses are not linear addresses.

>Segmentation is a completely orthogonal feature of the x86 instruction set.
>When addressing memory, an x86 code can specify a segment register number,
>along with the address itself. Through a table lookup mechanism similar
>to the TLB / page table setup, the segment register number is converted
>into a - 32 bit - linear base address. The address given by the memory
>addressing instruction, is added (mod 2^32) to this linear base address,
>giving the - 32 bit - linear address to look up through the usual paging
>mechanism.

When the 386 is in protected mode, the segment selector designates a
contiguous 4GB range indexed by the 32-bit offset register. The high
20 bits of the offset register are used as the page index and the low
12 bits index the page. The original design followed the 286 and
allowed, IIRC, 16384 segments each of which was 4GB.

In the 386 these segments were really protection zones rather than
divisions of RAM. The design allowed the OS and each application top
each have it's own full 4GB address space without stepping on each
other.

The problem was that changing the segment registers in protected mode
took hundreds of cycles ... updating the segment selector tables took
10s of thousands of cycles. Nobody imagined needing more than 4GB for
everything and paging was so much faster that most OS designers simply
initialized a single segment entry and set all the segment registers
to use it.

>Without OS intervention to modify segment table contents AND paging table
>contents at the same time, the application has no more than 32 bit of virtual
>addressing at its hands. Even with such OS intervention, and its cost,
>really using a lot more than the 32 bit space given, will continually
>modify vast parts of the process' page tables, making the segments
>formerly referring to these parts 'invalid' (for later trapping and
>transparent vast remodification of page tables). If the application
>happens to work on several 2^32 bit segments at once, things will
>thrash quite a bit...

You don't need OS intervention - you simply need certain protected
mode instructions. The OS has to allow this of course.

>Does anybody know a contemporary, real world application, which uses
>segmentation in this way?

No I don't. However, had it been used, segmenting could have solved
15 years ago all the problems the new Data Execution Prevention (DEP)
scheme is now supposed to address.

As I said previously, I know the newer chips still support segmenting
in protected mode, but I think the implementation has been severely
restricted due to lack of interest.

>best regards
> Patrick

George
--
for email reply remove "/" from address

From:	Stephen Sprunk
Subject:	Re: increasing addressable memory via paged memory?
Date:	Sun, 16 Jan 2005 17:27:17 -0600

"Patrick Schaaf" wrote in message
news:41ea4140$0$27803$9b622d9e@news.freenet.de...
> Without OS intervention to modify segment table contents AND
> paging table contents at the same time, the application has no more
> than 32 bit of virtual addressing at its hands. Even with such OS
> intervention, and its cost, really using a lot more than the 32 bit
> space given, will continually modify vast parts of the process'
> page tables, making the segments formerly referring to these
> parts 'invalid' (for later trapping and transparent vast remodification
> of page tables). If the application happens to work on several
> 2^32 bit segments at once, things will thrash quite a bit...
>
> Does anybody know a contemporary, real world application, which uses
> segmentation in this way?

On x86? I'm not aware of any modern OS that does more than the minimum with
segments. AFAIK, the segment base and limit are set to 0 and 4GB,
respectively, for all segments in Win32 and the various Unicies.

There is a Linux 4GB user + 4GB kernel patch, generally associated with
RedHat Enterprise Edition, that swaps the page tables out before/after each
syscall, but it doesn't fiddle with the segment registers AFAICT.

The 32-bit size of x86 linear addresses seriously constraints the usefulness
of segmentation; paging accomplishes many of the same goals much more
effectively. Segmentation's role has been drastically reduced in AMD64, not
coincidentally.

I've read of people trying to implement things like bounded pointers via
segmentation, but the limitation of 8192 objects quickly stymies that
approach in practice.

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

From:	Edward A. Feustel
Subject:	Re: increasing addressable memory via paged memory?
Date:	Tue, 18 Jan 2005 07:19:13 -0500

"Stephen Sprunk" wrote in message
news:1106041068.5b0b1713e8a11125873f98d1d045c520@teranews...
> "Patrick Schaaf" wrote in message
> news:41ea4140$0$27803$9b622d9e@news.freenet.de...
>> Without OS intervention to modify segment table contents AND
>> paging table contents at the same time, the application has no more
>> than 32 bit of virtual addressing at its hands. Even with such OS
>> intervention, and its cost, really using a lot more than the 32 bit
>> space given, will continually modify vast parts of the process'
>> page tables, making the segments formerly referring to these
>> parts 'invalid' (for later trapping and transparent vast remodification
>> of page tables). If the application happens to work on several
>> 2^32 bit segments at once, things will thrash quite a bit...
>>
>> Does anybody know a contemporary, real world application, which uses
>> segmentation in this way?
>
> On x86? I'm not aware of any modern OS that does more than the minimum
> with
> segments. AFAIK, the segment base and limit are set to 0 and 4GB,
> respectively, for all segments in Win32 and the various Unicies.
>
> There is a Linux 4GB user + 4GB kernel patch, generally associated with
> RedHat Enterprise Edition, that swaps the page tables out before/after
> each
> syscall, but it doesn't fiddle with the segment registers AFAICT.
>
> The 32-bit size of x86 linear addresses seriously constraints the
> usefulness
> of segmentation; paging accomplishes many of the same goals much more
> effectively. Segmentation's role has been drastically reduced in AMD64,
> not
> coincidentally.
>
> I've read of people trying to implement things like bounded pointers via
> segmentation, but the limitation of 8192 objects quickly stymies that
> approach in practice.
>
> 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
>
>
The only "decent" implementation of segmentation that Intel ever did was on
the Intel 960XA which was used by the short-lived BiiN OS. In order to be
truely useful,
each segment should have its own page table and unfortunately the X86 has
never done this.
As Multics showed, it is quite natural to use segments as a basis for
protection of objects
while paging is simply used to manage physical memory. Then sharing is done
using segments
and not pages. Intel just never caught on.

Ed

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---