baffled

[jack]

hello
I am trying to get acquainted with O2, so am testing with silly problems
I made a dll of libmingwex and am successful in calling some of the functions in the dll
in 32-bit mode, the following works

Code: [Select]

extern lib "mingwex32.dll"
! mingw_atan2l  Alias "atan2l"  (Byval x As extended, Byval y As extended) As extended
end extern
but same declaration for the 64-bit dll won't work

Code: [Select]

! mingw_atan2l  Alias "atan2l"  (Byref x As extended, Byref y As extended) As extended
I was successful with single argument functions using asm

Code: [Select]

function mingw_sinl(x As extended) As extended
extended z
lea rcx, z
lea rdx, x
call sinl
function=z
end function
but the similarly defined function for atan2l won't work, if the values 1, 2 are passed for the x and y arguments, the result is Pi/4
however, straight asm works, but not if inside a function as above

Code: [Select]

lea rcx, z
lea rdx, x
lea r8,  y
call atan2l
so I am wondering whether the registers inside a function are substituted for other registers.
[edit]
#show revealed the generated code, functions with the asm will not work, a macro works ok.

[Charles Pegge]

byval extended is not possible in 64bit exported/imported procedures because floats are carried in the simd registers, and these only support single and double floats.

[jack]

hello Charles Pegge
in 64-bit the afore mentioned function the arguments are passed byref, and O2 compiles ok but the exe crashes

Code: [Select]

lea rcx, z
lea rdx, x
lea r8,  y
call atan2l
this works, so it's not a problem of passing values byval as you can see the declaration that I used

Code: [Select]

! mingw_atan2l  Alias "atan2l"  (Byref x As extended, Byref y As extended) As extended


[Charles Pegge]

In external 64bit calls, the caller must provide a 32 byte register spill zone on the stack (and also maintain 16-byte stack pointer alignment):

Code: [Select]

lea rcx, z
lea rdx, x
lea r8,  y
        sub rsp,32
call atan2l
        add rsp,32


[Mike Lobanovsky]

Hi Charles,

Without reference to the Oxygen specific assembler dialect,

• Should 16-byte alignment occur before the spill zone is set up? In other words, should the alignment margin be included in the actual number of bytes you're supposed to subtract from/add to rsp?
• Does the 16-byte alignment requirement pertain to the rsp base only or should each of the arguments/locals on the stack (if any at all) be individually aligned (pre-padded with 0's) on CPU architectures that allow unaligned addressing (such as e.g. Intel Pentiums)?

TIA

[Charles Pegge]

Hi Mike,

The 16-byte rsp alignment is required before making any system calls. This restricts the traditional use of push and pop. The stack 'width' is always 8 bytes.

When a call is made, the return adress is pushed on to the stack causing an 8 byte mis-alignment, which must be corrected by the callee to restore 16-byte alignment before proceding.

As I understand it, these are Pentium rules, applying to MS, 'NIX and Apple. I don't know how these things are handled in other architectures.

[jack]

In external 64bit calls, the caller must provide a 32 byte register spill zone on the stack (and also maintain 16-byte stack pointer alignment):

please elaborate on the 16-byte stack pointer alignment, can you give an example on how to do it?
thank you for your patience, my communication skills are crude at best.

[Charles Pegge]

It is safe to assume that rsp is already 16-byte aligned, so the task is to ensure that this alignment is maintained in your assembly code, before making any calls. If you try to call MessageBox with a misaligned rsp it will go GPF.

Code: [Select]

'/*
'03:07 30/06/2019
'rsp alignments
$filename "t.exe"
uses rtl64
uses minwin

jmp fwd begin

msg:
====

sub rsp,40
' sub rsp,8  'to realign rsp after stacking return address
' sub rsp,32 'to provide spill zone
call messagebox
' add rsp,32
' add rsp,8
add rsp,40
ret

begin:
======
mov rcx,0
"Hello"
mov rdx,rax
"Test Message"
mov r8,rax
mov r9,0
call msg



[jack]

thank you