Minor release update,
1) Few small bug-fixes..(mainly for system-v)
2) Added a new Linux example Lin64_4 which uses glibc, creates a socket server, accepts incoming connections and echos out the response.
3) The new handling of simd type checking is in, this checks local and global variables based on their "size" as opposed to their type.
This allows the use of many forms of data declaration (bytes, words, dwords, structs, real4 etc) as long as the size matches there will be no operand error reported when used with simd instructions.
4) For the following instructions: movaps, vmovaps, movdqa, vmovdqa, movapd, vmovapd automatic alignment checking is performed when referencing a global variable. If the variable is not aligned to the correct size (16/32/64 for xmm,ymm,zmm respectively) a warning will be issued. I've been caught by that a few times after re-arranging variables and forgetting to update an align 16 and you only then pick it up with a run-time crash, so this might help spot those at assemble-time.
5) Macro library has been initially extended into two versions, one for 32bit and one for 64bit as work will continue to grow it for both.
Cheers,
John
Quote from: johnsa on June 08, 2017, 05:23:40 AM
4) For the following instructions: movaps, vmovaps, movdqa, vmovdqa, movapd, vmovapd automatic alignment checking is performed when
Include also this one: movntdqa
Hi JOHNSA,
Thanks for new Linux example.
I hope someday I'll have more time for my hobbies and personal interests.
I'm busy adding even more to it, including a sockets.inc, libc.inc (starting point) and system.inc which all the code for creating threads, using mmap, getting date/time etc etc.
It should be quite a sound base to build. My hope would be one day to create a Linux equivalent to WinInc.
Packages updated. Added (v)movntdqa, fixed a bug with mem,xmm size check and extended the Lin64_4 sample even further.
It now includes several inc files as a foundation for using syscalls, date/time, libc, sockets and some low level functions for using mmap, munmap and creating threads.
John
Quote from: johnsa on June 09, 2017, 05:31:38 AM
Packages updated. Added (v)movntdqa, fixed a bug with mem,xmm size check and extended the Lin64_4 sample even further.
It now includes several inc files as a foundation for using syscalls, date/time, libc, sockets and some low level functions for using mmap, munmap and creating threads.
John
I have the following comments:
1) The instruction "mulps" continues to produce an error when used without the XMMWORD ptr specifier
2) When building for x64 with the -pe switch I get an error and no executable. The help file says "-pe PE binary file, 32/64-bit"
3) For x64, in almost every case I noticed that RIP-relative addressing is used for data reference. The only exception I saw is when using "offset" (for example mov rax, offset mydata). Is there any way to force absolute addressing when we want that? As you know some assemblers have it. I did not check how MASM behaves in this respect but I read that it is a bit messy as well.
Cheers :biggrin:
Quote from: aw27 on June 12, 2017, 02:04:25 AM
3) For x64, in almost every case I noticed that RIP-relative addressing is used for data reference. The only exception I saw is when using "offset"
Just curious: Where would you prefer absolute addressing?
0000000140001013 | 48 BA 44 16 00 40 01 00 00 00 | movabs rdx, 140001644 |
000000014000101D | 48 8D 0D 20 06 00 00 | lea rcx, qword ptr ds:[140001644] |
Quote from: jj2007 on June 12, 2017, 02:46:15 AM
Quote from: aw27 on June 12, 2017, 02:04:25 AM
3) For x64, in almost every case I noticed that RIP-relative addressing is used for data reference. The only exception I saw is when using "offset"
Just curious: Where would you prefer absolute addressing?
0000000140001013 | 48 BA 44 16 00 40 01 00 00 00 | movabs rdx, 140001644 |
000000014000101D | 48 8D 0D 20 06 00 00 | lea rcx, qword ptr ds:[140001644] |
Something like:
lea rax, abs mydata
would be more clear for me. This is actually similar to YASM/NASM I think.
lea rcx, qword ptr ds:[140001644] |
Using segment registers in a flat model in the 21st century sucks a bit (unless you are addressing from the FS or GS segments, of course ):
The only options I can think of that are presently supported would be:
mov rax,offset myVariable
mov rax,FLAT:[20h] ;for a constant addr.
to produce a non-rip relative address in 64bit.
I would think that OFFSET and ABS would be synonymous in this context? If so we could just alias it.
I think lea would always be rip relative even in nasm ?
I remember FASM has "virtual" for things like this (which I don't quite understand myself). It would be a nice addition to UASM or even MASM32.
Quote from: aw27 on June 12, 2017, 03:03:59 AM
Using segment registers in a flat model in the 21st century sucks a bit (unless you are addressing from the FS or GS segments, of course ):
I think it's two centuries old already. If you're lucky to live that long, it's still be there the next century. It looks funky, anyway.
Quote from: johnsa on June 13, 2017, 04:19:45 AM
The only options I can think of that are presently supported would be:
mov rax,offset myVariable
mov rax,FLAT:[20h] ;for a constant addr.
to produce a non-rip relative address in 64bit.
I would think that OFFSET and ABS would be synonymous in this context? If so we could just alias it.
I think lea would always be rip relative even in nasm ?
Probably, it is better just leave things as they are for now. I am also suspicious that the linker has some responsibility in the outcome.
It is possible to use instructions like inc, dec, mov for a constant address and it will come in next release, however, it is a hard job and takes time. We will see which other instructions will be able to work in this mode
This was assembled with next UASM release:
220: inc byte ptr [0C2100Dh]
00007ff6d556109a FE 04 25 0D 10 C2 00 inc byte ptr [0xc2100d]
221: dec byte ptr [0C2100Dh]
00007ff6d55610a1 FE 0C 25 0D 10 C2 00 dec byte ptr [0xc2100d]
222: mov [0C2100Dh],eax
00007ff611d510af 89 04 25 0D 10 C2 00 mov dword ptr [0xc2100d], eax
BTW ml64 is capable to assemble these instructions as well
we have got also fixed instructions like mulps and sisters
Quote from: habran on June 14, 2017, 06:15:34 AM
It is possible to use instructions like inc, dec, mov for a constant address and it will come in next release, however, it is a hard job and takes time. We will see which other instructions will be able to work in this mode
This was assembled with next UASM release:
220: inc byte ptr [0C2100Dh]
00007ff6d556109a FE 04 25 0D 10 C2 00 inc byte ptr [0xc2100d]
221: dec byte ptr [0C2100Dh]
00007ff6d55610a1 FE 0C 25 0D 10 C2 00 dec byte ptr [0xc2100d]
222: mov [0C2100Dh],eax
00007ff611d510af 89 04 25 0D 10 C2 00 mov dword ptr [0xc2100d], eax
BTW ml64 is capable to assemble these instructions as well
we have got also fixed instructions like mulps and sisters
I was looking more for a way to replace the following 2 instructions with just 1.
.data
myVal qword 0;
.code
mov rax, offset myVal
inc qword ptr [rax]
All these instructions will be available in next release but please be patient, they don't give up to easy ;) :
Quote
inc dword ptr [0C2100Dh]
inc word ptr [0C2100Dh]
inc byte ptr [0C2100Dh]
dec qword ptr [0C2100Dh]
dec dword ptr [0C2100Dh]
dec word ptr [0C2100Dh]
dec byte ptr [0C2100Dh]
mov [00007FF6601D1010h],rax
mov [00007FF8807FF660h],eax
mov [00007FF8807FF660h],ax
mov [00007FF8807FF660h],al
mov rax,[00007FF6601D1010h]
mov eax,[00007FF6601D1010h]
mov ax,[00007FF6601D1010h]
mov al,[00007FF6601D1010h]
mov rax,[0C2100Dh]
mov eax,[0C2100Dh]
mov ax,[0C2100Dh]
mov al,[0C2100Dh]
mov [0C2100Dh],rax
mov [0C2100Dh],eax
mov [0C2100Dh],ax
mov [0C2100Dh],al
ml64 is accepting all these instructions but newer versions
include \Masm32\MasmBasic\Res\JBasic.inc
myVal qword 0
Init ; OPT_64 1
PrintLine Chr$("This code was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format")
@inc_s:
inc myVal
@inc_endp:
@inc_rax_s:
mov rax, offset myVal
inc qword ptr [rax]
@inc_rax_endp:
CodeSize @inc
CodeSize @inc_rax
Inkey Str$("myVal=%i", myVal)
EndOfCode
Output:
This code was assembled with HJWasm32 in 64-bit format
7 bytes for @inc
13 bytes for @inc_rax
myVal=2
So where is the problem? Why is inc qword ptr [rax] better?
Quote from: jj2007 on June 14, 2017, 07:44:31 PM
So where is the problem? Why is inc qword ptr [rax] better?
Who told is better in size? IP-Relative addresses are shorter, otherwise will not be chosen as default. If you have an address very far away beyond 32 bit range, you need to reach it by an absolute address.
My example should have been
mov rax, myAddress ; address stored in a variable
inc qword ptr [rax]
You should be aware that INC in IP-Relative addressing can be used only for DW0RD addresses, so:
inc qword ptr [8C2100Dh] ; this is OK
inc qword ptr [80C2100Dh] ; error A2070: invalid instruction operands
MOV can be used for 64 bit IP-Relative addresses.
Quote from: aw27 on June 15, 2017, 04:13:36 AMIf you have an address very far away beyond 32 bit range, you need to reach it by an absolute address.
How could this happen? Just curious, really, it's not a provocative question. Can the data and the code sections be more than 32 bits apart?
check this:
Quote
inc qword ptr [0C2100Dh]
inc dword ptr [0C2100Dh]
inc word ptr [0C2100Dh]
inc byte ptr [0C2100Dh]
dec qword ptr [0C2100Dh]
dec dword ptr [0C2100Dh]
dec word ptr [0C2100Dh]
dec byte ptr [0C2100Dh]
mov [00007FF6601D1010h],rax
mov [00007FF8807FF660h],eax
mov [00007FF8807FF660h],ax
mov [00007FF8807FF660h],al
mov rax,[00007FF6601D1010h]
mov eax,[00007FF6601D1010h]
mov ax,[00007FF6601D1010h]
mov al,[00007FF6601D1010h]
mov rax,[0C2100Dh]
mov eax,[0C2100Dh]
mov ax,[0C2100Dh]
mov al,[0C2100Dh]
mov [0C2100Dh],rax
mov [0C2100Dh],eax
mov [0C2100Dh],ax
mov [0C2100Dh],al
add [0C2100Dh],rax
add [0C2100Dh],eax
add [0C2100Dh],ax
add [0C2100Dh],al
sub [0C2100Dh],rax
sub [0C2100Dh],eax
sub [0C2100Dh],ax
sub [0C2100Dh],al
add rax,[0C2100Dh]
add eax,[0C2100Dh]
add ax,[0C2100Dh]
add al,[0C2100Dh]
sub rax,[0C2100Dh]
sub eax,[0C2100Dh]
sub ax,[0C2100Dh]
sub al,[0C2100Dh]
ml64 assembles to:
00007FF6A4461010 48 FF 04 25 0D 10 C2 00 inc qword ptr [0C2100Dh]
00007FF6A4461018 FF 04 25 0D 10 C2 00 inc dword ptr [0C2100Dh]
00007FF6A446101F 66 FF 04 25 0D 10 C2 00 inc word ptr [0C2100Dh]
00007FF6A4461027 FE 04 25 0D 10 C2 00 inc byte ptr [0C2100Dh]
00007FF6A446102E 48 FF 0C 25 0D 10 C2 00 dec qword ptr [0C2100Dh]
00007FF6A4461036 FF 0C 25 0D 10 C2 00 dec dword ptr [0C2100Dh]
00007FF6A446103D 66 FF 0C 25 0D 10 C2 00 dec word ptr [0C2100Dh]
00007FF6A4461045 FE 0C 25 0D 10 C2 00 dec byte ptr [0C2100Dh]
00007FF6A446104C 48 A3 10 10 1D 60 F6 7F 00 00 mov qword ptr [00007FF6601D1010h],rax
00007FF6A4461056 A3 60 F6 7F 80 F8 7F 00 00 mov dword ptr [00007FF8807FF660h],eax
00007FF6A446105F 66 A3 60 F6 7F 80 F8 7F 00 00 mov word ptr [00007FF8807FF660h],ax
00007FF6A4461069 A2 60 F6 7F 80 F8 7F 00 00 mov byte ptr [00007FF8807FF660h],al
00007FF6A4461072 48 A1 10 10 1D 60 F6 7F 00 00 mov rax,qword ptr [00007FF6601D1010h]
00007FF6A446107C A1 10 10 1D 60 F6 7F 00 00 mov eax,dword ptr [00007FF6601D1010h]
00007FF6A4461085 66 A1 10 10 1D 60 F6 7F 00 00 mov ax,word ptr [00007FF6601D1010h]
00007FF6A446108F A0 10 10 1D 60 F6 7F 00 00 mov al,byte ptr [00007FF6601D1010h]
00007FF6A4461098 48 8B 04 25 0D 10 C2 00 mov rax,qword ptr [0C2100Dh]
00007FF6A44610A0 8B 04 25 0D 10 C2 00 mov eax,dword ptr [0C2100Dh]
00007FF6A44610A7 66 8B 04 25 0D 10 C2 00 mov ax,word ptr [0C2100Dh]
00007FF6A44610AF 8A 04 25 0D 10 C2 00 mov al,byte ptr [0C2100Dh]
00007FF6A44610B6 48 89 04 25 0D 10 C2 00 mov qword ptr [0C2100Dh],rax
00007FF6A44610BE 89 04 25 0D 10 C2 00 mov dword ptr [0C2100Dh],eax
00007FF6A44610C5 66 89 04 25 0D 10 C2 00 mov word ptr [0C2100Dh],ax
00007FF6A44610CD 88 04 25 0D 10 C2 00 mov byte ptr [0C2100Dh],al
00007FF6A44610D4 48 01 04 25 0D 10 C2 00 add qword ptr [0C2100Dh],rax
00007FF6A44610DC 01 04 25 0D 10 C2 00 add dword ptr [0C2100Dh],eax
00007FF6A44610E3 66 01 04 25 0D 10 C2 00 add word ptr [0C2100Dh],ax
00007FF6A44610EB 00 04 25 0D 10 C2 00 add byte ptr [0C2100Dh],al
00007FF6A44610F2 48 29 04 25 0D 10 C2 00 sub qword ptr [0C2100Dh],rax
00007FF6A44610FA 29 04 25 0D 10 C2 00 sub dword ptr [0C2100Dh],eax
00007FF6A4461101 66 29 04 25 0D 10 C2 00 sub word ptr [0C2100Dh],ax
00007FF6A4461109 28 04 25 0D 10 C2 00 sub byte ptr [0C2100Dh],al
00007FF6A4461110 48 03 04 25 0D 10 C2 00 add rax,qword ptr [0C2100Dh]
00007FF6A4461118 03 04 25 0D 10 C2 00 add eax,dword ptr [0C2100Dh]
00007FF6A446111F 66 03 04 25 0D 10 C2 00 add ax,word ptr [0C2100Dh]
00007FF6A4461127 02 04 25 0D 10 C2 00 add al,byte ptr [0C2100Dh]
00007FF6A446112E 48 2B 04 25 0D 10 C2 00 sub rax,qword ptr [0C2100Dh]
00007FF6A4461136 2B 04 25 0D 10 C2 00 sub eax,dword ptr [0C2100Dh]
00007FF6A446113D 66 2B 04 25 0D 10 C2 00 sub ax,word ptr [0C2100Dh]
Quote from: habran on June 15, 2017, 05:58:52 AM
You should be aware that INC in IP-Relative addressing can be used only for DW0RD addresses, so:
inc qword ptr [8C2100Dh] ; this is OK
inc qword ptr [80C2100Dh] ; error A2070: invalid instruction operands
MOV can be used for 64 bit IP-Relative addresses.
In RIP-relative addressing the offset, or displacement, is limited to 32-bit. That's why we need absolute addressing in some cases.
Quote from: jj2007 on June 15, 2017, 06:24:12 AM
Quote from: aw27 on June 15, 2017, 04:13:36 AMIf you have an address very far away beyond 32 bit range, you need to reach it by an absolute address.
How could this happen? Just curious, really, it's not a provocative question. Can the data and the code sections be more than 32 bits apart?
Not provocative at all, you are just curious. :lol:
64-bit Windows applications have 8 terabytes of virtual memory address space, from 0x00000000000 through 0x7FFFFFFFFFF
Try to use a memory mapped files or VirtualAlloc to have pointers to far away memory.
Quote from: aw27 on June 15, 2017, 03:11:29 PM64-bit Windows applications have 8 terabytes of virtual memory address space, from 0x00000000000 through 0x7FFFFFFFFFF
Try to use a memory mapped files or VirtualAlloc to have pointers to far away memory.
Yes, that is known. But we are talking about RIP-relative addressing, i.e. current value of CODE as in RIP vs position in DATA section. Both memory mapped files and VirtualAlloc return pointers that you will store in a register. If I am wrong, please explain, I want to understand this properly.
Quote from: jj2007 on June 15, 2017, 05:02:42 PM
Yes, that is known. But we are talking about RIP-relative addressing, i.e. current value of CODE as in RIP vs position in DATA section. Both memory mapped files and VirtualAlloc return pointers that you will store in a register. If I am wrong, please explain, I want to understand this properly.
OK then :t
Something that is wrong and I think that it is what habran is working on is this:
myfunc proc
mov rax, 07FFFFh
mov rdx, [07FFFFh]
ret
myfunc endp
Assembles in UASM to:
00000001`3fac1025 48c7c0ffff0700 mov rax,7FFFFh
00000001`3fac102c 48c7c2ffff0700 mov rdx,7FFFFh
00000001`3fac1037 c3 ret
and in MASM to:
00000001`3f9d1021 48c7c0ffff0700 mov rax,7FFFFh
00000001`3f9d1028 488b1425ffff0700 mov rdx,qword ptr [7FFFFh]
00000001`3f9d1030 c3 ret
That is correct, but not only 32 bit addresses, 64 bit as well, as you can see here:
00007FF6A446104C 48 A3 10 10 1D 60 F6 7F 00 00 mov qword ptr [00007FF6601D1010h],rax
00007FF6A4461056 A3 60 F6 7F 80 F8 7F 00 00 mov dword ptr [00007FF8807FF660h],eax
00007FF6A446105F 66 A3 60 F6 7F 80 F8 7F 00 00 mov word ptr [00007FF8807FF660h],ax
00007FF6A4461069 A2 60 F6 7F 80 F8 7F 00 00 mov byte ptr [00007FF8807FF660h],al
00007FF6A4461072 48 A1 10 10 1D 60 F6 7F 00 00 mov rax,qword ptr [00007FF6601D1010h]
00007FF6A446107C A1 10 10 1D 60 F6 7F 00 00 mov eax,dword ptr [00007FF6601D1010h]
00007FF6A4461085 66 A1 10 10 1D 60 F6 7F 00 00 mov ax,word ptr [00007FF6601D1010h]
00007FF6A446108F A0 10 10 1D 60 F6 7F 00 00 mov al,byte ptr [00007FF6601D1010h]
RIP relative addressing accepts only DWORD displacement
IP addressing is giving you access to 64 bit addresses without additional index or base register, so if you know what are you doing it could be useful, especially for writing debugger 8)
However, only MOV is able to access 64 bit addresses, anyway, don't look a gift horse in the mouth :P
Quote from: habran on June 15, 2017, 09:14:03 PM
That is correct, but not only 32 bit addresses, 64 bit as well, as you can see here:
00007FF6A446104C 48 A3 10 10 1D 60 F6 7F 00 00 mov qword ptr [00007FF6601D1010h],rax
00007FF6A4461056 A3 60 F6 7F 80 F8 7F 00 00 mov dword ptr [00007FF8807FF660h],eax
00007FF6A446105F 66 A3 60 F6 7F 80 F8 7F 00 00 mov word ptr [00007FF8807FF660h],ax
00007FF6A4461069 A2 60 F6 7F 80 F8 7F 00 00 mov byte ptr [00007FF8807FF660h],al
00007FF6A4461072 48 A1 10 10 1D 60 F6 7F 00 00 mov rax,qword ptr [00007FF6601D1010h]
00007FF6A446107C A1 10 10 1D 60 F6 7F 00 00 mov eax,dword ptr [00007FF6601D1010h]
00007FF6A4461085 66 A1 10 10 1D 60 F6 7F 00 00 mov ax,word ptr [00007FF6601D1010h]
00007FF6A446108F A0 10 10 1D 60 F6 7F 00 00 mov al,byte ptr [00007FF6601D1010h]
RIP relative addressing accepts only DWORD displacement
IP addressing is giving you access to 64 bit addresses without additional index or base register, so if you know what are you doing it could be useful, especially for writing debugger 8)
However, only MOV is able to access 64 bit addresses, anyway, don't look a gift horse in the mouth :P
x64 Architecture - Addressing Modes, as explained by Microsoft:
A special form of the mov instruction has been added for 64-bit immediate constants or constant addresses. For all other instructions, immediate constants or constant addresses are still 32 bits.
So, there is no room for anything else. :eusa_naughty: