Grich

Just another annoying bunch of questions.
I have found no useful answers to these questions:

1. What is segmentation?
2. How does it work?

Something simple would do. I have tried so hard to answer these, but if someone just gave me a simple answer, it may help me.

Thanks

__________________
SYNTAX ERROR ...

dr.p

I googled for "memory segmentation" and found:

http://en.wikipedia.org/wiki/Segmentation_(memory)

__________________
Neeley.org

lectricpharaoh

Read the article dr.p posted. However, bear in mind it's written with logical segments in mind. Some assemblers and compilers refer to these as 'sections' instead, to resolve the ambiguity.

For x86-based CPUs, memory is accessed with a combination of two registers. Exactly how this works depends on what mode the processor is in; this is either real address mode (or just real mode) or protected mode. There is also a virtual-8086 mode (or just V86) on 386 and higher processors, but this generally functions as real mode from the point of view of applications, so I won't discuss it here. Protected mode is further divided into 16-bit and 32-bit versions, but generally when people refer to protected mode, they're talking about 32-bit. Real mode is the default mode at boot (and the only available mode on pre-286 CPUs), while 32-bit protected mode is only available on 386 and higher CPUs.

Anyways, back to addressing. The first is the segment register, and the second is the offset. In real mode, the segment register simply stores a portion of the physical address. In particular, it stores the 'paragraph' (16-byte memory block) that the actual address starts at. Thus, if you have A000h in your segment register, and 00FFh in the offset register, the actual physical address is A00FFh. This is normally expressed with A000:00FF or some similar notation. One caveat with real mode is that multiple logical addresses map to the same physical address. For example, 9FF0:010F maps to the same address. To verify this, left-shift the segment by four bits, and add in the offset. The main point of segmented memory addressing is to allow a 16-bit CPU (or CPU in a 16-bit mode) to access more than 64k of memory. The 8086 had a 20-bit address bus, but with the 16 bit register size, it needed a pair of them to access the full address space. This is also where the 'high memory area' on later machines came in. Rather than wrap back to address 0 when an address exceeded FFFFFh, a portion of memory above the one-megabyte mark could be addressed. This was because the memory was still there, and by enabling the 21st address line (commonly called the A20 line), this wraparound did not occur. This enabled real-mode software to access just shy of an additional 64k of memory (64k minus 16, so 65520 bytes). To see how this worked, consider the address FFFF:FFFF. This maps to 10FFEFh, rather than FFEFh as on older processors without an A20 line.

Now on to protected mode. With protected mode, the segment registers do not store a portion of the physical address. Rather, each stores a 'selector', which can best be thought of as an index into a table of records (called 'descriptors'). Each descriptor stores certain things about the segment in question, such as the starting physical address (base), the size of the segment (limit), whether it expands upwards (normal) or downwards (used for stacks), the privilege level of the segment, whether it is readable, writable, and/or executable, and if it is present in memory (used for implementing one type of virtual memory). This allows memory protection to be achieved in hardware, as the CPU will raise an exception if an invalid memory operation is attempted. In some cases, this will cause the operating system to terminate the offending process, but in other cases (particularly with regards to virtual memory) it will be handled in a transparent manner (swapping in the memory from disk, for example). With 16-bit protected mode, the system can access up to 16 MB of memory (by specifying a large enough base address), but like in real mode, each segment is limited to 64k in size (as that is the size of the offset register used). In 32-bit protected mode, the full 32-bit address space could be used, by specifying a 4 GB limit. In fact, some old real-mode memory managers (notably HIMEM.SYS) used this trick: they would switch the processor into 32-bit protected mode, create descriptors with a 4-gig limit, load the selectors for those descriptors into the relevant segment registers, and drop back into real mode. As changing the segment register values in real mode would not change selectors (since selectors were only for protected mode), the descriptors would not be changed again as long as the system remained in real mode. This allowed 386+ machines to address the full range of memory through address-size overrides, which in turn made copying blocks of memory a lot faster, since it could all be done from real mode, without performance-heavy mode switches, and was a major factor in improved performance of XMS and EMS drivers on these machines.

Anyways, that's probably enough to digest for now. More than you ever wanted to know about the ugly x86 segmented architecture, no?

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

Grich

Thanks lectricpharaoh and dr.p, oh yes lectricpharaoh that is
Thankyou so much. Now I can concentrate on putting theory to practice.

__________________
SYNTAX ERROR ...

lectricpharaoh

I also have some implementation details for x86 CPUs for you; I didn't put it in the first post because it was mostly theory. There are three kinds of segment registers, which are code, stack, and data.

The CS (code segment) register stores the segment or selector for currently-executing code. You cannot directly assign to it as you can for other segment registers, but you can assign it to another register or push it on to the stack. The only way to change the value of CS is through a context switch (call, jump, interrupt, etc). IP (instruction pointer) is paired with CS to form the logical address CS:IP; this stores the address of the next instruction. When you execute a call or int instruction, either IP (near call) or CS:IP (far call, int) is pushed on the stack so the code can return. Like CS, IP cannot be directly modified.

The SS (stack segment) register stores the segment or selector value for the current stack. You can directly assign to this or otherwise muck about with it, but you'd best know exactly what you're doing. It's paired with SP (stack pointer) to form the logical address SS:SP. A push stores data at SS:SP and decrements SP, whereas a pop does the reverse. The BP register (base pointer) also implicitly uses SS as its segment register of choice, but you can override this in some circumstances with a segment override. The reason BP uses the stack segment is because it's often used to create 'stack frames' for higher-level languages.

There are two (four on 386+) data segment registers. These are DS (data segment) and ES (extra segment). By default, most data accesses will use DS. The reason ES exists is to allow you to copy data from one segment to another, without having to constantly reload the registers. On the 386 and later CPUs, there are two additional segment registers, FS and GS. I don't think that they stand for anything; I suppose they picked those names because they already had DS and ES, so they fit the pattern. In general, you can use any of these coupled with one of the general-purpose registers for addressing, though you may need an override if using a segment register besides DS (SS for BP/BP). Though there was no real need for additional segment registers, it was helpful for certain tasks. For example, you could point one at your program's data, a second at a shared memory block, and another at a memory-mapped device like a video card.

Note also that I didn't mention the extended registers, but they work identically. For example, what is DS:BX in 16-bit addressing is DS:EBX for 32-bit.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

Grich

Thanks again lectricpharaoh, you are the new DaWei of ProgrammingForums. Ha Ha!
I was looking into implementation and was getting a bit lost. Thanks.

__________________
SYNTAX ERROR ...

lectricpharaoh

Well, I wouldn't go that far- DaWei's much more knowledgeable than me, particularly about the nitty-gritty low-level stuff. Besides, he's grouchier.
Yeah, it can be a bit of a headache. I remember way back when, I wrote some DOS-based 360x240 mode-x (remember mode-x?) stuff. One bit was some custom mouse drawing code; as the regular mouse driver had no knowledge of tweaked VGA modes, I had to do the rendering on my own. The benefit was I got support for 256-color mouse cursors. I also did some custom keyboard code (to detect multiple keypresses simultaneously), timer code, and even a bit of joystick code. I intended to use the code in some games, but it never got off the ground. I think it's still kicking around somewhere, probably on my ancient 386 laptop (yes, I have a 386 in a case under the table here).

Of course, these days, it's all API stuff. Directly mucking about with the hardware is a bad thing under a modern OS. Segmented memory models are also gone for all intents and purposes, as the OS typically allocates a large virtual address space to your process, and sets up all the segment registers to point at the descriptors for this space, making everything but kernel and API calls use near pointers.

Is there some particular thing you're trying to achieve, or are you just exploring out of curiosity?

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

Grich

Ha ha!!! Were is he anyway? I haven't seen him for a while.
I'm just learning assembly out of courosity, I like to know how the computer works on the lower level.

But I am researching compiler technology as well, I'm looking into building a BASIC compiler. So, assembly would come in handy for that. I have blue prints for it I have been working on for a while now, but I don't want to continue without knowing assembly. (the compiler would be built in C++)

Mostly it is out of couriosity though. I actually find it interesting and fun.

__________________
SYNTAX ERROR ...