UASM 2.36 Update Release

[johnsa]

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

[aw27]

4) For the following instructions: movaps, vmovaps, movdqa, vmovdqa, movapd, vmovapd automatic alignment checking is performed when

Include also this one: movntdqa

[GoneFishing]

Hi JOHNSA,
Thanks for  new Linux example.
I hope someday I'll have more time for my hobbies and personal interests.

[johnsa]

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.

[johnsa]

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

[aw27]

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

[jj2007]

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?

Code: [Select]

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]  |

[aw27]

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?

Code: [Select]

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 ):

[johnsa]

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 ?

[coder]

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.


 

[coder]

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.
 

[aw27]

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.

[habran]

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:

Code: [Select]

   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

[aw27]

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:

Code: [Select]

   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]

[habran]

All these instructions will be available in next release but please be patient, they don't give up to easy ;) :

    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