OSDev.org

what are segment registers ?

>On 2002-05-15 22:52:39, keyboard_ninja wrote:
>what are segment registers ?

The processor uses registers to make calclations in. I assume you know.
The segment registers are used for memory managment in pmode, maybe in some other modes to?
In pmode you cut the memory into pieces (segments), this is used for protected memory,
all applications has at least three segments, code segment where the code is stored, data segment
where the dynamic memory is allocated (new/delete in C++), and a stack segment, where the local variables
are stored when you call a function (C/C++, asm). Segments can have different sizes but simulates
4 Gb or 64 Gb depending on mode, thanks to this applications can't alter each others memory segments
and prevent a memory crash. the architecture is dynamic so processes can sometimes share the same segment,
shared memory.
Answer: the Segment Registers are pointers to the specific process memory areas.

>On 2002-05-15 22:52:39, keyboard_ninja wrote:
>what are segment registers ?

The processor uses registers to make calclations in. I assume you know.
The segment registers are used for memory managment in pmode, maybe in some other modes to?
In pmode you cut the memory into pieces (segments), this is used for protected memory,
all applications has at least three segments, code segment where the code is stored, data segment
where the dynamic memory is allocated (new/delete in C++), and a stack segment, where the local variables
are stored when you call a function (C/C++, asm). Segments can have different sizes but simulates
4 Gb or 64 Gb depending on mode, thanks to this applications can't alter each others memory segments
and prevent a memory crash. the architecture is dynamic so processes can sometimes share the same segment,
shared memory.
Answer: the Segment Registers are pointers to the specific process memory areas.

>On 2002-05-15 22:52:39, keyboard_ninja wrote:
>what are segment registers ?

The simple answer is, 'a pain in the @$$.'
However, you've probably already noticed that.

A bit more useful definition is that segmented
memory is a method of hardware memory management
in which the memory space is broken up into
segments, which allow for memory to be addressed
relative to the start of the segment. By
separating different programs into segments, and
using separate segments for code, data and stack
space, it provides a degree of memory protection, provided that the segments do not overlap.

That's a general description of the idea, and it's not a bad premise. It's in the actual implementation that things get kind of weird.

To understand segments in x86 systems, you need a bit of a history lesson. When the 8086 came out, memory was to expensive to waste; most contemporary small computers had 64k RAM total, and many had less. The Intel designers, however, figured that memory prices would soon drop, and figured that a 1M memory space would be adequate for the expected lifespan of the design. Also, the 8086 was meant to be an extension of the existing 8080 line, and had to be compatible with the 16-bit (64K) addressing of the older chip. Finally, they wanted some kind of memory protection, something no other microprocessor had in 1978; but they needed to keep the costs down, so virtual memory paging wasn't an option.

Their solution was to use segmentation to fill the double role of memory protection and memory extension. The devised a rather clever, but clumsy, system in which two 16-bit registers could be used to add up to a 2-bit (1M) address space:
(segment base * 16) + segment offset

or to give a practical example:
07C0 Segment base, shifted 16 bits
+00FE Segment Offset
-----
07CFE Absolute address

Segment bases were held in special segment registers, called CS (code), DS (data), SS (stack), and ES (extra). Any 'normal' 16 bit
address would be used as an offset, including the
value of the IP (instruction pointer).

Now, this design had several consequences. First,
since the offsets were 16-bits in size, the largest code size was still only 64K, and the maximum total memory space available to a program (code segment, two data segments, and a stack segment) was 256K, unless the program fiddled about with the segment bases or used 'far' pointers. Even with extensive juggling, the system could address a maximum of 1M, which seemed plenty at the time but quickly became a serious limitation.

Second, it meant that memory was broken up into 16-bit 'pages'; a segment could only begin at a page boundary. However, segments could be defined which were overlapping, or even identical. While this meant the the memory protection was easily compromised, it also meant that it was possible to simplify very small programs by having the

CS == DS == SS

allowing all memory refences be local, with no base:offset pairs. This would come to be called 'small mode', and was used by MS-DOS for the raw-binary only COMmand files.

There is more I could say, but this has already gone on long enough. What I've explained so far corresponds to the 'real mode' in modern processors; this is an artifact of the original 8086 design, kept for backwards compatibility reasons. Every x86 processor starts in real mode at boot up.

The 'protected' modes of the 286, and later the 386, were introduced as a was to solve the memory limitation problems, and improve the memory protection. For most purposes, 286 p-mode can be ignored; it's the 32-bit form of later processors that most people refer to when talking about 'protected mode'.

What Intel did with the 386 was, first off, to extend the offset size to 32 bits, allowing each segment to hold up to 4G. Second, they changed how the srgment registers are accessed; the segments for a given task are now defined by the 'segment descriptors' in each tasks Local Descriptor Table. The LDT also has additional settings about each segment, relating to access, execution rights, and virtual memory state, among other things. Finally, it was designed so that, if an OS designer chooses to, the whole system can be simplified by using the 'flat memory mode', in which all memory for the system is treated as a single 32-bit segment, and all other segment data is ingored; paging is used to implement memory management instead.

Quite a bit, isn't it? Sad to say, this is just the tip of the iceberg; segmentation has been the curse of the x86 design for over 20 years, and you really need to understnad it if you're going to do systems-level programming on the PC.

On 2002-05-17 15:04:37, Schol-R-LEA wrote:
>On 2002-05-15 22:52:39, keyboard_ninja wrote:
>what are segment registers ?

The simple answer is, 'a pain in the @$$.'
However, you've probably already noticed that.

A bit more useful definition is that segmented
memory is a method of hardware memory management
in which the memory space is broken up into
segments, which allow for memory to be addressed
relative to the start of the segment. By
separating different programs into segments, and
using separate segments for code, data and stack
space, it provides a degree of memory protection,
provided that the segments do not overlap.

That's a general description of the idea, and
it's not a bad premise. It's in the actual
implementation that things get kind of weird.

To understand segments in x86 systems, you need a
bit of a history lesson. When the 8086 came out,
memory was to expensive to waste; most
contemporary small computers had 64k RAM total,
and many had less. The Intel designers, however,
figured that memory prices would soon drop, and
figured that a 1M memory space would be adequate
for the expected lifespan of the design. Also,
the 8086 was meant to be an extension of the
existing 8080 line, and had to be compatible with
the 16-bit (64K) addressing of the older chip.
Finally, they wanted some kind of memory
protection, something no other microprocessor had
in 1978; but they needed to keep the costs down,
so virtual memory paging wasn't an option.

Their solution was to use segmentation to fill
the double role of memory protection and memory
extension. The devised a rather clever, but
clumsy, system in which two 16-bit registers
could be used to add up to a 2-bit (1M) address
space:

(segment base * 16) + segment offset

or to give a practical example:
07C0 Segment base, shifted 16 bits
+00FE Segment Offset
-----
07CFE Absolute address

Segment bases were held in special segment
registers, called CS (code), DS (data), SS
(stack), and ES (extra). Any 'normal' 16 bit
address would be used as an offset, including the
value of the IP (instruction pointer).

Now, this design had several consequences. First,
since the offsets were 16-bits in size, the
largest code size was still only 64K, and the
maximum total memory space available to a program
(code segment, two data segments, and a stack
segment) was 256K, unless the program fiddled
about with the segment bases or used 'far'
pointers. Even with extensive juggling, the
system could address a maximum of 1M, which
seemed plenty at the time but quickly became a
serious limitation.

Second, it meant that memory was broken up into
16-bit 'pages'; a segment could only begin at a
page boundary. However, segments could be defined
which were overlapping, or even identical. While
this meant the the memory protection was easily
compromised, it also meant that it was possible
to simplify very small programs by having the

CS == DS == SS

allowing all memory refences be local, with no
base:offset pairs. This would come to be called
'small mode', and was used by MS-DOS for the raw-
binary only COMmand files.

There is more I could say, but this has already
gone on long enough. What I've explained so far
corresponds to the 'real mode' in modern
processors; this is an artifact of the original
8086 design, kept for backwards compatibility
reasons. Every x86 processor starts in real mode
at boot up.

The 'protected' modes of the 286, and later the
386, were introduced as a was to solve the memory
limitation problems, and improve the memory
protection. For most purposes, 286 p-mode can be
ignored; it's the 32-bit form of later processors
that most people refer to when talking about
'protected mode'.

What Intel did with the 386 was, first off, to
extend the offset size to 32 bits, allowing each
segment to hold up to 4G. Second, they changed
how the srgment registers are accessed; the
segments for a given task are now defined by the
'segment descriptors' in each tasks Local
Descriptor Table. The LDT also has additional
settings about each segment, relating to access,
execution rights, and virtual memory state, among
other things. Finally, it was designed so that,
if an OS designer chooses to, the whole system
can be simplified by using the 'flat memory
mode', in which all memory for the system is
treated as a single 32-bit segment, and all other
segment data is ingored; paging is used to
implement memory management instead.

Quite a bit, isn't it? Sad to say, this is just
the tip of the iceberg; segmentation has been the
curse of the x86 design for over 20 years, and
you really need to understnad it if you're going
to do systems-level programming on the PC.