From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web09.9476.1637662342447739563 for ; Tue, 23 Nov 2021 02:12:23 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@posteo.de header.s=2017 header.b=aOl1UcFK; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 7A5BB240026 for ; Tue, 23 Nov 2021 11:12:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1637662339; bh=b9mq5qv+MfrYLpJ5MvMTk/5l3UW1Ois7Ux/9drKc/+w=; h=Date:Subject:From:To:Cc:From; b=aOl1UcFKW7fcqkcqReL+BkpSBzQzQ3bfprKIyEPddhf0UurfqSzyoWmIYl6YjKuTM EYDOiGVkwcz6Q8ML/FsUU9tabRqHlAhL9uc7NL3vMrMox7/VS/3c25IQpNL7BpSIPN FFQzs+8rlYNPXG7oJkcly+Q2k3e9P2KSVChEVLgQe9nMNcjc1PHOdO0eBo0gIAYBEW XOakknyU6Z/Fa9LYfBLKNU2J/WR838c7Z8qq/q1QaJpUYHIPOyZuM3suyNyqp6O9rT 50iJJdB9o+6zv+x6Au9grYVVkJnDwW1U4r9qhoOJDuOhAsIJyfYKcXr0OC5YAmJL+G RvhaRhtEQSwng== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Hz0LT3RNTz6tmP; Tue, 23 Nov 2021 11:12:16 +0100 (CET) Message-ID: <56c7bb53-a6d0-efae-bf1d-20824b6c2fa8@posteo.de> Date: Tue, 23 Nov 2021 10:12:16 +0000 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH V2 2/3] MdePkg/Base.h: Introduce various alignment-related macros From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= To: devel@edk2.groups.io, ray.ni@intel.com Cc: "Kinney, Michael D" , Liming Gao , "Liu, Zhiguang" , Vitaly Cheptsov References: <69c6e14c4fe944d380d38dcdb851a88f51631f86.1629057790.git.mhaeuser@posteo.de> <6b4798af-92e4-3411-1586-f9e1d922e0ab@posteo.de> In-Reply-To: <6b4798af-92e4-3411-1586-f9e1d922e0ab@posteo.de> Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Ping? :) On 16.08.21 15:10, Marvin H=C3=A4user wrote: > Hey Ray, > > On 16/08/2021 11:42, Ni, Ray wrote: >> Marvin, >> So lucky to have you in the edk2 project looking into these=20 >> fundamentals! > > Thank you. :) > >> +=C2=A0 #define ALIGNOF(TYPE) OFFSET_OF (struct { CHAR8 C; TYPE A; }, A) >> >> 1. Does struct{} inside a macro conform to C standard? How is the=20 >> compatibility with different compilers? > > This should work, yes. The C standard defines offsetof as such: > > "The macros are [...] > > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 offsetof(type, member-designator) > > which expands to an integer constant expression that has type size_t,=20 > the value of > which is the offset in bytes, to the structure member (designated by=20 > member-designator), > from the beginning of its structure (designated by type). The type and=20 > member designator > shall be such that given > > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 static type t; > > then the expression &(t.member-designator) evaluates to an address=20 > constant. [...]" [1] > > If we plug in t: > > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 static struct { CHAR8 C; TYPE A; } = t; > > we get a valid static storage duration variable declaration that=20 > satisfies the the last condition because: > > "An address constant is [...], a pointer to an lvalue designating an=20 > object of static > storage duration, or [...]" [2] > > It worked with all compilers I tinkered with at https://godbolt.org/ > I sadly do not have access to any of the compilers where this may be=20 > used effectively (RVCT, EBC). > >> +#define IS_POW2(Value)=C2=A0 ((Value) !=3D 0U && ((Value) & ((Value) - = 1U)) =3D=3D >> +0U) >> >> 2. Good to me. I learned this trick when implementing the MtrrLib. >> >> +#define ALIGN_VALUE_ADDEND(Value, Alignment)=C2=A0 (((Alignment) - (Val= ue)) >> +& ((Alignment) - 1U)) >> >> 3. Is any other open source project using the same macro for the addend? >> This is actually a general question to all new macros. >> I would like the macros look familiar to developers from other open=20 >> source projects. > > Good question, I never really saw it. I only came up with it because=20 > for the new PE loader, we may align the PE memory within an=20 > underaligned buffer, and for that we need the addend. I initially used=20 > to align up and then subtract, but I saw this could be simplified with=20 > ALIGN_VALUE_ADDEND, which was used in ALIGN_VALUE anyway. If you have=20 > a better name, I'll change it. > > Best regards, > Marvin > > > [1] ISO/IEC 9899:2011, 7.19, 3. > > [2] ISO/IEC 9899:2011, 6.6, 9. > >> >> >>=20 >> >> >