From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Envelope-to: publicinbox@libre-riscv.org Delivery-date: Sat, 16 May 2020 12:31:04 +0100 Received: from localhost ([::1] helo=libre-riscv.org) by libre-soc.org with esmtp (Exim 4.89) (envelope-from ) id 1jZv1y-0006WY-PG; Sat, 16 May 2020 12:31:02 +0100 Received: from vps2.stafverhaegen.be ([85.10.201.15]) by libre-soc.org with esmtp (Exim 4.89) (envelope-from ) id 1jZv1w-0006WO-Hn for libre-riscv-dev@lists.libre-riscv.org; Sat, 16 May 2020 12:31:00 +0100 Received: from localhost.localdomain (hpdc7800 [10.0.0.1]) by vps2.stafverhaegen.be (Postfix) with ESMTP id BEF9311C0543 for ; Sat, 16 May 2020 13:30:59 +0200 (CEST) To: libre-riscv-dev@lists.libre-riscv.org References: <747F8870-06C6-46A0-AFD9-D55289D4C41A@gatech.edu> <4BDA96A5-9063-42A6-9548-CAE3CBEBEBAC@gatech.edu> From: Staf Verhaegen Autocrypt: addr=staf@fibraservi.eu; prefer-encrypt=mutual; keydata= xsBNBFrIskcBCADcmvPcGj3WfInZqMlMeLn6COYJnO6bFcDmu0H/7eQ6LDhd5171d+3WSdNN DD6TFgFNWu2qWf7CO9bkp8lmEZ2+T+5detfu/SdddL0lkK2GlIHXah7TnY9Lpr4YykDFL2kX fbdMs32pOnvcK7Jhg/zKBzQyN3wHBPvpBqBnaWfMOMMvigTOAL3/jLPX1+TZ4JiA0YFsJwY5 7ytoqMXUi15eMGCW2URQ+iI35dSCqhyAy375DPjl9Q2veo4g10BruP6C7Qp2Qti3ytQEc1lJ NBMQPdWpxp7kugyoun0U/MYUypc6Todt5SIA47Igo6Mw/x7j5bifepY7Fg8YpUcQV2hHABEB AAHNI1N0YWYgVmVyaGFlZ2VuIDxzdGFmQGZpYnJhc2VydmkuZXU+wsB5BBMBAgAjBQJayLJH AhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQR9EEKdzPltxQaAf+IZBuNgJVeFsQ YNH6iYB23khq27NnFBiRs6gQd6UqSvWESHg3soafuDqYm5aNFTgHkZBzaE+/qP5qOX2Dhj28 9vSwkvHqlhW6ZQP9hnz3XOK+/IT1fdT8GwJAR4JSJn01nroZZf7QWqY/MO42zu9+pRy8ddQo c8AN8WOyowM1apDuu7rLibaWpuBFEEsYkOewjDVFksUcBrsPdNw1I+bw5QifP9/S8xE2W4/c 3BnUROc6TPvJnY7sIREmccdhBOUXNTk1pNXaEnMEBkiVEURgWM+ikonG/dRCNmZM+oclhB4L f2kS4JMEA/lSLVG9tguL2hMp9dPkdO1QPVM0L5972M7ATQRayLJHAQgAvpQaZJ5FZdqONoOI p2iH3AUX+LLEMQRIu6ms4yq/yC4DCnOA2BIqq9FcgNUMGY7EJjPYkkqoz7/Yc4OqSrlpqWYC fdPOMgDTlUTxUd+uWwvmSflEQHqGIN3r3IkXB4OiNDT7+VxZHxUepLU+CzbwpAUT24gH/P5q yCEomTXSovOwW9tLXXhqdTsq8Wv+MrjNAZgDWXTUt6QQh779xnrpIb0foa2av7hlWvxTeRzu RsIMP3pnm8Y8UDLkw/G3SPVC5bnRIcbrbTOOc79xjivKaF4/VkQGgd4IPZlNKX4YoMtldVIe UyCo/RE9oZMHpvsMhH4VFlE3wZ6AR27qxpb5dwARAQABwsBfBBgBAgAJBQJayLJHAhsMAAoJ EEfRBCncz5bcNWAIAKFCWJE6RqUjdshPGy/GLUBfr3dk3M1jjmyvM9SwV9Am7cTyoeJmMG0I rGJINH7HVQqpfeb7SOiQIrBDC0MVyuP6aYnOD2FACSf1plK6bj2CdJAbJupBOC5Fp3p2+Jkz 0ojwQWJul3FTpDqpgat3UX/FySr6em+Jxnfn4dPJ+5wudTQLNdDUw2GHXIKewFnJxZFGVKrV LeGoZ1J9Tcckw7R2BtUrZNgIExxzLD7G+wE48uBP1WVpOWYMcyHslXlA9sSCGSAOPNGaecwL nAZvnFlCbNmNrVMiwGgVydeH+oXIkXzjzov8NZtbxJzjgyCi9gIcKj730jtgAjRCKfScI64= Message-ID: <7c84f530-fc12-0f4e-8a1c-7e58a1b498c3@fibraservi.eu> Date: Sat, 16 May 2020 13:30:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: X-Content-Filtered-By: Mailman/MimeDel 2.1.23 Subject: Re: [libre-riscv-dev] Introduction and Questions X-BeenThere: libre-riscv-dev@lists.libre-riscv.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Libre-RISCV General Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Libre-RISCV General Development Content-Type: multipart/mixed; boundary="===============8438699356721995198==" Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org Sender: "libre-riscv-dev" Archived-At: List-Archive: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============8438699356721995198== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="14KFMkcVJ7dQDl7UpCgxT0L7T9Verovsv" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --14KFMkcVJ7dQDl7UpCgxT0L7T9Verovsv Content-Type: multipart/mixed; boundary="NyNGFtqQ9YKwV65VvuYvJnNWW9hlClfKH" --NyNGFtqQ9YKwV65VvuYvJnNWW9hlClfKH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Op 16/05/2020 om 11:47 schreef Staf Verhaegen: > Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]: >> >> Hmmm, ignoring WAW will significantly limit the ability of the core to= >> exploit ILP, which is one of the fundamental reasons for going OOO. > I've wondered about this myself. Can you give concrete example of where= > not supporting a WAW hazard blocks ILP ? > I am asking because just a WAW hazard could be easily avoided by a good= > peep hole optimizer in software because it would see that the output of= > the first write is never used. Ok after some reflection I do see the most possible performance difference in procedures calls. Most of the time in procedures some scratch registers are pushed on the stack at entering. Assume a write to a scratch register is still pending when doing a procedure. With real register renaming the register stack push does not need to block until write to register is complete, if it doesn't the register push will block. The question is special hardware provision need to be done to optimize this case or if one would rely on proper inlining of functions by the compiler for performance critical code. Personally I don't see a problem with relying on the latter. greets, Staf. --NyNGFtqQ9YKwV65VvuYvJnNWW9hlClfKH-- --14KFMkcVJ7dQDl7UpCgxT0L7T9Verovsv-- --===============8438699356721995198== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj di1kZXYK --===============8438699356721995198==--