Bug repport

[habran]

Sir mineiro,
67h is a prefix for 32 bite, as you can see it uses eip instead of rip
Can you post your source code you are using please

[qWord]

I guess the problem is the definition of OP_RIP, which cause memory_operand() to set CodeInfo->prefix.adrsiz = TRUE.
There is also a bug in set_rm_sib() that allows to use index registers in (explicit) RIP-relative addresses (e.g. mov eax,[rip+rax*2]).


BTW: comments like "//ADDED BY HABRAN" are not really useful ;)
BTW2: floating point literals as operands were already implemented in JWasm (Issue #22)

[mineiro]

source code sir

Code: [Select]

.x64
.code
public _start
_start:
mov al,byte ptr [rip+8]
mov ax,word ptr [rip+0]
mov eax,dword ptr [rip+0]
mov rax,qword ptr [rip+8]
end
command line:
hjwasm -10 -nologo -elf64 -Fo=quiz.o quiz.hjwasm

--edited-- Added other example, maybe can help a bit

Code: [Select]

.x64
.code
public _start
_start:
lea rbx, [rip] ; RBX now points to the next instruction
nop
cmp byte ptr [rbx], 90h ; Should be equal!

;0000000000000000 <_start>:
;   0:   67 48 8d 1d 00 00 00    lea    rbx,[eip+0x0]        # 8 <_start+0x8>
;   7:   00
;   8:   90                      nop
;   9:   80 3b 90                cmp    BYTE PTR [rbx],0x90
This is as source used and disassembled code

Code: [Select]

#command line: as -o quiz.o quiz.asm
.intel_syntax noprefix
.text
.global _start

_start:
lea rbx, [rip] # RBX now points to the next instruction
nop
cmp byte ptr [rbx], 0x90 # Should be equal!

#0000000000000000 <_start>:
#   0:   48 8d 1d 00 00 00 00    lea    rbx,[rip+0x0]        # 7 <_start+0x7>
#   7:   90                      nop
#   8:   80 3b 90                cmp    BYTE PTR [rbx],0x90


[habran]

Thanks mineiro, it looks like RIP instruction is creating 32 bite code, that is probably unwanted byproduct while implementing EVEX instructions.
At this moment I am focused on implementing VECTORCALL in hjwasm, as soon as I finish it I will rework RIP relative instructions.

qWORD, "//ADDED BY HABRAN" was an atavism from the time while I was working parallel wit Japheth on JWasm
It is still useful sometimes because it shows me where I have changed existing code.
If that bothers you, I apologize for inconvenience. 

[qWord]

Changing the definition of OP_RIP to OP_R64 in operands.h and OP_RSPEC to OP_RIP in special.h seems to solve the problem...

[habran]

Thanks qWORD :t
That fixes the problem indeed
It will be changed in next release.
Anyway, we will recheck all possible RIP-relative instruction formats

[johnsa]

I guess the problem is the definition of OP_RIP, which cause memory_operand() to set CodeInfo->prefix.adrsiz = TRUE.
There is also a bug in set_rm_sib() that allows to use index registers in (explicit) RIP-relative addresses (e.g. mov eax,[rip+rax*2]).


BTW: comments like "//ADDED BY HABRAN" are not really useful ;)
BTW2: floating point literals as operands were already implemented in JWasm (Issue #22)

With regards to the BTW2, the floating point literal changes we're making are:

ability to use floating point literals in invoke without need macros like FP4, FP8 and ability to use them directly with fp and simd instructions where a memory address is expected (will produce a warning that you can switch off)
so that you can do:
vmovss xmm0,2.3

and if you happen to use 2.3 again later hjwasm will re-use the same anonymous variable (unlike fp4/fp8 macros)..

At present invoke will generate the following if you use a direct floating point literal:
000000013F599188 B8 00 00 80 3F       mov         eax,3F800000h 
000000013F59918D 66 0F 6E C0          movd        xmm0,eax

which I personally think would be better as the above anonymous variable, one less instruction in the generation of the invoke and possible re-use of the literal value.

[johnsa]

I guess the problem is the definition of OP_RIP, which cause memory_operand() to set CodeInfo->prefix.adrsiz = TRUE.
There is also a bug in set_rm_sib() that allows to use index registers in (explicit) RIP-relative addresses (e.g. mov eax,[rip+rax*2]).


BTW: comments like "//ADDED BY HABRAN" are not really useful ;)
BTW2: floating point literals as operands were already implemented in JWasm (Issue #22)

With regards to the BTW2, the floating point literal changes we're making are:

ability to use floating point literals in invoke without need macros like FP4, FP8 and ability to use them directly with fp and simd instructions where a memory address is expected (will produce a warning that you can switch off)
so that you can do:
vmovss xmm0,2.3

and if you happen to use 2.3 again later hjwasm will re-use the same anonymous variable (unlike fp4/fp8 macros)..

At present invoke will generate the following if you use a direct floating point literal:
000000013F599188 B8 00 00 80 3F       mov         eax,3F800000h 
000000013F59918D 66 0F 6E C0          movd        xmm0,eax

which I personally think would be better as the above anonymous variable, one less instruction in the generation of the invoke and possible re-use of the literal value.

Just in case anyone was interested what happened here, after a bunch of performance profiling I decided not to change this as the mov eax/movd combination was considerably faster than memory read, so it remained as is.