Author Topic: VPERMILPS Bug?!  (Read 2448 times)

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #30 on: August 10, 2019, 09:51:41 PM »
A note:
Opcodes project have a opcode database in xml format.
Creating a csv-file from it could be useful, even that database has it's own limits.

asmdb as js/json format.

Hi TimoVJL,

that's exactly what I did, I used this file - https://github.com/golang/arch/blob/master/x86/x86.csv. This file was made based on intelxed/xed datafiles https://github.com/intelxed/xed/tree/master/datafiles, in my opinion this is the best database of all instructions. The csv file itself was generated using Golang x86avxgen, I tried to generate a new database relevant for avx-512, but i'm stuck with that go language  :undecided: :sad:

As an option, I can try to parse instructions directly https://github.com/intelxed/xed/blob/master/datafiles/avx/avx-isa.txt, they have a format similar to ...
Code: [Select]
AVX_INSTRUCTIONS()::
{
ICLASS    : VADDPD
EXCEPTIONS: avx-type-2
CPL       : 3
CATEGORY  : AVX
EXTENSION : AVX
ATTRIBUTES: MXCSR
PATTERN : VV1 0x58  V66 VL128 V0F MOD[mm] MOD!=3 REG[rrr] RM[nnn] MODRM()
OPERANDS  : REG0=XMM_R():w:dq:f64 REG1=XMM_N():r:dq:f64 MEM0:r:dq:f64

PATTERN : VV1 0x58  V66 VL128 V0F MOD[0b11] MOD=3 REG[rrr] RM[nnn]
OPERANDS  : REG0=XMM_R():w:dq:f64 REG1=XMM_N():r:dq:f64 REG2=XMM_B():r:dq:f64

PATTERN : VV1 0x58  V66 VL256 V0F MOD[mm] MOD!=3 REG[rrr] RM[nnn] MODRM()
OPERANDS  : REG0=YMM_R():w:qq:f64 REG1=YMM_N():r:qq:f64 MEM0:r:qq:f64

PATTERN : VV1 0x58  V66 VL256 V0F MOD[0b11] MOD=3 REG[rrr] RM[nnn]
OPERANDS  : REG0=YMM_R():w:qq:f64 REG1=YMM_N():r:qq:f64 REG2=YMM_B():r:qq:f64
}


{
ICLASS    : VADDPS
EXCEPTIONS: avx-type-2
CPL       : 3
CATEGORY  : AVX
EXTENSION : AVX
ATTRIBUTES: MXCSR
PATTERN : VV1 0x58  VNP VL128 V0F MOD[mm] MOD!=3 REG[rrr] RM[nnn] MODRM()
OPERANDS  : REG0=XMM_R():w:dq:f32 REG1=XMM_N():r:dq:f32 MEM0:r:dq:f32

PATTERN : VV1 0x58  VNP VL128 V0F MOD[0b11] MOD=3 REG[rrr] RM[nnn]
OPERANDS  : REG0=XMM_R():w:dq:f32 REG1=XMM_N():r:dq:f32 REG2=XMM_B():r:dq:f32

PATTERN : VV1 0x58  VNP VL256 V0F MOD[mm] MOD!=3 REG[rrr] RM[nnn] MODRM()
OPERANDS  : REG0=YMM_R():w:qq:f32 REG1=YMM_N():r:qq:f32 MEM0:r:qq:f32

PATTERN : VV1 0x58  VNP VL256 V0F MOD[0b11] MOD=3 REG[rrr] RM[nnn]
OPERANDS  : REG0=YMM_R():w:qq:f32 REG1=YMM_N():r:qq:f32 REG2=YMM_B():r:qq:f32
}


{
ICLASS    : VADDSD
EXCEPTIONS: avx-type-3
CPL       : 3
ATTRIBUTES : simd_scalar MXCSR
CATEGORY  : AVX
EXTENSION : AVX
PATTERN : VV1 0x58  VF2  V0F  MOD[mm] MOD!=3 REG[rrr] RM[nnn] MODRM()
OPERANDS  : REG0=XMM_R():w:dq:f64 REG1=XMM_N():r:dq:f64 MEM0:r:q:f64

PATTERN : VV1 0x58  VF2  V0F  MOD[0b11] MOD=3 REG[rrr] RM[nnn]
OPERANDS  : REG0=XMM_R():w:dq:f64 REG1=XMM_N():r:dq:f64 REG2=XMM_B():r:q:f64
}

Working with the csv format is easier for me, this leads to the main goal, that I can combine fake instructions and intentionally create the conditions for an error. Everything should be as simple as possible. There are three options, generate fake instructions in memory, use generic structures(Currently used), use a pre-prepared base for spoiled instructions. The first is too expensive, the other two are perfect. Xed parser complicates the whole structure, but I think it can be done. Xed has 5202 instructions in the description.

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #31 on: August 13, 2019, 04:18:55 AM »
Hi,

I think I was wrong, because the database file is generated by another technique, they wanted to introduce the method above, but it needs improvement ...
Details can be obtained at the link - https://godoc.org/golang.org/x/arch/x86/x86spec

Quote
Command x86spec
X86spec reads the “Intel® 64 and IA-32 Architectures Software Developer's Manual” to collect instruction encoding details and writes those details to standard output in CSV format.

Usage:

x86spec [-f file] [-u url] >x86.csv
The -f flag specifies the input file (default x86manual.pdf), the Intel instruction set reference manual in PDF form. If the input file does not exist, it will be created by downloading the manual.

The -u flag specifies the URL from which to download the manual (default https://golang.org/s/x86manual, which redirects to Intel's site). The URL is downloaded only when the file named by the -f flag is missing.

There are additional debugging flags, not shown. Run x86spec -help for the list.

Intel® 64 and IA-32 Architectures Software Developer’s Manual - Last updated 2019-05-30 - https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
All instructions can be found in the pdf file, the question is how to copy the tables correctly ?!

TimoVJL

  • Member
  • ***
  • Posts: 476
Re: VPERMILPS Bug?!
« Reply #32 on: August 13, 2019, 04:34:18 PM »
https://www.codeproject.com/articles/7056/code-to-extract-plain-text-from-a-pdf-file

EDIT: some streams needs a bigger buffer:
size_t outsize = (streamend - streamstart)*105;
« Last Edit: August 13, 2019, 06:09:33 PM by TimoVJL »
May the source be with you

AW

  • Member
  • *****
  • Posts: 2440
  • Let's Make ASM Great Again!
Re: VPERMILPS Bug?!
« Reply #33 on: August 13, 2019, 05:38:52 PM »
I would bet in in moving the information from the XED text database to an Sqlite database and manipulate it from there.
Records are already parsed and separated by {}
Record fields are: ICLASS, UNAME, VERSION, CATEGORY, .... etc
It will be easy to build the Sqlite database.
Just an idea.  :biggrin:

jj2007

  • Member
  • *****
  • Posts: 9798
  • Assembler is fun ;-)
    • MasmBasic
Re: VPERMILPS Bug?!
« Reply #34 on: August 13, 2019, 06:48:38 PM »
https://www.codeproject.com/articles/7056/code-to-extract-plain-text-from-a-pdf-file

EDIT: some streams needs a bigger buffer:
size_t outsize = (streamend - streamstart)*105;

It works, kind of, but it's lightyears away from what AbleWord can extract from a Pdf.

All instructions can be found in the pdf file, the question is how to copy the tables correctly ?!

Try AbleWord.

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #35 on: August 13, 2019, 09:15:51 PM »
https://www.codeproject.com/articles/7056/code-to-extract-plain-text-from-a-pdf-file

EDIT: some streams needs a bigger buffer:
size_t outsize = (streamend - streamstart)*105;

Hi TimoVJL,

 :thumbsup: great method, golang language processes the file in the same way, here is an example of a table to be found



Here is what will be found in the text file ..
Code: [Select]
Opcode Instruction Op/

En

64-Bit

Mode

Compat/

Leg Mode

Description

F6 /5 IMUL r/m8* MV a l i d V a l i d A X AL r/m byte.

F7 /5 IMUL r/m16 MV a l i d V a l i d D X : A X AX r/m word.

F7 /5 IMUL r/m32 MV a l i d V a l i d E D X : E A X EAX r/m 32.

REX.W + F7 /5 IMUL r/m64 M Valid N.E. RDX:RAX RAX r/m 64.

0F AF / r IMUL r16, r/m16 RM Valid Valid word register word register r/m 16.

0F AF / r IMUL r32, r/m32 RM Valid Valid doubleword register doubleword register

r/m32.

REX.W + 0F AF / r IMUL r64, r/m64 RM Valid N.E. Quadword register Quadword register

r/m64 .

6B / r ib IMUL r16, r/m16, imm8 RMI Valid Valid word register r/m16 sign-extended

immediate byte.

6B / r ib IMUL r32, r/m32, imm8 RMI Valid Valid doubleword register r/m32 sign-

extended immediate byte.

REX.W + 6B / r ib IMUL r64, r/m64, imm8 RMI Valid N.E. Quadword register r/m64 sign-extended

immediate byte.

69 / r iw IMUL r16, r/m16, imm16 RMI Valid Valid word register r/m16 immediate word.

69 / r id IMUL r32, r/m32, imm32 RMI Valid Valid doubleword register r/m32 immediate

doubleword.

REX.W + 69 / r id IMUL r64, r/m64, imm32 RMI Valid N.E. Quadword register r/m64 immediate

doubleword.

Formatting is broken, but as a method it should be the perfect way. Thanks!


I would bet in in moving the information from the XED text database to an Sqlite database and manipulate it from there.
Records are already parsed and separated by {}
Record fields are: ICLASS, UNAME, VERSION, CATEGORY, .... etc
It will be easy to build the Sqlite database.
Just an idea.  :biggrin:

Hi AW,

the form of records scared me, before that I studied a number of other similar databases, it turned out that with an almost perfect form, all operand information is lost, since encoding in operands has a suitable representation for instruction decoder, in other words, we do not know anything about operands and this information is transformed into the source code of the parser in C++. I immediately noticed this form in xed, therefore, I lost all desire to search for operand descriptors in the source code.

CMPXCHG8B
Code: [Select]
{
ICLASS    : CMPXCHG8B
CPL       : 3
CATEGORY  : SEMAPHORE
EXTENSION : BASE
ISA_SET   : PENTIUMREAL
ATTRIBUTES : LOCKABLE
FLAGS     : MUST [ zf-mod ]
PATTERN   : 0x0F 0xC7 MOD[mm] MOD!=3 REG[0b001] RM[nnn] not64 IMMUNE66() MODRM() nolock_prefix
OPERANDS  : MEM0:rcw:q REG0=XED_REG_EDX:rcw:SUPP REG1=XED_REG_EAX:rcw:SUPP REG2=XED_REG_ECX:r:SUPP REG3=XED_REG_EBX:r:SUPP
PATTERN   : 0x0F 0xC7 MOD[mm] MOD!=3 REG[0b001] RM[nnn] mode64 norexw_prefix IMMUNE66() MODRM() nolock_prefix
OPERANDS  : MEM0:rcw:q REG0=XED_REG_EDX:rcw:SUPP REG1=XED_REG_EAX:rcw:SUPP REG2=XED_REG_ECX:r:SUPP REG3=XED_REG_EBX:r:SUPP
}



Maybe I'm wrong, the instruction descriptor here is MEM0:rcw:q, CMPXCHG8B m64, m64 = MEM0:rcw:q ?! I will check the rest of the instructions and see if the information is lost there .. Thank you!


https://www.codeproject.com/articles/7056/code-to-extract-plain-text-from-a-pdf-file

EDIT: some streams needs a bigger buffer:
size_t outsize = (streamend - streamstart)*105;

It works, kind of, but it's lightyears away from what AbleWord can extract from a Pdf.

All instructions can be found in the pdf file, the question is how to copy the tables correctly ?!

Try AbleWord.

Hi jj2007,

I agree that a good presentation of text from pdf helps to process it more easily according to the conditions. But from experience this text always turns out to be messy, probably due to the fact that the pdf format has its own descriptors for the location of the text  :sad:. I tried the program and it gave me an error...



I would not want to be attached to the method of transformation into text, because there will always be some kind of new text structure.  :angelic: Thank you!

TimoVJL

  • Member
  • ***
  • Posts: 476
Re: VPERMILPS Bug?!
« Reply #36 on: August 13, 2019, 09:30:52 PM »
FoxIt can export to .txt

May the source be with you

AW

  • Member
  • *****
  • Posts: 2440
  • Let's Make ASM Great Again!
Re: VPERMILPS Bug?!
« Reply #37 on: August 13, 2019, 10:11:10 PM »
Quote
Maybe I'm wrong, the instruction descriptor here is MEM0:rcw:q, CMPXCHG8B m64, m64 = MEM0:rcw:q ?! I will check the rest of the instructions and see if the information is lost there .. Thank you!
I agree, disambiguate that appears difficult. The Golang guys have done it somewhere because they show "CMPXCHG8B m64","0F C7 /1","V","V","","operand16,operand32".

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #38 on: August 13, 2019, 10:38:39 PM »
Quote
Maybe I'm wrong, the instruction descriptor here is MEM0:rcw:q, CMPXCHG8B m64, m64 = MEM0:rcw:q ?! I will check the rest of the instructions and see if the information is lost there .. Thank you!
I agree, disambiguate that appears difficult. The Golang guys have done it somewhere because they show "CMPXCHG8B m64","0F C7 /1","V","V","","operand16,operand32".

They took this data from the pdf file and did not capture avx512 since there is a different table format, but the table of any instruction looks identical, one column requires a separator between the opcode and the instruction, this can be seen from the tables in the pictures above.

I took instructions with complex encoding ..
Code: [Select]
# EMITTING VMOVAPD (VMOVAPD-512-1)
{
ICLASS:      VMOVAPD
CPL:         3
CATEGORY:    DATAXFER
EXTENSION:   AVX512EVEX
ISA_SET:     AVX512F_512
EXCEPTIONS:     AVX512-E1
REAL_OPCODE: Y
ATTRIBUTES:  MASKOP_EVEX
PATTERN:    EVV 0x28 V66 V0F MOD[0b11] MOD=3 BCRC=0 REG[rrr] RM[nnn]  VL512  W1  NOEVSR
OPERANDS:    REG0=ZMM_R3():w:zf64 REG1=MASK1():r:mskw:TXT=ZEROSTR REG2=ZMM_B3():r:zf64
IFORM:       VMOVAPD_ZMMf64_MASKmskw_ZMMf64_AVX512
}

{
ICLASS:      VMOVAPD
CPL:         3
CATEGORY:    DATAXFER
EXTENSION:   AVX512EVEX
ISA_SET:     AVX512F_512
EXCEPTIONS:     AVX512-E1
REAL_OPCODE: Y
ATTRIBUTES:  MEMORY_FAULT_SUPPRESSION MASKOP_EVEX REQUIRES_ALIGNMENT DISP8_FULLMEM
PATTERN:    EVV 0x28 V66 V0F MOD[mm] MOD!=3 REG[rrr] RM[nnn] BCRC=0 MODRM()  VL512  W1  NOEVSR  ESIZE_64_BITS() NELEM_FULLMEM()
OPERANDS:    REG0=ZMM_R3():w:zf64 REG1=MASK1():r:mskw:TXT=ZEROSTR MEM0:r:zd:f64
IFORM:       VMOVAPD_ZMMf64_MASKmskw_MEMf64_AVX512
}


# EMITTING VMOVAPD (VMOVAPD-512-2)
{
ICLASS:      VMOVAPD
CPL:         3
CATEGORY:    DATAXFER
EXTENSION:   AVX512EVEX
ISA_SET:     AVX512F_512
EXCEPTIONS:     AVX512-E1
REAL_OPCODE: Y
ATTRIBUTES:  MASKOP_EVEX
PATTERN:    EVV 0x29 V66 V0F MOD[0b11] MOD=3 BCRC=0 REG[rrr] RM[nnn]  VL512  W1  NOEVSR
OPERANDS:    REG0=ZMM_B3():w:zf64 REG1=MASK1():r:mskw:TXT=ZEROSTR REG2=ZMM_R3():r:zf64
IFORM:       VMOVAPD_ZMMf64_MASKmskw_ZMMf64_AVX512
}

This information does not say anything about the form of real operands, because presumably this information is for the decoder algorithm.  :undecided:  :sad:

Code: [Select]
xed_reg_enum_t ZMM_R3()::
mode16 | OUTREG=ZMM_R3_32()
mode32 | OUTREG=ZMM_R3_32()
mode64 | OUTREG=ZMM_R3_64()

xed_reg_enum_t ZMM_R3_32()::
REG=0 | OUTREG=XED_REG_ZMM0
REG=1 | OUTREG=XED_REG_ZMM1
REG=2 | OUTREG=XED_REG_ZMM2
REG=3 | OUTREG=XED_REG_ZMM3
REG=4 | OUTREG=XED_REG_ZMM4
REG=5 | OUTREG=XED_REG_ZMM5
REG=6 | OUTREG=XED_REG_ZMM6
REG=7 | OUTREG=XED_REG_ZMM7

xed_reg_enum_t ZMM_R3_64()::
REXRR=0 REXR=0 REG=0 | OUTREG=XED_REG_ZMM0
REXRR=0 REXR=0 REG=1 | OUTREG=XED_REG_ZMM1
REXRR=0 REXR=0 REG=2 | OUTREG=XED_REG_ZMM2
REXRR=0 REXR=0 REG=3 | OUTREG=XED_REG_ZMM3
REXRR=0 REXR=0 REG=4 | OUTREG=XED_REG_ZMM4
REXRR=0 REXR=0 REG=5 | OUTREG=XED_REG_ZMM5
REXRR=0 REXR=0 REG=6 | OUTREG=XED_REG_ZMM6
REXRR=0 REXR=0 REG=7 | OUTREG=XED_REG_ZMM7
REXRR=0 REXR=1 REG=0 | OUTREG=XED_REG_ZMM8
REXRR=0 REXR=1 REG=1 | OUTREG=XED_REG_ZMM9
REXRR=0 REXR=1 REG=2 | OUTREG=XED_REG_ZMM10
REXRR=0 REXR=1 REG=3 | OUTREG=XED_REG_ZMM11
REXRR=0 REXR=1 REG=4 | OUTREG=XED_REG_ZMM12
REXRR=0 REXR=1 REG=5 | OUTREG=XED_REG_ZMM13
REXRR=0 REXR=1 REG=6 | OUTREG=XED_REG_ZMM14
REXRR=0 REXR=1 REG=7 | OUTREG=XED_REG_ZMM15

REXRR=1 REXR=0 REG=0 | OUTREG=XED_REG_ZMM16
REXRR=1 REXR=0 REG=1 | OUTREG=XED_REG_ZMM17
REXRR=1 REXR=0 REG=2 | OUTREG=XED_REG_ZMM18
REXRR=1 REXR=0 REG=3 | OUTREG=XED_REG_ZMM19
REXRR=1 REXR=0 REG=4 | OUTREG=XED_REG_ZMM20
REXRR=1 REXR=0 REG=5 | OUTREG=XED_REG_ZMM21
REXRR=1 REXR=0 REG=6 | OUTREG=XED_REG_ZMM22
REXRR=1 REXR=0 REG=7 | OUTREG=XED_REG_ZMM23
REXRR=1 REXR=1 REG=0 | OUTREG=XED_REG_ZMM24
REXRR=1 REXR=1 REG=1 | OUTREG=XED_REG_ZMM25
REXRR=1 REXR=1 REG=2 | OUTREG=XED_REG_ZMM26
REXRR=1 REXR=1 REG=3 | OUTREG=XED_REG_ZMM27
REXRR=1 REXR=1 REG=4 | OUTREG=XED_REG_ZMM28
REXRR=1 REXR=1 REG=5 | OUTREG=XED_REG_ZMM29
REXRR=1 REXR=1 REG=6 | OUTREG=XED_REG_ZMM30
REXRR=1 REXR=1 REG=7 | OUTREG=XED_REG_ZMM31

Code: [Select]
xed_reg_enum_t ZMM_B3()::
mode16 | OUTREG=ZMM_B3_32()
mode32 | OUTREG=ZMM_B3_32()
mode64 | OUTREG=ZMM_B3_64()

xed_reg_enum_t ZMM_B3_32()::
RM=0 | OUTREG=XED_REG_ZMM0
RM=1 | OUTREG=XED_REG_ZMM1
RM=2 | OUTREG=XED_REG_ZMM2
RM=3 | OUTREG=XED_REG_ZMM3
RM=4 | OUTREG=XED_REG_ZMM4
RM=5 | OUTREG=XED_REG_ZMM5
RM=6 | OUTREG=XED_REG_ZMM6
RM=7 | OUTREG=XED_REG_ZMM7

xed_reg_enum_t ZMM_B3_64()::
REXX=0 REXB=0 RM=0 | OUTREG=XED_REG_ZMM0
REXX=0 REXB=0 RM=1 | OUTREG=XED_REG_ZMM1
REXX=0 REXB=0 RM=2 | OUTREG=XED_REG_ZMM2
REXX=0 REXB=0 RM=3 | OUTREG=XED_REG_ZMM3
REXX=0 REXB=0 RM=4 | OUTREG=XED_REG_ZMM4
REXX=0 REXB=0 RM=5 | OUTREG=XED_REG_ZMM5
REXX=0 REXB=0 RM=6 | OUTREG=XED_REG_ZMM6
REXX=0 REXB=0 RM=7 | OUTREG=XED_REG_ZMM7
REXX=0 REXB=1 RM=0 | OUTREG=XED_REG_ZMM8
REXX=0 REXB=1 RM=1 | OUTREG=XED_REG_ZMM9
REXX=0 REXB=1 RM=2 | OUTREG=XED_REG_ZMM10
REXX=0 REXB=1 RM=3 | OUTREG=XED_REG_ZMM11
REXX=0 REXB=1 RM=4 | OUTREG=XED_REG_ZMM12
REXX=0 REXB=1 RM=5 | OUTREG=XED_REG_ZMM13
REXX=0 REXB=1 RM=6 | OUTREG=XED_REG_ZMM14
REXX=0 REXB=1 RM=7 | OUTREG=XED_REG_ZMM15
REXX=1 REXB=0 RM=0 | OUTREG=XED_REG_ZMM16
REXX=1 REXB=0 RM=1 | OUTREG=XED_REG_ZMM17
REXX=1 REXB=0 RM=2 | OUTREG=XED_REG_ZMM18
REXX=1 REXB=0 RM=3 | OUTREG=XED_REG_ZMM19
REXX=1 REXB=0 RM=4 | OUTREG=XED_REG_ZMM20
REXX=1 REXB=0 RM=5 | OUTREG=XED_REG_ZMM21
REXX=1 REXB=0 RM=6 | OUTREG=XED_REG_ZMM22
REXX=1 REXB=0 RM=7 | OUTREG=XED_REG_ZMM23
REXX=1 REXB=1 RM=0 | OUTREG=XED_REG_ZMM24
REXX=1 REXB=1 RM=1 | OUTREG=XED_REG_ZMM25
REXX=1 REXB=1 RM=2 | OUTREG=XED_REG_ZMM26
REXX=1 REXB=1 RM=3 | OUTREG=XED_REG_ZMM27
REXX=1 REXB=1 RM=4 | OUTREG=XED_REG_ZMM28
REXX=1 REXB=1 RM=5 | OUTREG=XED_REG_ZMM29
REXX=1 REXB=1 RM=6 | OUTREG=XED_REG_ZMM30
REXX=1 REXB=1 RM=7 | OUTREG=XED_REG_ZMM31

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #39 on: August 14, 2019, 04:03:05 AM »
 :azn:

I made all the tables from the pdf file, the condition for the parser was at least two rows and at least 5 columns. Scrolling through the document, I did not find an exception to this rule. The structure of the tables can be studied better using Excel, the last task is to combine these tables into one, difficulties will be due to the structure of the file, the description is divided into two lines (or more), just like opcode and instruction  :eusa_boohoo:





Where can I see a full comparison of intel with amd instructions ?! Maybe here ..
https://www.amd.com/en/support/tech-docs?f%5B0%5D=tech_docs_product_type%3Aprocessor

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #40 on: August 14, 2019, 07:24:02 AM »
 :biggrin: second attempt

- added pages that are skipped at the end (wrong interval)
- double strings were assembled into one, in some places there are errors(line was added in a new column), but they are few and easy to fix manually
- opcode and instruction are on the same line

Tables have a promising look, now it would be nice to combine tables with different number of columns .. and delete the first line that describes the table title. Our table will be even better  :eusa_dance:

The table header can be taken from this file - page-589-table-1.csv (first instruction)

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #41 on: August 15, 2019, 07:44:30 AM »
 :eusa_dance:

The list of instructions is ready, a complete set of instructions from the Intel documentation. For the generator it still needs to be adapted, but this is no longer a problem.

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #42 on: August 21, 2019, 11:14:13 PM »
Hi,

I'm doing 4 operand instructions now, for the test took this instruction VBLENDPD  :angelic: 20 736 lines of code, compilation results below,

Code: [Select]
Translated Windows SDK 10.0 64 bits
windef WIN_INTERNAL manque ENDIF
mywindow2.asm: 20806 lines, 2 passes, 178 ms, 0 warnings, 0 errors
Microsoft (R) Incremental Linker Version 14.22.27905.0
Copyright (C) Microsoft Corporation.  All rights reserved.

 Directory of E:\DATA\MASM64\HJWasm\Regression

21.08.2019  14:07         1 144 554 mywindow2.asm
21.08.2019  14:58           174 592 mywindow2.exe
21.08.2019  14:58             2 058 mywindow2.map
21.08.2019  14:58           487 424 mywindow2.pdb
               4 File(s)      1 808 628 bytes
               0 Dir(s)     157 351 936 bytes free
Press any key to continue . . .

There are a lot of instructions, some events are not processed yet, so I decided to make instructions with 3 operands after 4 operands, and after that add other types of processing data, we talked about these types above.

LiaoMi

  • Member
  • ****
  • Posts: 593
Re: VPERMILPS Bug?!
« Reply #43 on: August 21, 2019, 11:50:27 PM »
 :biggrin: we love real hardcore, VBLENDVPD 331 776 lines, there are bugs in UASM

mywindow2.obj : fatal error LNK1276: invalid directive '' found; does not start with '/'
mywindow2.obj : warning LNK4209: debugging information corrupt; recompile module; linking object as if no debug info


Code: [Select]
Translated Windows SDK 10.0 64 bits
windef WIN_INTERNAL manque ENDIF
mywindow2.asm: 331845 lines, 2 passes, 1247 ms, 0 warnings, 0 errors
Microsoft (R) Incremental Linker Version 14.22.27905.0
Copyright (C) Microsoft Corporation.  All rights reserved.

mywindow2.obj : fatal error LNK1276: invalid directive '' found; does not start with '/'
mywindow2.obj : warning LNK4209: debugging information corrupt; recompile module; linking object as if no debug info

 Directory of E:\DATA\MASM64\HJWasm\Regression

21.08.2019  15:28        19 077 160 mywindow2.asm
21.08.2019  14:58             2 058 mywindow2.map
21.08.2019  15:29         4 977 664 mywindow2.obj
21.08.2019  15:29            67 584 mywindow2.pdb
               4 File(s)     24 124 466 bytes
               0 Dir(s)     134 742 016 bytes free
Press any key to continue . . .


The macro assembler did the job, but the assembly slowed down for 7 seconds ...
Code: [Select]
Microsoft (R) Macro Assembler (x64) Version 14.22.27905.0
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: mywindowML2.asm
Microsoft (R) Incremental Linker Version 14.22.27905.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Could Not Find E:\DATA\MASM64\HJWasm\Regression\*.lst
Could Not Find E:\DATA\MASM64\HJWasm\Regression\*.res

 Directory of E:\DATA\MASM64\HJWasm\Regression

21.08.2019  15:40        19 075 754 mywindowML2.asm
21.08.2019  15:41         2 755 072 mywindowML2.exe
21.08.2019  15:41             2 150 mywindowML2.map
21.08.2019  15:41         2 748 416 mywindowML2.pdb
               4 File(s)     24 581 392 bytes
               0 Dir(s)     114 884 608 bytes free
Press any key to continue . . .

The files are larger, so I uploaded to the file hosting https://mega.co.nz/#!w1Bn2AgZ!AAAAAAAAAABkZMBqwd624wAAAAAAAAAAZGTAasHetuM

AW

  • Member
  • *****
  • Posts: 2440
  • Let's Make ASM Great Again!
Re: VPERMILPS Bug?!
« Reply #44 on: August 22, 2019, 04:26:02 AM »
@LiaoMi

 :biggrin:
I don't know whether it is a UASM bug or not, I will not investigate it further, but if we remove all things that are not necessary it will build the .exe (the KISS principle).

For example it will not build with this:
\masm32\bin\UASM64 /c -win64 -Zp8 /win64 /D_WIN64 /Cp /Cx /Cu /nologo /W2 -Zi0 -Zi1 -Zi2 -Zi3 /Zd -Zf %appname%.asm

But will build with this:
\masm32\bin\UASM64 /c -win64 -Zp8 %appname%.asm