'mov eax, cs' (possibly bug)

Index > Compiler Internals > 'mov eax, cs' (possibly bug)

Author

Thread

TDCNL

Joined: 25 Jan 2006
Posts: 56

TDCNL

I am currently busy with OS-Dev and in pmode I use 'mov eax, cs' to put CS into EAX, (use32 directive is used before 'mov eax, cs') and FASM does not report any error.

While this should be 'movzx eax, cs', is this right?

I haven't looked at the generated code to see what is actually generated, but shouldn't FASM at least report a warning?

EDIT: Did some review on these instructions, it seems 'mov eax, cs' command isn't even valid and neither is 'movzx eax, cs'. Does FASM convert 'mov eax, cs' to 'mov ax, cs' ?

-- Greetz, TDCNL (aka new nick BugHunter)

_________________
:: The Dutch Cracker ::

14 Aug 2006, 13:36

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland

Tomasz Grysztar

No, "MOV AX,CS" and "MOV EAX,CS" are two different instructions. It was never documented properly by Intel manuals, but the AMD ones do it well.

14 Aug 2006, 14:50

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen

Intel documents it very well:

Quote:

When operating in 32-bit mode and moving data between a segment register and a generalpurpose
register, the 32-bit IA-32 processors do not require the use of the 16-bit operand-size
prefix (a byte with the value 66H) with this instruction, but most assemblers will insert it if the
standard form of the instruction is used (for example, MOV DS, AX). The processor will
execute this instruction correctly, but it will usually require an extra clock. With most assemblers,
using the instruction form MOV DS, EAX will avoid this unneeded 66H prefix. When the
processor executes the instruction with a 32-bit general-purpose register, it assumes that the 16
least-significant bits of the general-purpose register are the destination or source operand. If the
register is a destination operand, the resulting value in the two high-order bytes of the register
is implementation dependent. For the Pentium 4, Intel Xeon, and P6 family processors, the two
high-order bytes are filled with zeros; for earlier 32-bit IA-32 processors, the two high order
bytes are undefined.

14 Aug 2006, 17:00

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 7756
Location: Kraków, Poland

Tomasz Grysztar

But they don't define distinct operand forms for those instructions and thus this feature is not visible in general reference (see attached pic).
fasm uses the syntax as defined by AMD - so you've got "mov eax,ds" and "mov ax,ds", but only "mov ds,ax" in reverse direction (and so fasm doesn't fit into "the most assemblers" mentioned by Intel).

There is also a similar story with the LAR and LSL instructions.

Description:	Intel manual vs. AMD one
Filesize:	20.15 KB
Viewed:	5460 Time(s)

14 Aug 2006, 17:52

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen

You're right, Intel is too brief in this reference.

On the other side, AMD often doesn't mention some important features of an instruction. For instance, POP [ESP] first increments ESP, then stores. AMD doesn't say anything about it.

14 Aug 2006, 18:06

Madis731

Joined: 25 Sep 2003
Posts: 2140
Location: Estonia

Madis731

Conclusion? You need both manuals and some common sence?

15 Aug 2006, 07:38

TDCNL

Joined: 25 Jan 2006
Posts: 56

TDCNL

It's clear now Smile

Btw I didn't look deeply into FASM manual yet but is this behaviour documented?

_________________
:: The Dutch Cracker ::

18 Aug 2006, 12:21

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum