Playtime with ML64 and a question on spill space.

[hutch--]

 

Habran,

hutch and jj2007, if you find the FASTCALL to compex, brace yourself for the VECTORCALL which is coming in the next release of HJWasm

I was using FASTCALL in MS-DOS in 1990, passing data in registers without a stack is not new technology. As far as the later AVX instructions, you must first have the hardware, then read the Intel manuals. In Win32 you can do your own FASTCALL with EAX, ECD and EDX and use GLOBALS for any further arguments OR use structures passed in 1 register.

Now Win64 apart from having a really crappy ABI has many advantages for an assembler language programmer, roll your own VERYFASTCALL with the extra integer registers (rax rcx rdx r8 r9 r10 r11) and GLOBALS for a stack free method of calling procedures while remaining compatible with the Windows version of the ABI. What you don't need to cripple 64 bit x86 assembler with is the assumptions of a C compiler. If you do you may as well use a C compiler and write modules in an assembler when you need extra speed.

[mineiro]

Thanks for answering.
Good sir rrr314159, the first thing is to put code to do something usefull, after yes, optimize. I like simplistic too and I start from point where everything will not work, this way I can reach less headcache. Thanks a lot, very helpfull answer.

sir habran, so I suppose the answer is no.

I meet the owner of that .br site years ago on an extinguished board, he have translated radasm language to brazilian portuguese, don't appears to be a bad person, but I will not put my hand on fire.

Good job sir fearless.

[fearless]

Yeh seems that site gives a warning about radasm v2, not sure where else it is hosted anymore, if at all - hopefully some of the other info helps anyhow.

Maybe softpedia: http://www.softpedia.com/get/Programming/File-Editors/RadASM.shtml - seemed to work

plus minor update i compiled for a v2.2.2.1 (only worth getting this exe if your are likely to have more than 256 resources compiled into your final project - raises the limit up to 512 resource files in total): http://masm32.com/board/index.php?topic=4884.msg53620#msg53620

[habran]

Sir mineiro, that means that it will be taken care of
Mr. fearless, softpedia is fine :t
Maestro hutch ;)
I don't doubt your programming skills, and I agree with you about crappy ABI.
What I love the mos about x64 is having plenty of registers to work (my apology to rrr314159) with.
Those who do programming for maths or graphic will be able to the advantage of the VECTORCALL.
The difference between  C and assembler is that in assembler we can optimize the code for the specific purpose, while C language does it more portable. So, my goal is to create assembly source easy to understand (HLL features) and at the same time optimized for the machine code 8)

[Mikl__]

Hi, rrr314159!
You wrote

There are other mistakes in all tutorials you'll see, which I'll mention briefly. They say all floating points are passed in XMM's. No, they're often passed in the GPRs. For instance printf gets floats from GPRs and will ignore any data you send in XMM

Tell me please how to display the contents of the XMM-register or a real number (float, double, 80- or 128-bits) using the printf function?
Thank you!

[jj2007]

Tell me please how to display the contents of the XMM-register or a real number (float, double, 80- or 128-bits) using the printf function?

Here is the 32-bit version:

include \masm32\MasmBasic\MasmBasic.inc      ; download
.data
SomeInt        dq    1234567890123456789
SomeFloat      REAL8 1234567890.1234567890

  Init
  movlps xmm0, SomeInt
  movlps xmm1, SomeFloat
  Print Str$("X0 (int)=\t%i\n", xmm0), Str$("X1 (R8)=\t%If\n", f:xmm1)      ; for comparison

  sub esp, 8            ; create qword slot
  mov esi, esp          ; assign a reg that points to the slot
  movlps qword ptr [esi], xmm0      ; move a qword from xmm reg to slot

  sub esp, 8            ; repeat for second value
  mov edi, esp
  movlps real8 ptr [edi], xmm1

  printf("X0 (int)=\t%lld\n", qword ptr [esi])
  printf("X1 (float)=\t%.8f\n", REAL8 ptr [edi])
  Inkey "that was cute, right?"
EndOfCode

Output:

Code Select Expand

X0 (int)=       1234567890123456789
X1 (R8)=        1234567890.12345672
X0 (int)=       1234567890123456789
X1 (float)=     1234567890.12345670

Note that CRT and WinAPI both have the bad habit ("ABI") to trash the lower xmm regs :(

[Mikl__]

Thank you, jj2007!

[rrr314159]

Hi, rrr314159!
You wrote

There are other mistakes in all tutorials you'll see, which I'll mention briefly. They say all floating points are passed in XMM's. No, they're often passed in the GPRs. For instance printf gets floats from GPRs and will ignore any data you send in XMM

Tell me please how to display the contents of the XMM-register or a real number (float, double, 80- or 128-bits) using the printf function?
Thank you!

See this post http://masm32.com/board/index.php?topic=3988.msg42123#msg42123 in my old thread "Yet Another Invoke Macro". jj2007, GoneFishing and I discussed this at some length, in the pages around this post. Basic idea: put XMM contents into memory, pass pointer to printf, and use %llx format command (twice). AFAIK that's the only way; printf doesn't accept XMM registers as input.

Code Select Expand

include \myinc\inc64.inc
.data
    o1 OWORD 12335678aacdff0112344678abbeef02h
.code

start:
    movups xmm0, o1
    movups [rsp-16], xmm0
    mov r15, [rsp-8]
    mov r14, [rsp-16]
    prnt "%llx ", QWORD PTR r14
    prnt "%llx \n", QWORD PTR r15
ret
end start

This code puts XMM0 on the stack, because that's what GoneFishing (a.k.a. Vertograd) wanted to do; you could also simply point at o1. If you want to use this code as it is you have to get my nvk macro, along with prnt macro and "inc64.inc" includes. But "prnt" is just a simple wrapper that calls printf. You should be able to adapt this technique to use with printf, without needing the nvk macro (s).

[EDIT] Forgot you asked about real numbers also. 64-bit, put it in a register, like r8 or r9. Larger, you would have to use the above technique with the right format statement, maybe %llf; I don't know about that.

[jj2007]

use %llx format command

%llx doesn't work for me - do you have code that produces valid output? Or is there are difference between 32-bit and 64-bit crt printf()??

See above, they both work fine:
  printf("X0 (int)=\t%lld\n", qword ptr [esi])
  printf("X1 (float)=\t%.8f\n", REAL8 ptr [edi])

[rrr314159]

@jj2007, I don't remember. But I know %llx (long hex) worked with that code. Undoubtedly if you download nvk macros, which includes everything except the libraries, it will work. And, there were other %ll type formats that worked; maybe %llf, %llu, etc. These days I'm only doing 32-bit, because I got tired of the lack of standardization with 64-bit. Happened often that something worked for me, with my idiosyncratic macros, but not for others. To get benefit from my stuff you should probably read the code see what went on under the hood, and adapt what's useful for your own code.

[jj2007]

@jj2007, I don't remember. But I know %llx (long hex) worked with that code.

Yes it does: llx produces hex output. I had fed it with the decimal stuff posted above, and couldn't make sense of the result...
My fault :P

[rrr314159]

Partly my fault also. MikL asked about floating point, I didn't read carefully, and responded with a hex format code.

[MichaelW]

For the original question, Raymond Chen provides a compact answer here:

"The stack must be kept 16-byte aligned. Since the "call" instruction pushes an 8-byte return address, this means that every non-leaf function is going to adjust the stack by a value of the form 16n+8 in order to restore 16-byte alignment."

[hutch--]

Thanks Michael.  :t

[mineiro]

Sir mineiro, that means that it will be taken care of

Ohh sir habran, really sorry, only now I understand what you have write, my fault. Only today I access your page and I understood about name John.
I download hjwasm and now I'm playing with it, I have successfull coded a simple asm sample.
Thanks a lot.