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 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