C++ Logo

std-proposals

Advanced search

Re: [std-proposals] ABI

From: zxuiji <gb2985_at_[hidden]>
Date: Sun, 14 Jul 2024 14:29:10 +0100
Why are those registers used? Why not RAX and RBX? 64bit functions should
be able to call 32bit functions since they should be used the same
registers, just under different sizes. Without that I see no reason for the
MAP_32BIT flag linux has in the userspace function mmap(). I would
understand the syscall( SYS_mmap ) or whatever it was need it but that's
not a userspace call so there's no reason for a system defined function
like mmap to expose that value in the 1st place. That very flag was the
whole reason I started converting my ABI to use a fixed size integer for
any exposed function expecting an address. Oh well, you can disregard my
earlier mentions of the pointer issues.

On Sun, 14 Jul 2024 at 14:13, Thiago Macieira <thiago_at_[hidden]> wrote:

> On Saturday 13 July 2024 22:38:42 GMT-7 zxuiji wrote:
> > By making pointers exclusive to compile time and not part of the stdabi
> it
> > becomes possible to unify the abi that is linked (for example linking x86
> > apps to an x86_64 library directly). This is the very thing I'm doing in
> my
> > own library launcher pair. I did not realise until reading it in this
> chain
> > however that there are differences in calling conventions between the
> GNUC
> > family of compilers. For now I've tacked __cdecl onto my global API
> define
> > but will need something to address that 16byte aligned vs 4 byte aliigned
> > thing I read on wikipedia
>
> The registers being used are also different. You can't call a 64-bit
> function
> from 32-bit (unless you can figure out how to access r8 and r9 in 32-bit
> code).
> It's also not as clearly obvious, but you can't call 32-bit code from
> 64-bit
> easily either, because the "push" instruction in 64-bit writes 64 bits to
> the
> stack.
>
> Given you can't call such functions across ABI boundaries at all, what's
> the
> point of erasing the pointer size? And besides, how big a pointer is big
> enough?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
>

Received on 2024-07-14 13:22:06