From nobody Tue Nov 15 02:36:05 2022 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NB9KZ3VPRz4hXyl for ; Tue, 15 Nov 2022 02:36:18 +0000 (UTC) (envelope-from pprocacci@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NB9KY5cgyz4Fgk for ; Tue, 15 Nov 2022 02:36:17 +0000 (UTC) (envelope-from pprocacci@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-x32f.google.com with SMTP id 94-20020a9d0067000000b0066c8d13a33dso7785210ota.12 for ; Mon, 14 Nov 2022 18:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Vjo+SOEZriNwqML77LolA9A5TrOiUDlEG6vE62IY2F4=; b=hd8op6FcplB3fvFza50PViju7ePzliSoKjqniYo/Q9BCfvJYsu33nsv5vx6Zq2tiPO nGUe95SQ5oJW2aEwgbE4xtYZib3Ct/0OAkqfa4Ssbo5elDV8jbWhVLqKTCWqB7TC/A85 Lfm0WV4CGLcbEqjtMPAJPwdL2tJTYQ0w6AA+qqQzXmtp6XPBsYbwGthI+jY/SC2eFAc8 dliTG11TRpsYJWGA6zjR66v5IP36AKIuzIkP/NHjCh3LgWxn7IpHi56pTJplLLj5N+Kl uK/+lQ1qgtTAsCn2m2LVfpYdHEQo8iYcFIb9BA9IU2zPHCeDo4fbda4qSYAAG0BHbk2v jJYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Vjo+SOEZriNwqML77LolA9A5TrOiUDlEG6vE62IY2F4=; b=E83AMH/vSoxChtVv423BeH2REXn14tsWOEMUrehK2PQjOLkeWCZ3nAFRNOWrEdxbkl rhWbhzQhZ711Hf0wnYDiGQtoXUVR1RRRyBwSbLwIIIn8r4eK2rZkobUK14++N0SrQeOr BXVXD+roMemK69lrv9pOjU6aOShnuNYrmriHt0Zkkh37wEizaH3hg/5+NBk9ctcng7KB WS4bXfxibnOD/cydfdOfSFu59lep5aDWImpBXPXYxyl2I8mMRXyb4R//PL6zJdrjZwHT 2NJpHwlNCzKfCAQTbROF2h/tYLncREKLG2WFRrEPkil1wRTZL1Us4VmP6c1wNVoqE1G2 UsPg== X-Gm-Message-State: ANoB5pn/RYX0D0hNrveV6W++jC4iISQTvjwQ8OxP33tOemFOGZ2sCCLb fkKSqCPV1+23ohK+iyNZV/Rh0JX6Qrz3oywpSDzHwXQL+S8O X-Google-Smtp-Source: AA0mqf5C+nRthDirbGWWJ2ZP5rKVhVI0QHWYkQh39RiFB+Fs9IMSEdjQ86pD4cTM/kgbTkwgbNTkXmzGuYYUSlcbbCw= X-Received: by 2002:a05:6830:1557:b0:66c:44be:cf1d with SMTP id l23-20020a056830155700b0066c44becf1dmr7542937otp.267.1668479776456; Mon, 14 Nov 2022 18:36:16 -0800 (PST) List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Paul Procacci Date: Mon, 14 Nov 2022 21:36:05 -0500 Message-ID: Subject: Re: Question about AMD64 ABI To: Daniel Cervus Cc: "freebsd-questions@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000646d0705ed7938fb" X-Rspamd-Queue-Id: 4NB9KY5cgyz4Fgk X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000646d0705ed7938fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2022 at 9:19 PM Daniel Cervus wrote: > > 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. > > > So I had better zero-extend it to 32 bit, right? Why not 64, because it= =E2=80=99s > already safe enough? > > Or just because the higher 32 bits can be automatically cleared? > Operations on 32 bit operands clear (sets to 0) bits 32 through 63 automatically of a given register. and eax, 0xFFFF This clears bits 16 through 63 because the operand is a 32 bit one. It's implicit due to this convention. The following however, doesn't touch any of the bits higher than 16. and ax, 0xFFFF This is because your operand isn't 32 bits. Both are in essence working the same rax/eax/ax register, but rules of what zero's when play roles here. The easiest way to remember this is when you use a 32-bit register as your operand, bits 32 through 64 will almost always get reset to zero. I honestly suck at explaining things clearly. Perhaps the manual itself can explain it better than I. Section 3.4 is where Intel describes the behavior I'm trying to describe. https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-= 32-architectures-software-developer-vol-1-manual.pdf ~Paul --=20 __________________ :(){ :|:& };: --000000000000646d0705ed7938fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Nov 14, 2022 at 9:1= 9 PM Daniel Cervus <Danielt= heDeer@outlook.com> wrote:

Again, most compilers are smart enough to perhaps `and reg, 0x0FFFF` or sim= ply ignore the high bits on its own, but ultimately you do feed it the enti= re register in which if the callee expects to operate on 16-bits or smaller= it better do so.

So I had better zero-extend it to 32 bit, right? Why not 64, because it=E2= =80=99s already safe enough?
Or just because the higher 32 bits can be automatically cleared?

Operations on 32 bit operands cl= ear (sets to 0) bits 32 through 63 automatically of a given register.

and eax, 0xFFFF

This clears bits 16 through = 63 because the operand is a 32 bit one.=C2=A0 It's implicit due to this= convention.
The following however, doesn't touch any of = the bits higher than 16.

and ax, 0xFFFF
This is because your operand isn't 32 bits.
B= oth are in essence working the same rax/eax/ax register, but rules of what = zero's when play roles here.

The easiest way to remem= ber this is when you use a 32-bit register as your operand, bits 32 through= 64 will almost always get reset to zero.

I honestly suck at = explaining things clearly.=C2=A0 Perhaps the manual itself can explain it b= etter than I.=C2=A0 Section 3.4 is where Intel describes the behavior I'= ;m trying to describe.
https://www.intel.com/content/dam/www/public/us/en/document= s/manuals/64-ia-32-architectures-software-developer-vol-1-manual.pdf

~Paul
--
__________________

:(){ :|:& };:
--000000000000646d0705ed7938fb--