flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Opcoding REX.W + C7/0

Author
Thread Post new topic Reply to topic
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
Hi Tomasz,
what about REX.W + C7/0 for
MOV r/m64,imm32 and respectively all
sign-extending (32 to 64bit) instructions, AND etc. ?
i like a lot this cpu feature, but i opcode it
thru a macro with fasm. Smile

It could be a good optimization, because
lower than 80000000h it should be always
safe generating 48C7 (7 bytes) by default
instead of 48B0 (10 bytes).

Cheers,

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 05 Apr 2011, 09:20
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Looks fine to me:
Code:
use64
mov rsi,1 ;48 C7 C6 01 00 00 00    
Post 05 Apr 2011, 11:27
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
Only MOV (B8-BF) is "privileged" to use imm64. You can't use AND or any other instruction with immediate value from full 64-bit range.
Post 05 Apr 2011, 12:52
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
MazeGen wrote:
Only MOV (B8-BF) is "privileged" to use imm64. You can't use AND or any other instruction with immediate value from full 64-bit range.

mmh...,it depends on the point of view.
on 64bit platform one should use all of
the 64bit cpu capability. also, isnt
there a reason, for example, to REX.W 81/4 id ?
revolution wrote:
Looks fine to me:
Code:
use64
mov rsi,1 ;48 C7 C6 01 00 00 00
    

to me too, but please read the post carefully:
Quote:
i like a lot this cpu feature, but i opcode it
thru a macro....

...when using fasm. if you cannot imagine why, try this
Code:
 use64
    db 0100'1000b
      db 0C7h
     db 11100000b
        dd 80000000h

    db 48h
      db 0C7h
     db 00000000b
        dd 80000000h
    

Cheers,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 05 Apr 2011, 15:37
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
dd 8000000h is the encoding for 0ffffffff80000000h. Same as:
Code:
mov rsi,0xffffffff80000000    
Post 05 Apr 2011, 15:47
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
revolution wrote:
dd 8000000h is the encoding for 0ffffffff80000000h. Same as:
Code:
mov rsi,0xffffffff80000000    

...ok... it satisfies the-point-of-view's side, as i said.

but apart from the bunch of 0ffffffff to type additionally
it doesnt satisfies the following rule:

REX.W + C7 /0 MOV r/m64,imm32
Move imm32 sign extended to 64-bits to r/m64.

the CPU should "move" imm32 and extend it,
not the user Laughing .
in your example the untirable user moves...
and the cpu... swings, Laughing

Cheers

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 05 Apr 2011, 16:01
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
If I type mov rsi,0x80000000 then I would expect rsi to be 0x0000000080000000, not 0xffffffff80000000.
Post 05 Apr 2011, 16:15
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
revolution wrote:
If I type mov rsi,0x80000000 then I would expect rsi to be 0x0000000080000000, not 0xffffffff80000000.

and if you need 0xffffffff80000000 ...
what would nt you "type" for that ?

that's... funny, revolution ! Laughing
but why have we imm32 / imm64, two different
opcodable data sizes ? for amusement ? sport ?
ok! that's my point of view:
sport!

Cheers,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 05 Apr 2011, 16:35
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Your suggestion to encode 0x80000000 as a dword is wrong because the CPU will place 0xffffffff80000000 into the register. That is what your macro is encoding, the 64 bit sign extended value of imm32 0x80000000.

Either that or I completely misunderstand what you are trying to say.
Post 05 Apr 2011, 16:57
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
revolution wrote:
Your suggestion to encode 0x80000000 as a dword is wrong because the CPU will place 0xffffffff80000000 into the register....

.. the point of view , as i said., do you know the point of view ?; i see a signed DWORD sometimes, sometimes
an UNSIGNED one, sometimes something else.
i make the policy, because i am the person who codes.
what CPU places is correct, when using that encoding !
Quote:
Either that or I completely misunderstand what you are trying to say.

what you often misunderstand is the meaning of 64bit signing extension for the meaning of "encoding". Most programmers misunderstand that. but as you know, it is basic, the ground when porting to 64bit, not only for that instruction and opcoding above. But, related to fasm, it is always an ecoding problem, not mine (i can use macro)
Also,if you misunderstand what i said, well... that's not my problem. that's your encoding. Laughing

Cheers...

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 05 Apr 2011, 17:24
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Are you saying that you don't care about the upper 32 bits of the 64 bit register? If so then, yes, you can encode as a dword, but otherwise there is no way to encode 0x0000000080000000 in 7 bytes. The CPU will always sign extend it.
hopcode wrote:
it should be always
safe generating 48C7 (7 bytes) by default
Not true. The assembler must do as told and not assume that the upper 32 bits don't matter.
Post 05 Apr 2011, 17:45
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
You can type "mov rsi,0xffffffff80000000" or "mov rsi,-80000000h", they mean the same. But "mov rsi,80000000h" is a different instruction. fasm focuses on instruction functionality - that is, with assembly mnemonics you specify what instruction exactly should do, and not what kind of encoding it should have (assembler should select the optimal encoding itself). There are some exceptions in fasm 1.x (like when you put size operator just before immediate, you enforce the long encoding of that value), but I plan to separate those things completely with fasm 2.0 (as revolution already knows, BTW).
Post 05 Apr 2011, 17:47
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Tomasz Grysztar wrote:
... I plan to separate those things completely with fasm 2.0 (as revolution already knows, BTW).
Yep, revolution knows, and is scared of it also. Paradigm changes are always scary things.
Post 05 Apr 2011, 17:54
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
hopcode wrote:
MazeGen wrote:
Only MOV (B8-BF) is "privileged" to use imm64. You can't use AND or any other instruction with immediate value from full 64-bit range.

mmh...,it depends on the point of view.
on 64bit platform one should use all of
the 64bit cpu capability. also, isnt
there a reason, for example, to REX.W 81/4 id ?

REX.W 81/4 id can't use immediate from full 64-bit range, only values from 0 to 7FFFFFFF, and from FFFFFFFF80000000 to FFFFFFFFFFFFFFFF (in contrast to REX.W B8-BF).
Post 06 Apr 2011, 11:05
View user's profile Send private message Visit poster's website Reply with quote
hopcode



Joined: 04 Mar 2008
Posts: 563
Location: Germany
hopcode
MazeGen wrote:
REX.W 81/4 id can't use immediate from full 64-bit range, only values from 0 to 7FFFFFFF,
and from FFFFFFFF80000000 to FFFFFFFFFFFFFFFF (in contrast to REX.W B8-BF).

i didn't say the contrary. id,imm32 are quantities.
the problem arises by encoding them, the meaning you
give / the assembler gives to that encoding. i said:
i use macros. now, please follow the post carefully:
revolution wrote:

Not true. The assembler must do as told and not assume that the upper 32 bits don't matter.


When you program something for a specified cpu,
you open the manual and read what the cpu manual
preserves, how data must be "opcoded". but the manual
tell you neither how those datas should be symbolized
nor what meaning they have for you or fasm. Also
we accept sign extension from the manual so exaclty as
the fact of the explicit 48C7 z-extension on value
below 80_ . your encoding habit maybe fasm encoding
habit, but that doesnt mean it is the finest habit
or the most flexible and coherent one (the nearest one
to the cpu).

Genius Tomasz wrote:
You can type "mov rsi,0xffffffff80000000"
or "mov rsi,-80000000h", they mean the same.

it depends on what flexibility your assembler have,
the point of view. When accepting fasm style, we accept
obviously this too.

Tomasz wrote:
But "mov rsi,80000000h" is a different instruction.
Question
No, why should it be ? it maybe fasm big implicitness
that inhibits the flexibility of what the cpu manual
preserves as doable or as rule. In fact you could use yet
another encoding marker (God save us!) to signify
discreptionality, for example

"mov rsi,0x80000000L" as DWORD or
"mov rsi,0x80000000X" as extendable opcoding

just like "0x" marker or the "h" marker or, alike in
your habit, the 0xffffffff one.
Also then, we weight pros and contras of fasm encoding
and this is the result
Code:
       mov rax,80000000h                                               ; 48B8 0000008000000000            mov rax,0000000080000000
 mov rax,7FFFFFFFh                                               ; 48C7 C0 FFFFFF7F                 mov rax,7FFFFFFF
 mov rax,0xffffffff80000000      ; 48C7 C0 00000080                 mov rax,FFFFFFFF80000000
 mov rax,-80000000h          ; 48C7 C0 00000080                 mov rax,FFFFFFFF80000000
     mov rax,+80000000h          ; 48B8 0000008000000000            mov rax,0000000080000000
     mov rax,-7FFFFFFFh          ; 48C7 C0 01000080                 mov rax,FFFFFFFF80000001
     mov rax,not 7FFFFFFFh       ; 48C7 C0 00000080                 mov rax,FFFFFFFF80000000
     ; mov rax,dword 7FFFFFFFh               ; operand sizes do not match !!!
    ; mov rax,dword -7FFFFFFFh      ; operand sizes do not match !!!
    

Also,laught at your coherence! it's not so bad after all.

ipse dixit wrote:
but I plan to separate those things completely with fasm 2.0 (as revolution already knows, BTW).

But you, Tomasz, again and again with that talking about fasm 2
without having got it publicly accessible... is somewhat "dirty"
from you! Make it publicly accessible, then we will see and
consider those features you are talking about. If you believe
to be cleverer, this doesnt give you permission/right to
fool,"punish" i would say, the readers by overbloating them this way.
It's fasm-1-encoding's convenience the eventual thema!

Then finally: you quoting yourself this way is pure complacency
on this dead forum: "pure" because you speak about something that
is not under our eyes , and "dead", is the goal in your speaking.
because alike most other fine programmers who come anymore or only occasionally
here ,-i am here only to review my posts-,or
just like the reader, who cannot learn anything from your implicit
self cerebral looping... and from the technical level of
your superficial discussion, that's all.

Horse sense, please ,
dont take it personally against you !

Bye,
Very Happy

_________________
⠓⠕⠏⠉⠕⠙⠑
Post 06 Apr 2011, 15:38
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
hopcode wrote:
Tomasz wrote:
But "mov rsi,80000000h" is a different instruction.
Question
No, why should it be ? it maybe fasm big implicitness
that inhibits the flexibility of what the cpu manual
preserves as doable or as rule.
It should be and IS, because it has a different effect - in first case you load value 0FFFFFFFF80000000h into RSI, in second one you load the value 80000000h. This is a substantial difference in what instruction does. "0xffffffff80000000" can be interpreted as 64-bit "-80000000h", but it in no way is the same as "80000000h".
hopcode wrote:
But you, Tomasz, again and again with that talking about fasm 2
without having got it publicly accessible... is somewhat "dirty"
from you! Make it publicly accessible, then we will see and
consider those features you are talking about.

fasm 2 for now exists only in my mind, because I prefer to prepare a good design before I start coding. And as some parts of this design are still subject to change, I do not say too much about the details, though you could hear some elementary information about it on fasmcon 2009.
Post 06 Apr 2011, 16:25
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
revolution wrote:
Tomasz Grysztar wrote:
... I plan to separate those things completely with fasm 2.0 (as revolution already knows, BTW).
Yep, revolution knows, and is scared of it also. Paradigm changes are always scary things.
It would not really be a paradigm change, just treating the existing paradigm more seriously. Because, as i once explained in my Design Principles, from the beginning I wanted fasm to focus on instruction syntax defining unequivocally what the instruction does exactly, as I saw assembler as tool that should separate you from the instruction code and choose the good encoding itself, only being told what you expect to get. Like being told what 64 bits you want to have exactly in your RSI register after executing an instruction, as in example discussed in this thread.
Post 06 Apr 2011, 16:36
View user's profile Send private message Visit poster's website 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-2020, Tomasz Grysztar.

Powered by rwasa.