PROC issues

[rain]

Hello folks!
I'm little newbie on moving on x64 platform, and got some questions.
1) Can I use parameters to my functions (except FRAME keyword)?
for example in old good ml.exe we can easly write

Code Select Expand


MyProc PROC dwParam1:DWORD, dwParam2:DWORD
..

so on ml64 we need to handle it by handls like this:

Code Select Expand


MyProc PROC
;save some registers to their place
mov [rsp+8*1],  rcx
mov [rsp+8*2],  rdx
..

i now it works very well, but kinda boring :( and if we use our local variables we need to add that offset, for example:

Code Select Expand


MyProc PROC
;allocate space on stack for local variables
sub rsp, 100h
;now acces to 5 parameter is looks like:
mov rax, [rsp + 8*5 + 100h]

boring.. =(

2) And what about local variables? seems LOCAL keyword is totally missed in ml64. Does we need to calculate offsets by hand too?

Sorry for newbie questions, I know it's new architecture and new philosophy =) and mb my questions is obsolete, so if u can give me some examples of sources for masm64 it would be great, and mb that questions will disappear

thanks in advance

[MazeGen]

rain, welcome on the board.

Unfortunately, PROC doesn't support function parameters (or, it supports it wrong way). Same for LOCAL. See also http://www.masm32.com/board/index.php?topic=7932.0.

As I said, I plan to release (at least first unfinished version of) my macro project to simulate their behaviour, but I'm still busy with other projects :(

[BogdanOntanu]

Until ml64 is upgraded or MazeGen comes up with some clever macros you can try and use structures in order to avoid calculating offsets for arguments and local variables.

[rain]

rain, welcome on the board.

thanks alot MazeGen, cool forum, thanks hutch for his works and sorry for my poor english (I'm russian :) )

Unfortunately, PROC doesn't support function parameters (or, it supports it wrong way). Same for LOCAL. See also http://www.masm32.com/board/index.php?topic=7932.0.

thanks for link, really nice reading, but..

Until ml64 is upgraded

seems it never be updeted, that's really sad that MS just ignore our enthusiast community of asm coders =\

As I said, I plan to release (at least first unfinished version of) my macro project to simulate their behaviour, but I'm still busy with other projects :(

hmm.. sounds cool, gl/hf with that project, it's very ingresting to see on it in work. And how u plannig to replace LOCAL? My knowledge of macro of masm is not best but, seems u can't just trace all push\pops.

btw, seems good that macro language doesn't extrimly changed, so macro like chr$ seems works fine

Cheers =)

[MazeGen]

And how u plannig to replace LOCAL? My knowledge of macro of masm is not best but, seems u can't just trace all push\pops.

Do you mean if procedure locals and params are addressed using RSP base, how do I track all PUSH/POP? If so, current version of the project uses RBP stack frame so it is not an issue.

I also want to add another "mode" where you can switch to ESP stack frame. In this case, PUSH and POP will be completely disabled because, as you said, it is impossible to keep tracking all of them correctly.

[rain]

Sorry for uncertain thoughts.

Do you mean if procedure locals and params are addressed using RSP base, how do I track all PUSH/POP? If so, current version of the project uses RBP stack frame so it is not an issue.

Yes, just some crazy thoughts of assembler, u know, like in code generated by HLL. Of course we can use RBP, it was designed for that.

cheers

[VonKyrin]

I don't know much more than anyone else here, but it seems to me that the problems with the deprecated directives such as PROC are directly related to the changes in how parameters are passed in code compiled by x64 Visual C++ (which presumably is how they compiled the Windows Vista kernel). I read somewhere that the change is that instead of using STDCALL they are now using FASTCALL, but I think that's an over simplification from what little I know about FASTCALL.

It looks to me that parameter passing in x64 Win32 has gotten MUCH more complicated than it was in x86 Win32. I believe that's why Microsoft has not yet attempted to add this functionality back to ML64. From what I see, x86 Win32 parameter passing's most complicated part was deciding which order to pass which parameter on the stack. In x64, there are a whole BUNCH of decisions to make when passing parameters. When I disassembled some C++ x64, it looked like C++ groups together functions that it is planning on calling, and then allocates stack space for ALL of them at once. Not to mention that floating point values are passed in totally different registers than integers are, and so you have to take that into account. I think the bottom line is that parameter passing in x64 Win32 is just far more complicated than it was in x86 Win32, and I'm guessing that's why Microsoft is hesitant to try and add that functionality back to ML64.

I've posted some hyper-links to some documents that talk about the new parameter passing convention in the thread labeled "How to import external function values?"http://www.masm32.com/board/index.php?topic=8290.0

I really want to get this information out to the x64 Assembly Language community, because I'd like to see more people coding Win32 in x64 Assembler. So, if you're not familiar with the new parameter passing in x64, check out those documents and pass the info on to the community.