UASM 2.41 Release + WinInc 2.09

[jj2007]

If you'd like to test it out

Works perfect with my big sources and is even a tick faster :t

[habran]

That is a good news JJ, thank you for testing :t
aw27, I have already succeeded to make 32 bit work with 64 bit RECORDS, now I am trying to conjure inline stuff ::)

[aw27]

aw27, I have already succeeded to make 32 bit work with 64 bit RECORDS, now I am trying to conjure inline stuff ::)

What is inline staff? It appears that was something you did yesterday, i.e, mov  someDouble2.parts, _FP64<0, 400h, 999999999999Ah>

[habran]

Yes

Code Select Expand


    44:     movq   cobalt.rc,COLOR<224, 225, 226, 227, 228, 229, 230, 231>
00CC1035 68 E3 E2 E1 E0       push        0E0E1E2E3h 
00CC103A 68 E7 E6 E5 E4       push        0E4E5E6E7h 
00CC103F F3 0F 7E 2C 24       movq        xmm5,mmword ptr [esp] 
00CC1044 83 C4 08             add         esp,8 
00CC1047 66 0F D6 2D 19 50 CC 00 movq        mmword ptr ds:[0CC5019h],xmm5 



[habran]

It already works all but I have unwanted additional : movq        mmword ptr ds:[385019h],xmm5
it doesnt do any damage but it shouldn't do it at the beginning and at the end:

Code Select Expand


    45:     movq   cobalt.rc,COLOR<224, 225, 226, 227, 228, 229, 230, 231>
0038102D 66 0F D6 2D 19 50 38 00 movq        mmword ptr ds:[385019h],xmm5 
00381035 68 E3 E2 E1 E0       push        0E0E1E2E3h 
0038103A 68 E7 E6 E5 E4       push        0E4E5E6E7h 
0038103F F3 0F 7E 2C 24       movq        xmm5,mmword ptr [esp] 
00381044 83 C4 08             add         esp,8 
00381047 66 0F D6 2D 19 50 38 00 movq        mmword ptr ds:[385019h],xmm5
 

I've got a proper data:
XMM5 = 0000000000000000E0E1E2E3E4E5E6E7
cobalt.rc = 0x00385019  e7 e6 e5 e4 e3 e2 e1 e0
but I can not find the reason why is movq        mmword ptr ds:[385019h],xmm5 getting executed twice

I know that it is something trivial but my brains are overheated at the moment ::)

[aw27]

habran,
I have no idea what you are talking about. I don't know where you found those xmm instructions.
In 32-bit:
mov float.parts,_FP32<0, 80h,4ccccdh> is assembled as:
mov dword ptr [rec32c+0x3000 (00403000)],404CCCCDh

In 64-bit:
mov float.parts,_FP32<0, 80h,4ccccdh> is assembled as
mov dword ptr [rec64c+0x3018 (00000001`40003018)],404CCCCDh
mov  someDouble2.parts, _FP64<0, 400h, 999999999999Ah> is assembled as
00000001`4000111f 48b89a99999999990940 mov rax,400999999999999Ah
00000001`40001129 488905d81e0000  mov     qword ptr [rec64c+0x3008 (00000001`40003008)],rax

aw27, I have already succeeded to make 32 bit work with 64 bit RECORDS,

I don't think so, it still fails in my test suite.  :(

[johnsa]

Hi,

We've changed the way this is working to make it more useful .. inline RECORDs will be evaluate before pre-processing of source lines, which means the result of the record can be used anywhere an immediate would be valid IE as an input to a macro or invoke etc.

Neither 32bit nor 64bit code would allow a 64bit immediate to memory move, so we have added MOV64 as a macro to the macrolibrary which is used in cases where you want to inline a direct record directive to memory.

Code Select Expand



COLOR  RECORD blink:8, back:8, intense:8, fore:8,blink1:8, back1:8, intense1:8, fore1:8
COL8   RECORD blinkx:4, backx:4
COL32 RECORD _a:8,_b:8,_c:8,_d:8

COBALT STRUCT
    pntr1 DWORD ?
    pntr2 DWORD ?
    rc   COLOR <>
COBALT ENDS

cobalt COBALT <>
safir  COLOR <224, 225, 226, 227, 228, 229, 230, 231>                        ; E0E1E20EE0E1E20E
blue COL8 <1,2>
red COL32 <10,20,30,40>

    .CODE

MOV64 cobalt.rc,0x12345678abcdef01
MOV64   cobalt.rc,COLOR<224, 225, 226, 227, 228, 229, 230, 231>
mov  al,COL8<2,3>
mov blue,COL8<3,4>
mov red,COL32<0xff,0x01,0x02,0x03>



The MOV64 macro can be used for general purposes as well as shown in the first line.
This method now removes the need for stack/xmm/reg usage as the immediate values are written directly to memory locations.

The implementation of MOV64 is:

Code Select Expand



MOV64 macro dst:REQ, imm:REQ
mov dword ptr dst, LOW32(imm)
mov dword ptr dst + 4, HIGH32(imm)
ENDM



which keeps it cleaner and also helps to separate out the fact that there is no REAL instruction that moves a 64bit immediate to memory.

Updated download for testing is at :

www.terraspace.co.uk/uasm64_vs17.zip

Cheers
John

[aw27]

MOV64 does not appear to work yet for 64-bit assembling. For 32-bit assembly it works.

[hutch--]

Strange way to do it in 64 bit. Using a register is a lot cleaner.

mov rax, 123456789012
mov pmem, rax

[johnsa]

I debated it, we had it that way previously for 64bit, but I'm trying to avoid (as far as possible) adding any more things into uasm that do "behind the scenes" manipulation of registers.. between prologue/epilogue/switch and so forth pretty soon you won't know what registers are in what state without looking in a debugger.. so opted for "save the registers"(tm) over speed in this case :)

[hutch--]

John,

As long as your pre-processor engine works OK,

  i2m MACRO mem,imm
    mov rax, imm
    mov mem, rax
  ENDM

[habran]

All issues fixed :t

[johnsa]

New packages up on the site and committed to git branch 2.41.
Dated 03-10-2017.

Cheers
John

[jj2007]

No problems found with my bigger sources :t

[aw27]

:t