deleted
Thanks for an excellent/ detailed report!
Let's work through the issues one by one.
The first one is this annoyance around intptr_t in main.c
If we use long and forget about intptr_t.. (how it used to be once in the source) then the binary version of hjwasm works on Win7 but gives a general failure when executed on Win10...
If we use intptr_t .. it doesn't compile for some compilers like GCC ..
#ifdef __UNIX__
#if defined( intptr_t )
intptr_t fh; //fixed by ToutEnMasm intptr_t instead of long
#else
long fh; // more compatible type (linux builds etc) when intptr_t isn't valid.
#endif
#else
intptr_t fh;
#endif
This block needs to be modified to something that works with EVERY C compiler then.. suggestions welcome? :)
ALIGN3.ASO: missing warning
We intentionally removed this warning, because you would have it using align 32 as well, which was very annoying when trying to align AVX structs / data.
For this particular case I would say we need to amend the regression, as a user I would expect to align things however I see fit. [open for discussion for values > 32]?
working bottom up..
HJWASM
00000124 C5F877 vzeroall
vs
ASMC/JWASM
00000124 C5FC77 vzeroall
0000000000402004 C5 FC 77 vzeroall
0000000000402007 C5 F8 77 vzeroupper
This is what the encoding should be.. so this is a BUG.
HJWASM
000000D6 C4E37D04C101 vpermilps ymm0, ymm1, 1
vs
ASMC/JWASM
000000D6 C4E37D0CC101 vpermilps ymm0, ymm1, 1
In this case HJWASM encoding is correct and confirmed against FASM and Intel manual..
FASM = C4 E3 7D 04 C1 01
Intel Manual: VEX.256.66.0F3A.W0 04 /r ib [c4 e3 7d]= the vex portion which should be followed by 0x04.
vpsllq xmm0, xmm1, xmm2
This one is a BUG, the src/dst registers are being encoded the wrong way around.
C4E2FD190500000000 vbroadcastsd ymm0, m64
The W bit of the 3 byte vex encoding SHOULD be 0 yielding 7D not FD as the 3rd byte... bug
mov eax,HIGHWORD 80000000h appears to be leaving the top half of eax signed with 0xffff... this is wrong.
shld eax,ecx,1,2 <--- this isn't a valid instruction: SHLD eax,ecx,1 is and works ?
I've logged the above into github issues and will start fixing them.
I suggest we get them sorted and then re-run the tests, Bearing in mind that there are a few cases where hjwasm is correct and the others not !
deleted
Quoteintptr_t uintptr_t Integer type capable of holding a value converted from a void pointer and then be converted back to that type with a value that compares equal to the original pointer.
Optional: These typedefs may not be defined in some library implementations.*
Quoteintptr_t fh;
We compile hjwasm to x64 too. There have to use it?
deleted
size_t is working for me here on win7 and win10 using both Visual C and GCC 5.x builds, so for now I'm going to stick to that and see how it goes :)
Good job nidud :t
it works for me as well on windows 8.1
deleted
Excellent thanks!
I'm slowly working my way through the regression findings one by one and putting them onto the github issues page, from whence Habran and I are making our way through them in batches.. it's a bit of a process but we'll get there shortly!
Thanks for all the testing and support!
Win 10
Link problem,"corrupted object file"
ToutEnMasm, it happens because vblendvpd xmm0, xmm1,m128 is missing 4th operand,
it suppose to be vblendvpd xmm0, xmm1,m128,xmm2
It is now fixed but you have to wait until Johnsa upload it on Git.
He will let you know when ready.
"repport" should have only one "p"
Pure thing, "rapport" is much better off ;)
Where is that equal opportunity , it also has 2 "p" :(
it was a bug, so i repported it :lol:
Wasn't me :icon_eek:
I know who did it but I am not gonna tell you, no matter which CIA method you apply on me 8)
I will wait and see..
It seems there is need to declare Hjwasm as a work in progress.
There is Need also to put a stable version of jwasm or Hjwasm somewhere .
for example ,http://www.terraspace.co.uk/hjwasm.html (http://www.terraspace.co.uk/hjwasm.html)
Take piety for those who are discovering Hjwasm!.
Quote from: ToutEnMasm on February 05, 2016, 06:50:24 PM
...
There is Need also to put a stable version of jwasm or Hjwasm somewhere .
...
http://sourceforge.net/projects/jwasm/files/JWasm%20Windows%20binary/
Hi,
Git repository and binary packages have been updated on the website to include the fix for vblendvpd!
ToutEnMasm, let us know if that solves the issue.
The binary packages of hjwasm include the last release version of jwasm too (that was the main reason I kept it in the package for now - so that people could still download JWASM).
I haven't included Nidud's jwasm 2.12A (I believe he included the .while and highword fixes in that version, not sure what else changed?).
Cheers
John
I just want to remind you again that you must ad option EVEX : 1 if you want to assemble EVEX instructions
option casemap : none
option win64 : 11
option frame : auto
option STACKBASE : RSP
option EVEX : 1 ;//this line is for EVEX instructions
fatal error LNK1107: fichier non valide ou endommagé : impossible de lire à 0xAA2
without avx,32 bits prog
讲英文的请
Couldn't say more than the linker !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
fatal error LNK1107: invalid or corrupt file: cannot read at 0xAA2
Thank you Dave for translation :biggrin:
>ToutEnMasm, you have overestimated my capabilities, no matter how smart I am, I can't still make any conclusion out of the source you supplied in your post ::)
Windows 10 test of the last Hjwasm version.
Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz
Microsoft Windows 10 Famille Version: 10.0.10586
Quote
HJWasm v2.13, Feb 13 2016, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
Translated Windows SDK 10.0 32 bits
essai_sdk.asm: 51 lines, 2 passes, 405 ms, 0 warnings, 0 errors
********************** FIN *********************
Link /SUBSYSTEM:CONSOLE essai_sdk.obj
I:\TestSdk
essai_sdk.obj : fatal error LNK1107: corrupted or invalid file: unable to read à 0x1FC
????????????????????????????????????????????????
code is very simple,32 bits
.NOLIST
;RECORD64 equ 1
include sdk32.inc
.const
includelib msvcrt.lib
invalid_parameter PROTO C :DWORD, :DWORD, :DWORD, :DWORD, :DWORD
.data
invalid db "invalid parameter",0
.code
;################################################################
invalid_parameter PROC C expression:DWORD,function,file,line,pReserved
Local retour:DWORD
mov retour,1
invoke MessageBox,NULL,ADDR invalid,NULL,MB_OK
Findeinvalid_parameter:
mov eax,retour
ret
invalid_parameter endp
;################################################################
main PROC C argc:DWORD,pargv:DWORD
; eax,sizeof ZIRP ;113f8h
;pour les fonctions sécurisées sprintf_s ......
invoke _set_invalid_parameter_handler,invalid_parameter
invoke _getch
mov eax,0
ret
main endp
end
the object file is here,the error isn't random.All others source code give the same result
Where is FRAME ::)
Hi Tout,
What command line options are you using with hjwasm to create the object file?
Also can you confirm that the exact same configuration / compilation does or doesn't work with jwasm2.12a ?
Does 32bit link.exe support OMF object file?
no - you have to use a 16-bit linker for OMF format object files
LINK16.EXE
for win32, the format is COFF
There is no need of frame in 32 bits,and it isn't a reason to write a corrupted obj (bad PE file).
The prog have i have posted is perfectly compiled by this version of JWASm:
http://masm32.com/board/index.php?topic=4256.msg45375#msg45375
Don't search newbe error in the compiled,I am not one of them.
deleted
Here is what say dumpbin about the obj i have posted
Quote
Microsoft (R) COFF/PE Dumper Version 14.00.23026.0
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file essai_sdk.obj
essai_sdk.obj : warning LNK4048: invalid file format ; ignored
Summary
Explain given by objconv,the compiled option are good with other jwasm,hjwasm
OMF32 instead off COFF32
Quote
Dump of file: essai_sdk.obj, type: OMF32
Summary of records:
Record 80, Translator Header, total length 18
Record 88, Comment, total length 15
Record 88, Comment, total length 16
Record 88, Comment, total length 18
Record 88, Comment, total length 18
Record 88, Comment, total length 18
Record 88, Comment, total length 17
Record 88, Comment, total length 18
Record 88, Comment, total length 15
Record 88, Comment, total length 18
Record 88, Comment, total length 16
Record 96, List of Names, total length 44
Record 98, Segment Definition, total length 10
Record 88, Comment, total length 8
Record 98, Segment Definition, total length 10
Record 98, Segment Definition, total length 10
Record 9A, Group Definition, total length 5
Record 8C, External Names Definition, total length 63
Record 90, Public Names Definition, total length 37
Record 88, Comment, total length 7
Record A0, Enumerated Data, total length 25
Record A0, Enumerated Data, total length 71
Record 9D, Fixup.32, total length 26
Record 8A, Module End, total length 5
Local names:
Module: essai_sdk.asm
1
2 FLAT
3 CODE
4 _TEXT
5 DATA
6 _DATA
7 CONST
8 CONST
External names:
1 _MessageBoxA@16, Type 0
2 __set_invalid_parameter_handler, Type 0
3 __getch, Type 0
Public names:
_invalid_parameter, Segment _TEXT, Group FLAT, Offset 0x0, Type 0
_main, Segment _TEXT, Group FLAT, Offset 0x24, Type 0
Segment records:
Segment 1, Name _TEXT, Class CODE, Align 16, Public, 32 bit, Length 64
Overlay 1
Segment 2, Name _DATA, Class DATA, Align 16, Public, 32 bit, Length 18
Overlay 1
Segment 3, Name CONST, Class CONST, Align 16, Public, 32 bit, Length 0
Overlay 1
Group records:
Group: FLAT
Segments:
LEDATA, LIDATA, COMDAT and FIXUPP records:
LEDATA: segment _DATA, Offset 0x0, Size 0x12
LEDATA: segment _TEXT, Offset 0x0, Size 0x40
FIXUPP:
Direct 32 bit, Offset 0x12, group FLAT. Segment _DATA (T4), inline 0x0
Relatv 32 bit, Offset 0x19, frame = target. Symbol _MessageBoxA@16 (T6), inline 0x0
Direct 32 bit, Offset 0x28, group FLAT. Segment _TEXT (T4), inline 0x0
Relatv 32 bit, Offset 0x2D, frame = target. Symbol __set_invalid_parameter_handler (T6), inline 0x0
Relatv 32 bit, Offset 0x35, frame = target. Symbol __getch (T6), inline 0x0
Final explain Don't understand the JWASM constant but only HJWASM
SET HJWASM=/c /coff /nologo
The jwasm.exe provided with the pack understand JWASM
Release version seem ok,but:64 bits version debug
Fun never end :biggrin:
http://masm32.com/board/index.php?topic=3225.msg56532#msg56532
Even me can solve the issue with qWord notes and explanation!
Regards. HSE
with
Quote
;-----------
foostr TEXTEQU <xyz>
foo SIZESTR foostr
%echo @CatStr(%foo)
IF foo GT 1
echo foo GT 1
ELSE
echo should be dead code
ENDIF
foo = foo - 100 ; <--- does set asym.value3264 to -1
foo SIZESTR foostr ; <-- CreateVariable() does not zero asym.value3264, if equate already exist.
%echo @CatStr(%foo)
IF foo GT 1
echo foo GT 1
ELSE
echo should be dead code
ENDIF
foo INSTR foostr,
%echo looks nice: @CatStr(%foo)
;-----------
I get
Quote
3
foo GT 1
-4294967293
should be dead code
StatDyn.asm(47) : Error A2065: Constant expected
How to modify the CreateVariable function ,in equate.c?
Quote
struct asym *CreateVariable( const char *name, int value )
/********************************************************/
{
struct asym *sym;
DebugMsg1(( "CreateVariable(%s, %d ) enter\n", name, value ));
sym = SymSearch( name );
if( sym == NULL ) {
sym = SymCreate( name );
#if FASTPASS
//sym->issaved = FALSE;
sym->issaved = StoreState; /* v2.10 */
#endif
} else if ( sym->state == SYM_UNDEFINED ) {
sym->value3264 = 0; /* v2.13: added qWord indication H E R E <<<<<<<<<<<<<<<<<<<<<*/
sym_remove_table( &SymTables[TAB_UNDEF], (struct dsym *)sym );
sym->fwdref = TRUE;
#if FASTPASS
sym->issaved = StoreState; /* v2.10 */
#endif
} else {
sym->value3264 = 0; /* v2.13: added qWord indication H E R E <<<<<<<<<<<<<<<<<<<<<*/
if ( sym->isequate == FALSE ) {
EmitErr( SYMBOL_REDEFINITION, name );
return( NULL );
}
#if FASTPASS
/*
* v2.09: don't save variable when it is defined the first time
* v2.10: store state only when variable is changed and has been
* defined BEFORE SaveState() has been called.
*/
//if ( StoreState && sym->issaved == FALSE && sym->isdefined == TRUE ) {
if ( StoreState && sym->issaved == FALSE ) {
SaveVariableState( sym );
}
#endif
}
sym->isdefined = TRUE;
sym->state = SYM_INTERNAL;
//sym->mem_type = MT_ABS;
sym->variable = TRUE;
sym->value = value;
sym->isequate = TRUE;
return( sym );
}
Hi Yves!
Perhaps there is another way but is working.
struct asym *CreateVariable( const char *name, int value )
/********************************************************/
{
struct asym *sym;
DebugMsg1(( "CreateVariable(%s, %d ) enter\n", name, value ));
sym = SymSearch( name );
if( sym == NULL ) {
sym = SymCreate( name );
#if FASTPASS
sym->issaved = FALSE;
//sym->issaved = StoreState; /* v2.10 */
#endif
} else if ( sym->state == SYM_UNDEFINED ) {
sym->value3264 = 0; /* v2.13: added qWord indication H E R E */
//sym->uvalue = 0;
sym_remove_table( &SymTables[TAB_UNDEF], (struct dsym *)sym );
sym->fwdref = TRUE;
#if FASTPASS
sym->issaved = StoreState; /* v2.10 */
#endif
} else {
sym->value3264 = 0; /* v2.13: added qWord indication H E R E */
if ( sym->isequate == FALSE ) {
EmitErr( SYMBOL_REDEFINITION, name );
return( NULL );
}
#if FASTPASS
/*
* v2.09: don't save variable when it is defined the first time
* v2.10: store state only when variable is changed and has been
* defined BEFORE SaveState() has been called.
*/
//if ( StoreState && sym->issaved == FALSE && sym->isdefined == TRUE ) {
if ( StoreState && sym->issaved == FALSE ) {
SaveVariableState( sym );
}
#endif
}
sym->isdefined = TRUE;
sym->state = SYM_INTERNAL;
//sym->mem_type = MT_ABS;
sym->variable = TRUE;
sym->value = value;
//sym->uvalue = 0;
sym->isequate = TRUE;
return( sym );
}
/*
* CreateConstant()
* this is the worker behind EQU.
* EQU may define 3 different types of equates:
* - numeric constants (with or without "type")
* - relocatable items ( aliases )
* - text macros
* the argument may be
* - an expression which can be evaluated to a number or address
* - a text literal (enclosed in <>)
* - anything. This will also become a text literal.
*/
Thanks better result like that
Quote
3
foo GT 1
3
foo GT 1
StatDyn.asm(46) : Error A2065: Constant expected
Hi ToutEnMasm,
that bug in debugger version happens probably because of myassert()
try to build when they are isolated in the souce
Thanks HSE :t
it will be fixed in next upload but for now you can use this one to build:
struct asym *CreateVariable( const char *name, int value )
/********************************************************/
{
struct asym *sym;
DebugMsg1(( "CreateVariable(%s, %d ) enter\n", name, value ));
sym = SymSearch( name );
if( sym == NULL ) {
sym = SymCreate( name );
#if FASTPASS
//sym->issaved = FALSE;
sym->issaved = StoreState; /* v2.10 */
#endif
} else if ( sym->state == SYM_UNDEFINED ) {
sym->value3264 = 0; //fixed by HSE on qWord indication
sym_remove_table( &SymTables[TAB_UNDEF], (struct dsym *)sym );
sym->fwdref = TRUE;
#if FASTPASS
sym->issaved = StoreState; /* v2.10 */
#endif
} else {
sym->value3264 = 0; //fixed by HSE on qWord indication
if ( sym->isequate == FALSE ) {
EmitErr( SYMBOL_REDEFINITION, name );
return( NULL );
}
#if FASTPASS
/*
* v2.09: don't save variable when it is defined the first time
* v2.10: store state only when variable is changed and has been
* defined BEFORE SaveState() has been called.
*/
//if ( StoreState && sym->issaved == FALSE && sym->isdefined == TRUE ) {
if ( StoreState && sym->issaved == FALSE ) {
SaveVariableState( sym );
}
#endif
}
sym->isdefined = TRUE;
sym->state = SYM_INTERNAL;
//sym->mem_type = MT_ABS;
sym->variable = TRUE;
sym->value = value;
sym->isequate = TRUE;
return( sym );
}
It's very important that qWord's macros work properly, because they are very useful for specific purposes and, more in general, they are exploiting the amazing macro capabilities of MASM :t
Thanks. HSE
Quote
habran: "that bug in debugger version happens probably because of myassert()
try to build when they are isolated in the souce "
How can I do that ?
Hi,
We've just updated the 2.14 release binaries and code in github with the fix for CreateVariable.
John
Hi ToutEnMasm,
Use a search in VS and find the first 'myassert'
than click with right button on it and chose "Ind all references"
they already have /**/myassert, just move the '*/' to the end of line
let me know if you succeed to build without myassert, please
I have put all myassert in comment but,same error
If you google that error, you will find out that it happens to others as well.
It has to do something with Visual Studio.
ToutEnMasm, try to put in Property Pages C\C++\Preprocessor _NDEBUG
and in a linker _DEBUG
Found from where it com:
tokenize.c
Quote
static void StartComment( const char *p )
/***************************************/
{
while ( isspace( *p ) ) p++;
if ( *p == NULLC ) {
EmitError( COMMENT_DELIMITER_EXPECTED );
return;
}
ModuleInfo.inside_comment = *p++;
if( strchr( p, ModuleInfo.inside_comment ) )
ModuleInfo.inside_comment = NULLC;
return;
}
the assertion failed using isspace say it's a bug using bad char to find the zero.
recommended method is to use len>> if len = 0
http://stackoverflow.com/questions/22952087/debug-assertion-failed-error-with-null-terminated-character-array
Great find :t
Did you find solution for that?
The line is a "comment µ",I let you search why there is a bug here in debug mode ?!.
I try my best proc this time :biggrin:
Quote
.686P
.MMX
.XMM
.model flat, stdcall
option casemap :none
ExitProcess PROTO :DWORD
includelib kernel32.lib
.code
start:
comment q
rien
q
invoke ExitProcess,0
end start
result
Quote
bug_jwasm.asm: 17 lines, 2 passes, 1 ms, 0 warnings, 0 errors
32 items in symbol table, expected 32
max items in a line=1, lines with 0/1/<=5/<=10 items=7977/32/0/0,
1937 items in resw table, max items/line=7 [0=695 1=695 357 105 35 8 2 3]
invokation CATSTR=0 SUBSTR=0 SIZESTR=0 INSTR=0 EQU(text)=0
lines read(files)/processed in pass one: 17 / 17
invokations: PreprocessLine=30/24/24, Tokenize=33/0
memory used: 408 kB
The debug version don't accept ascii char > 7Eh 126d ~
Thanks ToutEnMasm :t
I will look at it ASAP
Hallo,
what does this message mean?
HJWasm v2.14, Jun 9 2016, Masm-compatible assembler.
Portions Copyright (c) 1992-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
Translated Windows SDK 8.1 64 bits
Win64Test.asm: 575 lines, 3 passes, 9 ms, 0 warnings, 0 errors
Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
Win64Test.obj : error LNK2017: 'ADDR32' relocation to '_insn' invalid without /LARGEADDRESSAWARE:NO
Win64Test.obj : error LNK2017: 'ADDR32' relocation to '_insn' invalid without /LARGEADDRESSAWARE:NO
Win64Test.obj : error LNK2017: 'ADDR32' relocation to '_insn' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors
Press any key to continue . . .
Here is an example of code that I use
.if rax
xor rbx, rbx
.WHILE rbx < rax
invoke printf, offset _Dis, _insn[rbx].address, _insn[rbx].mnemonic, _insn[rbx].op_str;
inc rbx
.ENDW
.else
nop
.endifDescription
QuoteThe /LARGEADDRESSAWARE option tells the linker that the application can handle addresses larger than 2 gigabytes. In the 64-bit compilers, this option is enabled by default. In the 32-bit compilers, /LARGEADDRESSAWARE:NO is enabled if /LARGEADDRESSAWARE is not otherwise specified on the linker line.
If an application was linked with /LARGEADDRESSAWARE, DUMPBIN /HEADERS will display information to that effect.
This is required? After all, I do not break the boundaries of memory.
Regards!
Hi,
When doing 64bit coding you cannot use OFFSET to obtain the address of a variable (as you would in 32bit as an argument to invoke etc).
To obtain an address you should use LEA, or for an argument to invoke you can use the ADDR operator.
For example:
lea rdi,myBuffer ; get the address of myBuffer into RDI.
invoke myProc, ADDR myBuffer2, myBuffer
The warning relating to largeaddressaware is telling you that you're trying to create a 64bit image that is using 32bit style relocations (for runtime loading by the OS).
Quote from: johnsa on July 03, 2016, 08:12:29 PM
Hi,
When doing 64bit coding you cannot use OFFSET to obtain the address of a variable (as you would in 32bit as an argument to invoke etc).
To obtain an address you should use LEA, or for an argument to invoke you can use the ADDR operator.
For example:
lea rdi,myBuffer ; get the address of myBuffer into RDI.
invoke myProc, ADDR myBuffer2, myBuffer
The warning relating to largeaddressaware is telling you that you're trying to create a 64bit image that is using 32bit style relocations (for runtime loading by the OS).
Hallo,
the difficulty was not offset, but instead a pointer that has not been properly defined. With Offset is also interesting, since I did not notice the difference when assembled program. Thanks for the help :t
Regards
Quote from: johnsa on July 03, 2016, 08:12:29 PM
When doing 64bit coding you cannot use OFFSET to obtain the address of a variable (as you would in 32bit as an argument to invoke etc).
There are 64Bit offsets as well JWASM and ml64 handle them (either by using MOV or making them RIP-relative). I guess you mean the problem when using offsets/labels with SIB-Addressing, which is not possible** because these kind of addressing is not RIP-relative.
regards
**except if using LARGEADDRESSAWARE:NO, which tells that that our image is in [0, 2
32) thus 64bit offsets could be truncate to 32bit.
Hello, please, can you check this about rip addressing.
This is output from yasm and as on other side of moon.
as output
0000000000000000 <_start>:
0: 8a 05 08 00 00 00 mov al,BYTE PTR [rip+0x8] # e <_start+0xe>
6: 66 8b 05 00 00 00 00 mov ax,WORD PTR [rip+0x0] # d <_start+0xd>
d: 8b 05 00 00 00 00 mov eax,DWORD PTR [rip+0x0] # 13 <_start+0x13>
13: 48 8b 05 08 00 00 00 mov rax,QWORD PTR [rip+0x8] # 22 <_start+0x22>
The same code with adjustment using hjwasm:
hjwasm output
0000000000000000 <.text>:
0: 67 8a 05 08 00 00 00 mov al,BYTE PTR [eip+0x8] # 0xf
7: 67 66 8b 05 00 00 00 mov ax,WORD PTR [eip+0x0] # 0xf
e: 00
f: 67 8b 05 00 00 00 00 mov eax,DWORD PTR [eip+0x0] # 0x16
16: 67 48 8b 05 08 00 00 mov rax,QWORD PTR [eip+0x8] # 0x26
1d: 00
Thanks.
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
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)
source code sir
.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
.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
#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
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.
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...
Thanks qWORD :t
That fixes the problem indeed :biggrin:
It will be changed in next release.
Anyway, we will recheck all possible RIP-relative instruction formats
Quote from: qWord on July 09, 2016, 01:45:16 AM
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.
Quote from: johnsa on July 09, 2016, 07:18:42 PM
Quote from: qWord on July 09, 2016, 01:45:16 AM
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.