Re: [libre-riscv-dev] Introduction and Questions

diff --git a/6e/3fc364c1ea82d8e6c801b31f651788c17296a7 b/6e/3fc364c1ea82d8e6c801b31f651788c17296a7
new file mode 100644 (file)
index 0000000..765dae7
--- /dev/null
+++ b/6e/3fc364c1ea82d8e6c801b31f651788c17296a7
@@ -0,0 +1,146 @@
+Return-path: <libre-riscv-dev-bounces@lists.libre-riscv.org>
+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 <libre-riscv-dev-bounces@lists.libre-riscv.org>)
+       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 <staf@fibraservi.eu>) 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 <libre-riscv-dev@lists.libre-riscv.org>;
+ Sat, 16 May 2020 13:30:59 +0200 (CEST)
+To: libre-riscv-dev@lists.libre-riscv.org
+References: <CAEoCstQz36UuDJ+ZUgLRJNeQkA=pTfYuzCr+XgF-FJY9+yJsvA@mail.gmail.com>
+ <747F8870-06C6-46A0-AFD9-D55289D4C41A@gatech.edu>
+ <CAEoCstRUXkB_LxXXubx4A0dhLGvFqq6EPL+GzukDQORpHopaiw@mail.gmail.com>
+ <4BDA96A5-9063-42A6-9548-CAE3CBEBEBAC@gatech.edu>
+ <CAPweEDyZQEBsh8uZ4VkzzALPcoiTgs0AvTmTwS6B0Dc+jy+mfw@mail.gmail.com>
+ <CAEoCstTERH=Z84je148ffL7_yiBYFj_Zet2VfOzkbe86MVmyQQ@mail.gmail.com>
+ <CAPweEDyHrrQqPaNy7OqCsPUgR0yrELuRENqZTw_qr-tBVHVg+g@mail.gmail.com>
+ <CAEoCstT7yZObkbS9GhWDRE7rm3p=Y5CzAJgYYj_3THCuRy=MCQ@mail.gmail.com>
+ <CAPweEDzObJ1RXD51Y1D1WDJqsmsiNJKL1j-jDQqy0OwKLs6fdQ@mail.gmail.com>
+ <CAEoCstS+xz_K6AYNkq-nXB=e7B4FqdC5nzdOXRaNyiqNOuCC7w@mail.gmail.com>
+ <ff622773af59baea76786e85e28649a3941e69e5.camel@fibraservi.eu>
+From: Staf Verhaegen <staf@fibraservi.eu>
+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: <ff622773af59baea76786e85e28649a3941e69e5.camel@fibraservi.eu>
+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
+ <libre-riscv-dev.lists.libre-riscv.org>
+List-Unsubscribe: <http://lists.libre-riscv.org/mailman/options/libre-riscv-dev>, 
+ <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=unsubscribe>
+List-Archive: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/>
+List-Post: <mailto:libre-riscv-dev@lists.libre-riscv.org>
+List-Help: <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=help>
+List-Subscribe: <http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev>, 
+ <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=subscribe>
+Reply-To: Libre-RISCV General Development
+ <libre-riscv-dev@lists.libre-riscv.org>
+Content-Type: multipart/mixed; boundary="===============8438699356721995198=="
+Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
+Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>
+
+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==--
+
+