Date: Sun, 13 Nov 2022 09:07:53 +0000 From: Daniel Cervus <DanieltheDeer@outlook.com> To: Paul Procacci <pprocacci@gmail.com> Cc: FreeBSD Questions Mailing List <freebsd-questions@freebsd.org> Subject: Re: Question about AMD64 ABI Message-ID: <TYWP286MB2667FDC5425C52AD3A492052B8029@TYWP286MB2667.JPNP286.PROD.OUTLOOK.COM> In-Reply-To: <CAFbbPujfaSZ%2BxGsKPL4J-arydLCr7=YGyrBTt18Cg8q16z3Tdg@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
Hi Paul,
You mean I need to ensure higher bits are zeros (including signed int, short, char...) when passing the parameters? Okay, I get it.
By the way, is there any good resources that I can learn 64-bit FB (or *nix) assembly programming from?
Regards,
Daniel
在 2022年11月13日，下午4:52，Paul Procacci <pprocacci@gmail.com> 写道：
On Sat, Nov 12, 2022 at 10:31 PM Daniel Cervus <DanieltheDeer@outlook.com<mailto:DanieltheDeer@outlook.com>> wrote:
Hi everyone,
I’m trying to do assembly programming on FB in 64-bit mode. I have a question, 64-bit mode requires parameters to be passed on 64-bit registers. But when a parameter is 32-bit or smaller, do I need to sign-extend (or zero-extend) them to 64-bit? The System V ABI specifications only says "The size of each argument gets rounded up to eightbytes." It’s somewhat ambiguous. How to round up 'float', when they are passed on stack?
Thanks,
Daniel
(Didn't Reply all)
Hi Daniel,
There are a handful of operations that operate on 32bit registers that automatically clear the high bits for you.
32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose register.
16 and 8 bit operands don't have this "built-in" so you would indeed need to ensure the higher bits are cleared.
mov dword edi, 1 is effectively setting rdi to the value of 0x0000000000000001
As for sign extending the values, the answer is `no'.....under most circumstances. If you are sticking to widths of 32 and 64 bits then you are fine.
The moment you mess with 16bits or smaller, then yes, you need to ensure no garbage lives in your higher bits because the cpu doesn't clear this for you.
"The size of each argument gets rounded up to eight bytes."
The size of ALL arguments passed to the callee via general purpose registers is 8 bytes "regardless of what a function def says". It's HOW the callee operates upon the register arguments that matters.
As for passing arguments on the stack ... you shouldn't have to. Not only are there the GPR's rdi, rsi, rdx, rcx, r8, r9, r10 at your disposal for int/scalar types there are also xmm0-xmm7 for your floats.
Thanks,
~Paul
--
__________________
:(){ :|:& };:
[-- Attachment #2 --]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi Paul,</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"> You mean I need to ensure higher bits are zeros (including signed int, short, char...) when passing the parameters? Okay, I get it. </div>
<div dir="ltr"> By the way, is there any good resources that I can learn 64-bit FB (or *nix) assembly programming from?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Regards,</div>
<div dir="ltr">Daniel</div>
<div dir="ltr"><br>
<blockquote type="cite">在 2022年11月13日，下午4:52，Paul Procacci <pprocacci@gmail.com> 写道：<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Nov 12, 2022 at 10:31 PM Daniel Cervus <<a href="mailto:DanieltheDeer@outlook.com">DanieltheDeer@outlook.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi everyone,<br>
<br>
I’m trying to do assembly programming on FB in 64-bit mode. I have a question, 64-bit mode requires parameters to be passed on 64-bit registers. But when a parameter is 32-bit or smaller, do I need to sign-extend (or zero-extend) them to 64-bit? The System
V ABI specifications only says "The size of each argument gets rounded up to eightbytes." It’s somewhat ambiguous. How to round up 'float', when they are passed on stack?<br>
<br>
Thanks,<br>
Daniel</blockquote>
</div>
<br>
</div>
(Didn't Reply all)<br>
<br clear="all">
<div>
<div>
<div>
<div>Hi Daniel,</div>
<div><br>
</div>
<div>There are a handful of operations that operate on 32bit registers that automatically clear the high bits for you.<br>
<br>
32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose register.<br>
</div>
<div>16 and 8 bit operands don't have this "built-in" so you would indeed need to ensure the higher bits are cleared.<br>
<br>
</div>
<div>mov dword edi, 1 is effectively setting rdi to the value of 0x0000000000000001</div>
<br>
</div>
As for sign extending the values, the answer is `no'.....under most circumstances. If you are sticking to widths of 32 and 64 bits then you are fine.</div>
<div>The moment you mess with 16bits or smaller, then yes, you need to ensure no garbage lives in your higher bits because the cpu doesn't clear this for you.<span class="gmail-im"><br>
<br>
"The size of each argument gets rounded up to eight bytes."<br>
</span></div>
<div><br>
The size of ALL arguments passed to the callee via general purpose registers is 8 bytes "regardless of what a function def says". It's HOW the callee operates upon the register arguments that matters.<br>
<br>
</div>
<div>As for passing arguments on the stack ... you shouldn't have to. Not only are there the GPR's rdi, rsi, rdx, rcx, r8, r9, r10 at your disposal for int/scalar types there are also xmm0-xmm7 for your floats.<br>
</div>
<div><br>
</div>
<div>
<div>
<div>Thanks,</div>
<div>~Paul</div>
</div>
</div>
<br>
-- <br>
<div dir="ltr" class="gmail_signature">__________________<br>
<br>
:(){ :|:& };:</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?TYWP286MB2667FDC5425C52AD3A492052B8029>