Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 Nov 2022 00:12:46 -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:  <CAFbbPugBchNLWhuwWBGo5g-SvJsKboLsn022iGP2CU0rYqHDBQ@mail.gmail.com>
In-Reply-To: <CAFbbPug0T6R=NtGdwX-XDFJeEYtUAvW8r%2BtMFCT1zaD82g_Osw@mail.gmail.com>
References:  <CAFbbPuge7D4Cky5ucrBg1%2Bp8QLj7t2RMAY-440d935%2BYvyddFw@mail.gmail.com> <TYWP286MB2667C4E185C7A58F6C550FEFB8059@TYWP286MB2667.JPNP286.PROD.OUTLOOK.COM> <CAFbbPug0T6R=NtGdwX-XDFJeEYtUAvW8r%2BtMFCT1zaD82g_Osw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000e50ef305ed674adb
Content-Type: text/plain; charset="UTF-8"

On Sun, Nov 13, 2022 at 11:55 PM Paul Procacci <pprocacci@gmail.com> wrote:

> >> 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
>
> --
> __________________
>
> :(){ :|:& };:
>


As an aside to the above, feel free to start writing something, and send me
some personal emails with snippets and examples of what you might have in
mind.
I'm happy to critique and provide comments as necessary.  I also have a
treasure trove of asm related things that I wrote that could potentially
help with your asm endeavors.
Fair warning though, this isn't for the faint of heart.  There's seldom a
case where I've been able to out-wit a compiler.  They are THAT good
nowadays.

~Paul

-- 
__________________

:(){ :|:& };:

--000000000000e50ef305ed674adb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div dir=3D"ltr"><br></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Nov 13, 2022 at 11:55 PM=
 Paul Procacci &lt;<a href=3D"mailto:pprocacci@gmail.com">pprocacci@gmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div><div>&gt;&gt; And what if the function requires a 1=
6-bit or an 8-bit parameter?<br><br></div><div>When you pass a value, you p=
ass the entirety of the 64-bit register to the function.<br></div><div>If t=
here&#39;s even the slightest chance that the function body acts upon the e=
ntirety of the register, then you _should_ ensure it&#39;s zero padded appr=
opriately.<br></div><div><br></div><div>Again, most compilers are smart eno=
ugh 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.<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 expect=
s 8-bits then you can do as you please; don&#39;t worry about anything, don=
&#39;t clear the high bits, etc.<br></div><div>However, note this will seld=
om be the case.=C2=A0 In the 64-bit amd environment, you&#39;ll be operatin=
g on 32-bit operands MOST of the time (again which automatically clears the=
 high 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&#39; function, its p=
arameter should expect a `char&#39; that&#39;s been zero filled to an `int&=
#39;.=C2=A0=C2=A0 0xFF -&gt; 0x000000FF<br></div><div>In the function `memc=
py&#39; this isn&#39;t so important, but when it comes to arithmetic relate=
d ops like `inc/dec/add/sub/etc&#39; it matters as to avoid eflag stalls.<b=
r></div><div> <br></div>Thanks,<br></div>~Paul<br><br><div><div><div>-- <br=
><div dir=3D"ltr">__________________<br><br>:(){ :|:&amp; };:</div></div></=
div></div></div>
</blockquote></div><br clear=3D"all"><br></div><div>As an aside to the abov=
e, feel free to start writing something, and send me some personal emails w=
ith snippets and examples of what you might have in mind.<br></div><div>I&#=
39;m happy to critique and provide comments as necessary.=C2=A0 I also have=
 a treasure trove of asm related things that I wrote that could potentially=
 help with your asm endeavors.<br></div><div>Fair warning though, this isn&=
#39;t for the faint of heart.=C2=A0 There&#39;s seldom a case where I&#39;v=
e been able to out-wit a compiler.=C2=A0 They are THAT good nowadays.<br></=
div><div><br></div>~Paul<br><br><div>-- <br><div dir=3D"ltr" class=3D"gmail=
_signature">__________________<br><br>:(){ :|:&amp; };:</div></div></div>

--000000000000e50ef305ed674adb--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFbbPugBchNLWhuwWBGo5g-SvJsKboLsn022iGP2CU0rYqHDBQ>