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

diff --git a/30/6f69e812cb83cce4ac1f835857c5112198f48f b/30/6f69e812cb83cce4ac1f835857c5112198f48f
new file mode 100644 (file)
index 0000000..2fd23c4
--- /dev/null
+++ b/30/6f69e812cb83cce4ac1f835857c5112198f48f
@@ -0,0 +1,102 @@
+Return-path: <libre-riscv-dev-bounces@lists.libre-riscv.org>
+Envelope-to: publicinbox@libre-riscv.org
+Delivery-date: Sat, 16 May 2020 10:47:30 +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 1jZtPl-0005pq-Qi; Sat, 16 May 2020 10:47:29 +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 1jZtPk-0005pk-Bd
+ for libre-riscv-dev@lists.libre-riscv.org; Sat, 16 May 2020 10:47:28 +0100
+Received: from hpdc7800 (hpdc7800 [10.0.0.1])
+ by vps2.stafverhaegen.be (Postfix) with ESMTP id 063D111C04FF
+ for <libre-riscv-dev@lists.libre-riscv.org>;
+ Sat, 16 May 2020 11:47:27 +0200 (CEST)
+Message-ID: <ff622773af59baea76786e85e28649a3941e69e5.camel@fibraservi.eu>
+From: Staf Verhaegen <staf@fibraservi.eu>
+To: libre-riscv-dev@lists.libre-riscv.org
+Date: Sat, 16 May 2020 11:47:27 +0200
+In-Reply-To: <CAEoCstS+xz_K6AYNkq-nXB=e7B4FqdC5nzdOXRaNyiqNOuCC7w@mail.gmail.com>
+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>
+Organization: FibraServi bvba
+X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) 
+Mime-Version: 1.0
+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="===============6853962972487324962=="
+Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
+Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>
+
+
+--===============6853962972487324962==
+Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
+       boundary="=-aNfOkJazDJL9i8Rts+Jp"
+
+
+--=-aNfOkJazDJL9i8Rts+Jp
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]:
+>=20
+> >=20
+> > sigh over a year ago i understood this enough to be able to answer.
+> > what we will have to do is simply ignore the optimisation opportunity.
+>=20
+>=20
+> 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.
+
+greets,
+Staf.
+
+
+--=-aNfOkJazDJL9i8Rts+Jp--
+
+
+
+--===============6853962972487324962==
+Content-Type: text/plain; charset="utf-8"
+MIME-Version: 1.0
+Content-Transfer-Encoding: base64
+Content-Disposition: inline
+
+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz
+Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn
+Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj
+di1kZXYK
+
+--===============6853962972487324962==--
+
+
+