OSDev.org

Octocontrabass wrote:Every memory access involves a segment register.

You don't notice it in protected mode, because most operating systems are nice and map the same addresses to CS, DS, ES, and SS.

When you fetch opcodes from memory, you must always use CS. This is important when a far jump, far call, or far return occurs, because those will change the value of CS.

When you access memory in general, the segment is usually DS. However, if the address calculation involves a stack register (BP, SP, EBP, or ESP), the segment will be SS instead. A segment override prefix will override these defaults. (Some instructions also use ES for a second memory operand. Segment override prefixes have no effect on that operand.)

When you push or pop data on the stack, the address calculation involves SP so the segment will always be SS.


Your example compares "Mov ax, word[bp+18]" and "Mov ax, word ptr ss:[bp+18]". Those are equivalent, because the effective address calculation involves BP and therefore the default segment register will be SS. (NASM produces gibberish because NASM thinks you want to disassemble 32-bit code.)

You should also check out the wiki article: Segmentation

PearOs wrote:So in that opcode SS is the override

PearOs wrote:Edit: So I read the wiki again for the third time and I think I understand my question. So if you did mov ax, word ss:[bp + 18] would the equation be (ss * 0x10) + (bp + 18)?

Octocontrabass wrote:

PearOs wrote:So in that opcode SS is the override

The opcode is "8b 46 12", right? There's no prefix and the address includes BP, so SS is the default segment.

The override prefixes are 0x2E, 0x3E, 0x26, 0x64, 0x65, and 0x36 for CS, DS, ES, FS, GS, and SS. If the opcode does not have one of those prefixes, there is no override.

PearOs wrote:Edit: So I read the wiki again for the third time and I think I understand my question. So if you did mov ax, word ss:[bp + 18] would the equation be (ss * 0x10) + (bp + 18)?

Yes, that is correct. Make sure you truncate the offset to 16 bits before adding the segment.

Octocontrabass wrote:By truncate, I mean something like this:

(ss * 0x10) + ((bp + 18) & 0xFFFF)

Octocontrabass wrote:The BIOS code is expecting to be called from an int 0x10 instruction within a real-mode program, so you must set up the registers to look like you're doing that.

A typical real-mode program will set up a stack, put the parameters for the BIOS into the appropriate registers, and then execute int 0x10. The int instruction will push FLAGS, CS, and IP to the stack, clear the IF, TF, and AC bits, and set CS:IP to the value in the IVT. When the BIOS code is done, it executes iret which pops IP, CS, and FLAGS.

The BIOS code must have CS and IP set to the correct values, and will be expecting a stack set up as I described, but any registers I didn't mention in the above paragraph can be whatever you want.

Octocontrabass wrote:CS comes from the segment for int 0x10 in the IVT. IP comes from the offset.

From your questions, it sounds like you're trying to use the physical address for the instruction pointer. I don't think that's a good idea; clever or buggy code may depend on the fact that IP is only 16 bits and wraps around when it overflows.

PearOs wrote:Should I make the IP a 16bit number and then just calculate it when I'm reading from memory by CS and then IP as the offset just in case?

Octocontrabass wrote:

PearOs wrote:Should I make the IP a 16bit number and then just calculate it when I'm reading from memory by CS and then IP as the offset just in case?

That's the simplest way to make sure it will work correctly.

It's up to you if you want to find a more complex solution. (You probably will not use the video BIOS often enough for a more complex design to have any benefit, but it might be a fun side project.)

PearOs wrote:

From your questions, it sounds like you're trying to use the physical address for the instruction pointer. I don't think that's a good idea; clever or buggy code may depend on the fact that IP is only 16 bits and wraps around when it overflows.

Your right I am, which is kinda stupid of me I agree. I used the IP as a 32bit number and Increment it when reading opcodes. This works but I may run into trouble later I feel. Thank you for your reply. I know what to set CS now. Should I make the IP a 16bit number and then just calculate it when I'm reading from memory by CS and then IP as the offset just in case?

Octocontrabass wrote:(ss * 0x10) + ((bp + 18) & 0xFFFF)

    offset = (bp+18) & 0xFFFF;
    segment = &SS_segment_info;
    if(offset+size > segment->limit) {
        do_GPF();
    }
    address = segment->base + offset;

uint32_t do_virtual_read(struct segment_info *segment, uint32_t offset, int size) {
    uint32_t linear_address;
    uint64_t physical_address;
    uint32_t result;

    // Convert virtual address to linear address
    if( ((segment->attributes & SEG_READABLE) != 0) || (offset+size > segment->limit) ) {
        do_GPF(segment->value);
    }
    linear_address = segment->base + offset;

    // Convert linear address to physical address
    if(false) {
        // For future, "if paging enabled"
    } else {
        physical_address = linear_address;
    }

    // Do read from physical address
    return do_physical_read(physical_address, size);
}

PearOs wrote:DS (Data Segment) how will I find the value for this? Or will the Video Bios not care?