Date: Sun, 13 Nov 2022 23:55:54 -0500 From: Paul Procacci <pprocacci@gmail.com> To: Daniel Cervus <DanieltheDeer@outlook.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: Question about AMD64 ABI Message-ID: <CAFbbPug0T6R=NtGdwX-XDFJeEYtUAvW8r%2BtMFCT1zaD82g_Osw@mail.gmail.com> In-Reply-To: <TYWP286MB2667C4E185C7A58F6C550FEFB8059@TYWP286MB2667.JPNP286.PROD.OUTLOOK.COM> References: <CAFbbPuge7D4Cky5ucrBg1%2Bp8QLj7t2RMAY-440d935%2BYvyddFw@mail.gmail.com> <TYWP286MB2667C4E185C7A58F6C550FEFB8059@TYWP286MB2667.JPNP286.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000979c2905ed670ebd
Content-Type: text/plain; charset="UTF-8"
>> And what if the function requires a 16-bit or an 8-bit parameter?
When you pass a value, you pass the entirety of the 64-bit register to the
function.
If there's even the slightest chance that the function body acts upon the
entirety of the register, then you _should_ ensure it's zero padded
appropriately.
Again, most compilers are smart enough to perhaps `and reg, 0x0FFFF` or
simply ignore the high bits on its own, but ultimately you do feed it the
entire register in which if the callee expects to operate on 16-bits or
smaller it better do so.
As the programmer of the callee, YOU can take shortcuts. If YOU want to
pass an 8-bit value to a function that you wrote that expects 8-bits then
you can do as you please; don't worry about anything, don't clear the high
bits, etc.
However, note this will seldom be the case. In the 64-bit amd environment,
you'll be operating on 32-bit operands MOST of the time (again which
automatically clears the high bits for you), if not 64 bits directly.
To wrap this all up ... if you want to write a `memcpy' function, its
parameter should expect a `char' that's been zero filled to an `int'.
0xFF -> 0x000000FF
In the function `memcpy' this isn't so important, but when it comes to
arithmetic related ops like `inc/dec/add/sub/etc' it matters as to avoid
eflag stalls.
Thanks,
~Paul
--
__________________
:(){ :|:& };:
--000000000000979c2905ed670ebd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>>> And what if the function requires a 16-=
bit or an 8-bit parameter?<br><br></div><div>When you pass a value, you pas=
s the entirety of the 64-bit register to the function.<br></div><div>If the=
re's even the slightest chance that the function body acts upon the ent=
irety of the register, then you _should_ ensure it's zero padded approp=
riately.<br></div><div><br></div><div>Again, most compilers are smart enoug=
h to perhaps `and reg, 0x0FFFF` or simply ignore the high bits on its own, =
but ultimately you do feed it the entire register in which if the callee ex=
pects to operate on 16-bits or smaller it better do so.<br></div><div><br><=
/div><div>As the programmer of the callee, YOU can take shortcuts.=C2=A0 If=
YOU want to pass an 8-bit value to a function that you wrote that expects =
8-bits then you can do as you please; don't worry about anything, don&#=
39;t clear the high bits, etc.<br></div><div>However, note this will seldom=
be the case.=C2=A0 In the 64-bit amd environment, you'll be operating =
on 32-bit operands MOST of the time (again which automatically clears the h=
igh bits for you), if not 64 bits directly.<br></div><div><br></div><div>To=
wrap this all up ... if you want to write a `memcpy' function, its par=
ameter should expect a `char' that's been zero filled to an `int=
9;.=C2=A0=C2=A0 0xFF -> 0x000000FF<br></div><div>In the function `memcpy=
' this isn't so important, but when it comes to arithmetic related =
ops like `inc/dec/add/sub/etc' it matters as to avoid eflag stalls.<br>=
</div><div> <br></div>Thanks,<br></div>~Paul<br><br><div><div><div>-- <br><=
div dir=3D"ltr" class=3D"gmail_signature">__________________<br><br>:(){ :|=
:& };:</div></div></div></div></div>
--000000000000979c2905ed670ebd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFbbPug0T6R=NtGdwX-XDFJeEYtUAvW8r%2BtMFCT1zaD82g_Osw>