Index
> Compiler Internals > 16 bit operand in LGDT |
| Author |
|
|
revolution 20 Oct 2023, 04:58
Where are you putting "word"? There are two places it can go. The data size and/or the address size.
Code: lgdt word[word 0x0000] |
|||
20 Oct 2023, 04:58 |
|
|
pfranz 20 Oct 2023, 05:21
I put it as "data" ("operand", to use the intel nomenclature) size, before the square bracket:
lgdt word [addr] It works fine without "word"; with it, I cannot make it work neither in 32 bit mode nor 64 bit mode |
|||
|
20 Oct 2023, 05:21 |
|
|
revolution 20 Oct 2023, 05:46
There is no word length gdt entry. IIRC it has to be at least 48-bits 16:32 (pword).
|
|||
|
20 Oct 2023, 05:46 |
|
|
Tomasz Grysztar 20 Oct 2023, 05:52
You can force the 32-bit version by specifying 6-byte operand with PWORD operator, but fasm 1 has no similar keyword for 5-byte operand to enforce 16-bit version. It is easier with fasmg/fasm2 where sizes can be defined more freely:
Code: lgdt [data5] ; 16-bit version lgdt [data6] ; 32-bit version label data5: 5 ; assembles with fasmg / fasm 2 only data6 dp ? Code: define x86.wpword? :5 ; affects x86-2.inc module of fasm 2 lgdt wpword [0] lgdt pword [0] |
|||
|
20 Oct 2023, 05:52 |
|
|
revolution 20 Oct 2023, 06:40
I think the operand is never 5 bytes. It always reads 6 bytes and ignores the top 8 bits and internally replaces them with zeros.
That could be tested by placing the address at (top_of_segment - 5) and see if it tries to read the wraparound byte at address 0. |
|||
|
20 Oct 2023, 06:40 |
|
|
Tomasz Grysztar 20 Oct 2023, 07:42
Yes, the definition of what constitutes the "operand" here is disputable, I made a compromise, but the size is the only way to attempt distinguishing these forms in fasm's syntax.
With x86-2 we could alternatively invent some new instruction decorators, but this is not just a choice of a different encoding, it is a change in what the instruction does, and for that I preferred to have a distinguished base syntax. |
|||
|
20 Oct 2023, 07:42 |
|
|
pfranz 20 Oct 2023, 13:03
Yes revolution, with 16 bit operand size I meant "read 6 bytes and use only 5".
I tried the "pword" operand size in 64bit and I get "illegal instruction" in fasm 1. So there is no way to change the operand size? It only depends on the current processor mode? |
|||
|
20 Oct 2023, 13:03 |
|
|
Tomasz Grysztar 20 Oct 2023, 13:12
pfranz wrote: So there is no way to change the operand size? It only depends on the current processor mode? Intel® 64 and IA-32 Architectures Software Developer’s Manual wrote: In 64-bit mode, the instruction’s operand size is fixed at 8+2 bytes (an 8-byte base and a 2-byte limit). |
|||
|
20 Oct 2023, 13:12 |
|
|
revolution 20 Oct 2023, 16:17
So to summarise:
Code: use16 lgdt [si] ; 0F0114 16 + 24 lgdt pword[si] ; 660F0114 16 + 32 use32 db 0x66 lgdt [esi] ; 660F0116 16 + 24 lgdt pword[esi] ; 0F0116 16 + 32 use64 lgdt tword[rsi] ; 0F0116 16 + 64 Using a macro: Code: macro lgdt24 address { local mode virtual at 0 inc ax mode = 8 shl $ end virtual if mode = 16 lgdt address else if mode = 32 db 0x66 lgdt address else if mode = 64 err "16+24 lgdt not available in 64 bit mode" end if } use16 lgdt24 [si] lgdt24 [esi] use32 lgdt24 [si] lgdt24 [esi] use64 lgdt24 [rsi] ; err |
|||
|
20 Oct 2023, 16:17 |
|
|
revolution 21 Oct 2023, 05:11
The original 80286 manual says that the CPU loads 6 bytes. And further that the last byte must be zero. So it appears that with the 16-bit encoding only the later CPUs have dropped the requirement for the zero and instead ignore the final byte.
|
||||||||||
|
21 Oct 2023, 05:11 |
|
|||||||||
|
pfranz 22 Oct 2023, 02:31
Thanks for the research. Probably 80286 wanted to be upward compatible with possible future use of 32bit base (which actually happened), and then 80386+ wanted to be backward compatible with misbehaved software that wouldn't bother to clear reserved bits.
By the way, I tried 66 prefix in 64bit mode: it works but does nothing. lgdt still reads and uses 10 bytes. |
|||
|
22 Oct 2023, 02:31 |
|
< Last Thread | Next Thread > |
Forum Rules:
|