flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > EXTRACTPS minor bug

Author
Thread Post new topic Reply to topic
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 01 Jul 2009, 10:43
Code:
extractps eax, xmm0, 0    

fasm 1.69.00 produces
Quote:
66 66 0F 3A 17 C0 00

(duplicated prefix 66h)
Post 01 Jul 2009, 10:43
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 01 Jul 2009, 11:02
The syntax of EXTRACTPS seems to be pretty weird. The manual says:
Quote:
[...] When in 64-bit mode and the destination operand is a general purpose register
(GPR), the default operand size is 64 bits. The upper 32 bits of the 64-bit register is
filled with zero.
This is what we can assume so how to deal with that? Should fasm prevent emmiting REX.W when r64 is used and disable r32 (which is not encodable if default operand size is 64 bits) under use64? Or we should take this as a nonsence in Intel manual and ignore it?
Post 01 Jul 2009, 11:02
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 01 Jul 2009, 11:44
There is similar confusion with PEXTRB:
Quote:
In 64-bit mode, [...] If the destination operand is a general-purpose register, the default operand size of PEXTRB is 64 bits.

Pointless mess, I'd say.

EDIT: see also PEXTRW.
Post 01 Jul 2009, 11:44
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland
Tomasz Grysztar 01 Jul 2009, 13:40
Yeah, we already had some discussion about this: http://board.flatassembler.net/topic.php?t=9770
The syntax that 1.68+ uses is the result of it.
Post 01 Jul 2009, 13:40
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 01 Jul 2009, 15:04
Thanks for reminding me. So the decision is to kick those weird Intel reqiurements and follow the expected way.
Post 01 Jul 2009, 15:04
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4082
Location: vpcmpistri
bitRAKE 01 Jul 2009, 15:19
MazeGen wrote:
should take this as a nonsence in Intel manual and ignore it?
Intel seems to get extremely verbose in matters not needing it, and actually just confuse the reader. I've always imagined they had a poor editor which allowed the various author perspectives to weigh to heavily on the text. It isn't like the goals changed over time, imo.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 01 Jul 2009, 15:19
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 01 Jul 2009, 15:43
Yes, seems like Intel needs more time to settle on 64 bits. The documentation, for example, on REP prefix counter size in 64-bit mode have always been wrong.
Post 01 Jul 2009, 15:43
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4082
Location: vpcmpistri
bitRAKE 02 Jul 2009, 04:14
Quote:
In 64-bit mode, default operation size is 32 bits. The default count register is RCX for REP INS and REP OUTS; it is ECX for other instructions. REX.W does not promote operation to 64-bit for REP INS and REP OUTS. However, using a REX prefix in the form of REX.W does promote operation to 64-bit operands for other REP/REPNE/REPZ/REPNZ instructions. See the summary chart at the beginning of this section for encoding data and limits.
Is this what you mean? Very Happy

...at least on Table 4-3 Notes they qualify the statement:
Quote:
* Count register is CX, ECX or RCX by default, depending on attributes of the operating modes. In 64-bit mode, if default operation size is 32 bits, the count register becomes RCX when a REX prefix is used.
...making it seem like compatibility mode allows RCX to be used. I haven't tried that, but it seems unlikely.

Code:
IF AddressSize = 16
  THEN 
    Use CX for CountReg;
  ELSE IF AddressSize = 64 and REX.W used
    THEN Use RCX for CountReg; FI;
  ELSE
    Use ECX for CountReg;
FI;    
...WTF?! This is just all wrong. Confused
Post 02 Jul 2009, 04:14
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 02 Jul 2009, 07:41
Someone from Intel told me about a way how to report typos and errors, but the form is very awkward so I have never tried it.
Post 02 Jul 2009, 07:41
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 02 Jul 2009, 21:07
I tried it, regarding a terrible description of VMXON region. Never got any feedback on that, I'd have to check next revision of manual whether they accepted it or what.
Post 02 Jul 2009, 21:07
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 02 Jul 2009, 22:18
Take a look at Table 2-1, seems they just invented a new hex number (EQ). It is the June 2009 version of the volume 2A.
Post 02 Jul 2009, 22:18
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.