x86 Processor instruction "LDS"; When this is useful?

[osdevkid]

Hi all,

I know, what "LDS" processor command will do.

Code: Select all

ORG 100h
LDS AX, m
RET
m  DW  1234h
     DW  5678h
END

AX is set to 1234h, DS is set to 5678h.

I want to know, when we will use this command ? where it is actually required in OS development or for any other purpose.

[xenos]

As you can see in your example, it loads a far pointer into DS:AX. So whenever you want to load a far pointer from memory, you can use this (or a similar) command.

[osdevkid]

Thank you, I understood.

[miker00lz]

its very useful when you need to load a 16-bit:16-bit segment:offset vector from some memory location. it can be done easily with other operations, but this generally saves some CPU cycles. not very useful if you just want to store the values somewhere, but rather if you want to go access data from where it points to. LES is the same, but of course, moves the segment into ES.

[qw]

And LDS, LES etcetera are guaranteed not te be interrupted, which is useful when setting up a stack (with LSS).

[bewing]

I'm going to have to disagree with the tone of the previous replies. For almost all current OS or application development, segment registers are obsolete. No application should ever modify them. In a perfect world, your OS should only need to set them once, and then never touch them again. The only exception is playtime experimental rmode OSes. LDS and its cousins are somewhat extra clever opcodes for initting segment registers. Therefore, they are almost completely worthless. As implied above, you can easily perform the same functionality with a few more "regular" opcodes, and you should almost never need to init your segment registers anyway.

[miker00lz]

I'm going to have to disagree with the tone of the previous replies. For almost all current OS or application development, segment registers are obsolete. No application should ever modify them. In a perfect world, your OS should only need to set them once, and then never touch them again. The only exception is playtime experimental rmode OSes. LDS and its cousins are somewhat extra clever opcodes for initting segment registers. Therefore, they are almost completely worthless. As implied above, you can easily perform the same functionality with a few more "regular" opcodes, and you should almost never need to init your segment registers anyway.

yeah, of course. in a 32-bit OS it's worthless. it still has it's uses in stuff like simple bootloaders, etc.

[pcmattman]

Segment registers are still used in modern operating systems - consider FS and GS which are often used for TLS on x86. The concept of segmentation for code/data separation and protection however is mostly dead.

[jal]

And LDS, LES etcetera are guaranteed not te be interrupted, which is useful when setting up a stack (with LSS).

There's no need for using LSS for that reason, as MOV SS disables interrupts until the next instruction (typically a MOV SP). This has been the behaviour of every x86 since the 8086/88, which didn't discourage countless compiler writers to insert a cli/sti around the pair.


JAL

[qw]

There's no need for using LSS for that reason, as MOV SS disables interrupts until the next instruction (typically a MOV SP). This has been the behaviour of every x86 since the 8086/88, which didn't discourage countless compiler writers to insert a cli/sti around the pair.

I know, but there is a small issue:

To prevent this situation, the 80386, after both a MOV to SS and a POP to SS instruction, inhibits NMI, INTR, debug exceptions, and single-step traps at the instruction boundary following the instruction that changes SS. Some exceptions may still occur; namely, page fault and general protection fault. Always use the 80386 LSS instruction, and the problem will not occur.

[jal]

Some exceptions may still occur; namely, page fault and general protection fault. Always use the 80386 LSS instruction, and the problem will not occur.

Ok, I thought you were talking about the 8086. Which, come to think of it, didn't have LSS, or did it?


JAL