Recent posts

#1

MASM64 SDK / Re: Environment issue? Simple ...

Last post by jj2007 - September 14, 2024, 09:45:03 PM

Actually, yes. On entry
Code Select Expand

Code Select Expand

RSP+0     return address
RSP+8     space for 1st arg
RSP+16    space for 2nd arg
RSP+24    space for 3rd arg
RSP+32    space for 4th arg
RSP+40    actual 5th arg - first stack arg

You are right, as usual

#2

Windows Projects / Re: Hyper (precision) numeric ...

Last post by i Z ! - September 14, 2024, 08:49:17 PM

hello i Z !
I would be interested in testing you HyperLib but there several reasons that prevent that
1: prohibitive licence
2: closed source
3: binary distribution only, and worst, it comes as an installer

hi Jack,

points 1. and 2. are not preventing you from testing. For the 3rd, I silently hope that one day, you'll find the courage to just install the bloody thing :) it only takes a split second.
I'm planning to use this library in one of my bigger projects and I need to know whether the calculations are performed correctly 100% . I tested the boundaries, it appears to work well, but you never know :)

#3

The Orphanage / Re: Copilot vs Chat-GPT

Last post by sinsi - September 14, 2024, 06:51:14 PM

 

At least Copilot's would work. ChatGPT? Good luck with that

#4

The Orphanage / Copilot vs Chat-GPT

Last post by Biterider - September 14, 2024, 06:40:39 PM

Hi
The AI hype is not over yet. Some companies are moving forward with copilot and co, while others have banned them, mostly for safety reasons. 

Things are a bit different for private users.
Some time ago I tested Chat-GPT for assembler programming and was a little disappointed and put it aside.
A colleague of mine uses AI tools extensively for his high-level programming tasks and is enthusiastic about them.

This led me to check out Copilot with a simple prompt 

show me an x64 assembler skeleton program for Windows using the Windows API

and I was amazed at what it came with.
I typed the same prompt into Chat-GPT and the response was even better.

Things seem to be getting better, particularly for asm coding... 

Biterider

[is 32 bytes above the return address]

#5

MASM64 SDK / Re: Environment issue? Simple ...

Last post by sinsi - September 14, 2024, 05:49:29 PM

The Shadow space (also sometimes called Spill space or Home space) is 32 bytes above the return address

It's the 32 bytes, not 32 bytes above.

below stack args

Really?

Actually, yes. On entry

Code Select Expand

RSP+0     return address
RSP+8     space for 1st arg
RSP+16    space for 2nd arg
RSP+24    space for 3rd arg
RSP+32    space for 4th arg
RSP+40    actual 5th arg - first stack arg

I've never heard the debugging reason though, the main use for me is saving the args for later use, since the first WinAPI call will probably trash RCX etc.
If you don't use it then there's 32 bytes for any small locals for you to use.
I've seen code that uses it to save registers instead of pushing them.

#6

MASM64 SDK / Re: Environment issue? Simple ...

Last post by jj2007 - September 14, 2024, 04:35:34 PM

below stack args

Really?

#7

UASM Assembler Development / Re: Use the MOV instruction to...

Last post by wanker742126 - September 14, 2024, 01:19:50 PM

In fact, I just hope that UASM64.EXE can assembly the following three situations:
MOV reg1,VAR[reg2*n]
MOV VAR[reg1*n],reg2
MOV Var[reg*n],imm
I didn't expect to be able to use the entire 64-bit addressing space. So I have always misunderstood your question.

#8

UASM Assembler Development / Re: Use the MOV instruction to...

Last post by _japheth - September 14, 2024, 12:27:31 PM

My MYFIX_ENG.INC can only be used in
MOV reg1,VAR[reg2*n]

Ok, I did a little test:

Code Select Expand

.x64
.model flat
include MYFIX_ENG.INC

.data
db 50h dup (?)
array dd 0,1,2,3,4,5,6,7

.code
start:
xor ecx, ecx
mova eax, array[rcx*4]
mov eax, array[rcx*4]
ret
end  start

Since UASM refuses indexed addressing with symbolic displacement, I used JWasm to assemble it. DUMPBIN then displays the following relocations:

Code Select Expand

Offset    Type              Applied To         Index     Name
 --------  ----------------  -----------------  --------  ------
 00000005  ADDR32                     00000050         4  .data
 0000000C  ADDR32                     00000000         9  array

So there's indeed a difference, but the important thing is that both relocs are ADDR32. This inevitably makes  MS link complain:

Code Select Expand

Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

MOV64b.obj : error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
MOV64b.obj : error LNK2017: 'ADDR32' relocation to 'array' invalid without /LARGEADDRESSAWARE:NO
LINK90 : fatal error LNK1165: link failed because of fixup errors[/code]

Of course, adding /LARGEADDRESSAWARE:NO to link's cmdline makes the errors disappear, but the image is then restricted to run in the first 4 GB of the address space.

#9

UASM Assembler Development / Re: Use the MOV instruction to...

Last post by wanker742126 - September 14, 2024, 10:31:34 AM

My MYFIX_ENG.INC can only be used in
MOV reg1,VAR[reg2*n]
MOV VAR[reg1*n],reg2
MOV Var[reg*n],imm
In three cases, reg1, reg2, and reg can only be general purposes registers, cannot be RIP. In fact, RIP cannot change its value through MOV. In addition, I also admit that MYFIX_ENG.INC is very large, with more than 400 lines, so I did not list the entire code on the forum, but downloaded its link through MEGA. Maybe you experts can simplify it :).

#10

MASM64 SDK / Re: Environment issue? Simple ...

Last post by NoCforMe - September 14, 2024, 10:11:49 AM

I certainly don't want to preempt sinsi or anyone else here who knows more than I do about X64 programming. However, I ran across an explanation of spill space (aka shadow space) which may be helpful. Apparently, there are two main reasons for providing this memory space: debugging and handling functions with variable-length argument lists (varargs):

The Shadow space (also sometimes called Spill space or Home space) is 32 bytes above the return address which the called function owns (and can use as scratch space), below stack args if any. The caller has to reserve space for their callee's shadow space before running a call instruction.

It is meant to be used to make debugging x64 easier.

Recall that the first 4 parameters are passed in registers. If you break into the debugger and inspect the call stack for a thread, you won't be able to see any parameters passed to functions. The values stored in registers are transient and cannot be reconstructed when moving up the call stack.

This is where the Home space comes into play: It can be used by compilers to leave a copy of the register values on the stack for later inspection in the debugger. This usually happens for unoptimized builds. When optimizations are enabled, however, compilers generally treat the Home space as available for scratch use. No copies are left on the stack, and debugging a crash dump turns into a nightmare.

Of course, the space can be used by a compiler, but we're not using one (this is assembly language), so the spill space just sits there unused, even though it must be "allocated" (by moving the stack pointer before calling the function).

Any better explanations welcomed here.