flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > New instructions

Author
Thread Post new topic Reply to topic
Jin X



Joined: 06 Mar 2004
Posts: 66
Location: Russia
Jin X
Hello!

There're new instructions described in Intel SDM (October 2019):

CLRSSBSY, ENDBR32, ENDBR64, INCSSPD/INCSSPQ
RDSSPD/RDSSPQ, RSTORSSP, SAVEPREVSSP, SETSSBSY
VPCOMPRESSB/VCOMPRESSW, VPDPBUSD, VPDPBUSDS, VPDPWSSD, VPDPWSSDS, VPEXPANDB/VPEXPANDW, VPOPCNT, VPSHLD, VPSHLDV, VPSHRD, VPSHRDV, VPSHUFBITQMB, VPDPWSSDS, WRSSD/WRSSQ, WRUSSD/WRUSSQ

All of them are absent in fasm 1 now Wink


Last edited by Jin X on 27 Nov 2019, 13:11; edited 2 times in total
Post 27 Nov 2019, 12:57
View user's profile Send private message Reply with quote
Jin X



Joined: 06 Mar 2004
Posts: 66
Location: Russia
Jin X
So, VPSHLD is present but as XOP instruction.
Intel's VPSHLD is a group of AVX-512(VBMI2/VL) instructions defined as VPSHLDW, VPSHLDD and VPSHLDQ Smile
Some other instructions listed above is also group of instructions. See Intel SDM for more info.
Post 27 Nov 2019, 13:08
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
You can get them for fasmg right now. But this should also pave the way for a future implementation in fasm 1.
Post 27 Nov 2019, 16:31
View user's profile Send private message Visit poster's website Reply with quote
Jin X



Joined: 06 Mar 2004
Posts: 66
Location: Russia
Jin X
I don't need it right now. I just wanted to let you know (just in case) Smile

By the way, MOVSXD allows to use r16 and r32 as first operand but fasm 1 doesn't. This operation is meaningless but described in Intel SDM (and conflicting with ARPL in non-64-bit mode) Smile
Post 27 Nov 2019, 18:04
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
Jin X wrote:
By the way, MOVSXD allows to use r16 and r32 as first operand but fasm 1 doesn't. This operation is meaningless but described in Intel SDM (and conflicting with ARPL in non-64-bit mode) Smile
This has been discussed many years ago...
Post 27 Nov 2019, 18:44
View user's profile Send private message Visit poster's website Reply with quote
Jin X



Joined: 06 Mar 2004
Posts: 66
Location: Russia
Jin X
Some other comments:

1. PTWRITE is also absent in fasm 1.

2. It seems there's no way to specify operand size of XBEGIN instruction (rel16 or rel32). I don't know what reserved word should be used (maybe REL16 and REL32 as SHORT and NEAR for JMP: XBEGIN REL32 AbortProc).

3. SAL is encoded as SHL.
Post 27 Nov 2019, 19:01
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
Jin X wrote:
1. PTWRITE is also absent in fasm 1.
It must have fallen through the cracks. Perhaps because it is not a part of any instruction set extension.

Jin X wrote:
2. It seems there's no way to specify operand size of XBEGIN instruction (rel16 or rel32). I don't know what reserved word should be used (maybe REL16 and REL32 as SHORT and NEAR for JMP: XBEGIN REL32 AbortProc).
Back when I was implementing it, I was not sure about this, so I decided to choose fasm's usual route and I just made it automatically optimized for size.

Jin X wrote:
3. SAL is encoded as SHL.
Officially there is no separate code for SAL, it is defined as just a synonym of SHL. See my post about some undocumented opcodes.
Post 27 Nov 2019, 19:23
View user's profile Send private message Visit poster's website Reply with quote
Jin X



Joined: 06 Mar 2004
Posts: 66
Location: Russia
Jin X
Tomasz Grysztar wrote:
This has been discussed many years ago...
You wrote:

1. The manuals list MOVSX/MOVZX with forms of first operand being larger than the second one.
MOVZX has no forms with the same operand size of 1st and 2nd operands but MOVSXD has.

2. The fact that it isn't really important for programmer which encoding the assembler chooses, allows even to make the "imprint" of the assembler on the code it generates.
You limit the use of assembler to your personal vision of what is important to all programmers and what is not. However, this use can be much wider. For example, it can be sizecoding (for demoscene, where code can be part of data), obfuscation, or self-modifying code, where encoding or instruction length can be important. And many other cases that do not occur to us.
Post 27 Nov 2019, 19:27
View user's profile Send private message Reply with quote
Jin X



Joined: 06 Mar 2004
Posts: 66
Location: Russia
Jin X
Tomasz Grysztar wrote:
It must have fallen through the cracks. Perhaps because it is not a part of any instruction set extension.
Maybe but it has special CPUID bit (EAX=14h,ECX=0 : EBX[bit4]).

Tomasz Grysztar wrote:
Back when I was implementing it, I was not sure about this, so I decided to choose fasm's usual route and I just made it automatically optimized for size.
I see but it can be important e.g. for self-modifying code Smile
Post 27 Nov 2019, 19:34
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
Jin X wrote:
MOVZX has no forms with the same operand size of 1st and 2nd operands but MOVSXD has.
The manuals have changed since that discussion was taking place. But, as Intel manuals are not completely consistent anyway, I stay with my design choices.

Jin X wrote:
You limit the use of assembler to your personal vision of what is important to all programmers and what is not. However, this use can be much wider. For example, it can be sizecoding (for demoscene, where code can be part of data), obfuscation, or self-modifying code, where encoding or instruction length can be important. And many other cases that do not occur to us.
Yeah, it is hard to satisfy everyone. This realization is one of the reasons why I made fasmg instead of fasm 2. With instructions implemented simply as optional macro packages, it is possible to customize them in any way you might need. By using different macros you can get an encoder allowing to customize everything, or emulate syntax of another assembler, or whatever other could come to your mind.

Jin X wrote:
I see but it can be important e.g. for self-modifying code Smile
The early versions of fasm had many features that allowed to enforce a specific length of immediate or displacement field, specifically for the purposes of self-modifying code. But I have been gradually withdrawing these features. As it turned out, use of such features is really exceptionally rare (as self-modifying code itself is not used frequently, especially nowadays) and in the meantime fasm gained many new features that allow to get the same effect without cluttering the basic syntax with additional options. For example, you can generate an instruction with a value of immediate field that enforces the size you need and then replace it with the value you want through STORE directive.
Post 27 Nov 2019, 19:36
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7489
Location: Kraków, Poland
Tomasz Grysztar
OK, most of these new instruction sets were trivial to implement in fasm 1, the only ones left are AVX512_4VNNIW and CET_SS, because they need some specialized handlers. I could release a new version now, but there is no hurry, so I'm going to wait till I have the remaining instructions completed, too.

Having the (easier to make) fasmg macro implementations first is a great help in fasm 1 development as well. And it allows for additional cross-testing.
Post 27 Nov 2019, 20:53
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-2019, Tomasz Grysztar.

Powered by rwasa.