Using ES, FS, GS segment registers to stash values?

[cork]

I'd like to use them to store variables. Is it okay to do? Or frowned upon? Are these 3 registers being used for something else and I shouldn't tread on them?

I'm using MASM32 and writing Win32 programs. OS 64-bit Vista.

[Geryon]

You should preserve those (just like ebp, edi, esi)
And don't forget all memory operations are based on those (even procted mode, memory adress must include a segment part)

mov eax, [edi]
mov [esi], eax
actually mean
mov eax, ds:[edi]
mov es:[esi], eax
FS is a special case, SEH depend on FS, So if modify it, SEH won't be work util FS restored

[clive]

mov eax, [edi]
mov [esi], eax
actually mean
mov eax, ds:[edi]
mov es:[esi], eax

No it doesn't, you are perhaps thinking of MOVSx, CMPSx, etc where it is DS:[ESI] and ES:[EDI], but that is NOT the general rule

Operations on EBP and ESP assume SS

Loading segment (selector) registers may well cause faults on some processors as they are not designed to hold arbitrary values.

[MichaelW]

Even under conditions were loading arbitrary values into segment registers would not cause an exception, you would gain nothing by doing so. Segment registers are limited to 16-bit values, they cannot be used as general-purpose registers (as operands for arithmetic or logical instructions, for example), and moves to/from segment registers are slower than they are for the general-purpose registers or for memory.

Code Select Expand


;==============================================================================
    include \masm32\include\masm32rt.inc
    .686
    include \masm32\macros\timers.asm
;==============================================================================
    .data
        mem1 dw 0
        mem2 dw 0
    .code
;==============================================================================
start:
;==============================================================================

    invoke Sleep, 3000

    REPEAT 3
      counter_begin 1000, HIGH_PRIORITY_CLASS
      counter_end
      print str$(eax),13,10

      counter_begin 1000, HIGH_PRIORITY_CLASS
        REPEAT 8
            mov ax, 1
            mov cx, ax
            mov dx, ax
            mov ax, cx
            mov ax, dx
        ENDM
      counter_end
      print str$(eax),13,10

      counter_begin 1000, HIGH_PRIORITY_CLASS
        REPEAT 8
            mov ax, 1
            mov mem1, ax
            mov mem2, ax
            mov ax, mem1
            mov ax, mem2
        ENDM
      counter_end
      print str$(eax),13,10


      counter_begin 1000, HIGH_PRIORITY_CLASS
        REPEAT 8
            mov ax, 1
            mov es, ax
            mov gs, ax
            mov ax, es
            mov ax, gs
        ENDM
      counter_end
      print str$(eax),13,10,13,10
    ENDM

    inkey "Press any key to exit..."
    exit

;==============================================================================
end start


Running on a P3:

Code Select Expand


0
58
59
98

0
58
59
98

0
58
59
98


[clive]

They are slow because they are reading selector information (limit, base, etc) from the LDT/GDT into the TLB either from memory or from the TLB cache. I suspect on a PPro the timing would be even more hideous.

[RuiLoureiro]

I'd like to use them to store variables.
I'm using MASM32 and writing Win32 programs.

            Its not a good idea to use them to store values (variables), in my opinion.
            I use mm0,..., mm7 in some cases
RuiLoureiro

[dedndave]

they also have a thing called....
RAM

[Geryon]

mov eax, [edi]
mov [esi], eax
actually mean
mov eax, ds:[edi]
mov es:[esi], eax

No it doesn't, you are perhaps thinking of MOVSx, CMPSx, etc where it is DS:[ESI] and ES:[EDI], but that is NOT the general rule

Operations on EBP and ESP assume SS

Loading segment (selector) registers may well cause faults on some processors as they are not designed to hold arbitrary values.

I see, Thank you

[MichaelW]

They are slow because they are reading selector information (limit, base, etc) from the LDT/GDT into the TLB either from memory or from the TLB cache.

I selected the value 1 because it seemed likely to be valid for any descriptor table. Now that I test, values outside the range 0-3 trigger an access violation when they are loaded into the segment register.