Yet Another Invoke Macro ...

[rrr314159]

Hi vertograd,

Your post took me aback for a moment because printf won't take a value from the stack, since of course it uses rsp for its own purposes, but then I noticed "FCALLTEST". I reckon you're doing the sensible thing, getting the value off the stack and putting it in rdx, r8, r9, or etc, b4 calling printf. I'll probably do that also in my "prnt" routine, but I was thinking about substituting some other register for rsp, such as rbp. That works when done "by hand" but to get it right in all cases appears difficult and/or time-wasting. There are other ways also but all seem worse than the first one.

Some would say we're wasting effort, implementing 2 similar print macros; but that's wrong. It's like saying, if we go for a bicycle ride, one of us is duplicating effort, should stay at home and watch TV! Like bicycling coding is enjoyable and good exercise. Of course too often it's like a bicycle ride where a tire goes flat, the chain breaks, u get caught in a tornado, hit over the head by bandits, then arrested on the way home for littering the path with blood and broken bicycle parts ...  ;)

[GoneFishing]

BLANK

[GoneFishing]

First draft of PRINT macro is done. No FPU resgisters support yet.

Code: [Select]

movups XMM0, o1
  PRINT  RSP
  PRINT  XMM0
  PRINT  RSP
OUTPUT:

RSP    = a6254f80
XMM0 = 12345678 abcdef00 12345678 abcdef00
RSP    = a6254f80

[EDIT] :BINGO ! XMM->print(f) is done! I knew it's possible:

Code: [Select]

.data
      frm   db "%f",10,0
      r  REAL8 123.456789

.code
      _start:   
               movsd    XMM0, r
               mov rdi, offset frm
               mov rax, 1
               call printf OUTPUT:

123.456789

[rrr314159]

@vertograd,

we got another foot of snow, been digging out all morning.

I have been considering what you did with "PRINT" for, e.g, [rsp+4], and I might have an improvement for nvk to do similar, without slowing it down much (just 2 extra instructions!) It would have been done (or, discarded as unworkable) by now but for the snow.

However, I'm confused by your last edit, BINGO XMM=>print(f). The code doesn't work for me - nothing is output. Why put the format string in rdi (normally it goes in rcx) and what's rax got to do with it (to paraphrase Tina Turner)? Of course you have a very good reason: "it works" - but not for me (yet, anyway). R u sure you've posted it correctly? Normally args go in rcx, rdx, r8, r9. I'm missing something, and it just occurred to me - is this Linux code?

[jj2007]

too often it's like a bicycle ride where a tire goes flat, the chain breaks, u get caught in a tornado, hit over the head by bandits, then arrested on the way home for littering the path with blood and broken bicycle parts ...  ;)

Sounds like ordinary Windows coding :lol:

[rrr314159]

OK ... I smell a rat! 

And now, back to our regularly scheduled programming...  :icon_cool:

[GoneFishing]

 BLANK

[rrr314159]

Hi vertograd,

Been working on other things (math algo's using SSE/AVX) and ran into Linux printf function, was reminded of this post. As everyone else already knew, of course your BINGO example is legit Linux - thot u were just pulling my leg!

More snow here yesterday and more on the way. Cat is going stir crazy, wants to be outside ... she wishes there were a rat in the house, give her something to do!

One of these days I'll get back to these printing issues - need to upgrade nvk to do it right - but math routines are (to me) much more important. Should have some interesting results to post soon - amazing how much power is hidden in modern CPU's. Seems no-one is really tapping the full potential.

c u later, good luck with your coding, jogging and beer!

[meneghini]

Hello Buddy!
I'm here just to say thanks, It worked perfect! I'm just a beginner and I had to parse a x86 code to x64 version, as I'm using masm64, this helped a lot. Thanks.

[rrr314159]

Hi meneghini,

glad it helped. Only problem I've noticed, it can make the .exe quite a bit larger, 20%. Often u can replace it by just putting the arguments in rcx,rdx etc then calling the function. What I do, always use it when developing, then in the final product I might try replacing it like that. More than half the time stack is already aligned, etc and nvk's not necessary. Particularly helps when in a macro; if it gets re-instantiated 20 times, saves quite a few bytes to replace it. But good chance you don't care, masm produces such small .exe's anyway it's not a big deal.

thanks for the thanks, I appreciate it!