6e/3fc364c1ea82d8e6c801b31f651788c17296a7

   1 Return-path: <libre-riscv-dev-bounces@lists.libre-riscv.org>
   2 Envelope-to: publicinbox@libre-riscv.org
   3 Delivery-date: Sat, 16 May 2020 12:31:04 +0100
   4 Received: from localhost ([::1] helo=libre-riscv.org)
   5         by libre-soc.org with esmtp (Exim 4.89)
   6         (envelope-from <libre-riscv-dev-bounces@lists.libre-riscv.org>)
   7         id 1jZv1y-0006WY-PG; Sat, 16 May 2020 12:31:02 +0100
   8 Received: from vps2.stafverhaegen.be ([85.10.201.15])
   9  by libre-soc.org with esmtp (Exim 4.89)
  10  (envelope-from <staf@fibraservi.eu>) id 1jZv1w-0006WO-Hn
  11  for libre-riscv-dev@lists.libre-riscv.org; Sat, 16 May 2020 12:31:00 +0100
  12 Received: from localhost.localdomain (hpdc7800 [10.0.0.1])
  13  by vps2.stafverhaegen.be (Postfix) with ESMTP id BEF9311C0543
  14  for <libre-riscv-dev@lists.libre-riscv.org>;
  15  Sat, 16 May 2020 13:30:59 +0200 (CEST)
  16 To: libre-riscv-dev@lists.libre-riscv.org
  17 References: <CAEoCstQz36UuDJ+ZUgLRJNeQkA=pTfYuzCr+XgF-FJY9+yJsvA@mail.gmail.com>
  18  <747F8870-06C6-46A0-AFD9-D55289D4C41A@gatech.edu>
  19  <CAEoCstRUXkB_LxXXubx4A0dhLGvFqq6EPL+GzukDQORpHopaiw@mail.gmail.com>
  20  <4BDA96A5-9063-42A6-9548-CAE3CBEBEBAC@gatech.edu>
  21  <CAPweEDyZQEBsh8uZ4VkzzALPcoiTgs0AvTmTwS6B0Dc+jy+mfw@mail.gmail.com>
  22  <CAEoCstTERH=Z84je148ffL7_yiBYFj_Zet2VfOzkbe86MVmyQQ@mail.gmail.com>
  23  <CAPweEDyHrrQqPaNy7OqCsPUgR0yrELuRENqZTw_qr-tBVHVg+g@mail.gmail.com>
  24  <CAEoCstT7yZObkbS9GhWDRE7rm3p=Y5CzAJgYYj_3THCuRy=MCQ@mail.gmail.com>
  25  <CAPweEDzObJ1RXD51Y1D1WDJqsmsiNJKL1j-jDQqy0OwKLs6fdQ@mail.gmail.com>
  26  <CAEoCstS+xz_K6AYNkq-nXB=e7B4FqdC5nzdOXRaNyiqNOuCC7w@mail.gmail.com>
  27  <ff622773af59baea76786e85e28649a3941e69e5.camel@fibraservi.eu>
  28 From: Staf Verhaegen <staf@fibraservi.eu>
  29 Autocrypt: addr=staf@fibraservi.eu; prefer-encrypt=mutual; keydata=
  30  xsBNBFrIskcBCADcmvPcGj3WfInZqMlMeLn6COYJnO6bFcDmu0H/7eQ6LDhd5171d+3WSdNN
  31  DD6TFgFNWu2qWf7CO9bkp8lmEZ2+T+5detfu/SdddL0lkK2GlIHXah7TnY9Lpr4YykDFL2kX
  32  fbdMs32pOnvcK7Jhg/zKBzQyN3wHBPvpBqBnaWfMOMMvigTOAL3/jLPX1+TZ4JiA0YFsJwY5
  33  7ytoqMXUi15eMGCW2URQ+iI35dSCqhyAy375DPjl9Q2veo4g10BruP6C7Qp2Qti3ytQEc1lJ
  34  NBMQPdWpxp7kugyoun0U/MYUypc6Todt5SIA47Igo6Mw/x7j5bifepY7Fg8YpUcQV2hHABEB
  35  AAHNI1N0YWYgVmVyaGFlZ2VuIDxzdGFmQGZpYnJhc2VydmkuZXU+wsB5BBMBAgAjBQJayLJH
  36  AhsDBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQR9EEKdzPltxQaAf+IZBuNgJVeFsQ
  37  YNH6iYB23khq27NnFBiRs6gQd6UqSvWESHg3soafuDqYm5aNFTgHkZBzaE+/qP5qOX2Dhj28
  38  9vSwkvHqlhW6ZQP9hnz3XOK+/IT1fdT8GwJAR4JSJn01nroZZf7QWqY/MO42zu9+pRy8ddQo
  39  c8AN8WOyowM1apDuu7rLibaWpuBFEEsYkOewjDVFksUcBrsPdNw1I+bw5QifP9/S8xE2W4/c
  40  3BnUROc6TPvJnY7sIREmccdhBOUXNTk1pNXaEnMEBkiVEURgWM+ikonG/dRCNmZM+oclhB4L
  41  f2kS4JMEA/lSLVG9tguL2hMp9dPkdO1QPVM0L5972M7ATQRayLJHAQgAvpQaZJ5FZdqONoOI
  42  p2iH3AUX+LLEMQRIu6ms4yq/yC4DCnOA2BIqq9FcgNUMGY7EJjPYkkqoz7/Yc4OqSrlpqWYC
  43  fdPOMgDTlUTxUd+uWwvmSflEQHqGIN3r3IkXB4OiNDT7+VxZHxUepLU+CzbwpAUT24gH/P5q
  44  yCEomTXSovOwW9tLXXhqdTsq8Wv+MrjNAZgDWXTUt6QQh779xnrpIb0foa2av7hlWvxTeRzu
  45  RsIMP3pnm8Y8UDLkw/G3SPVC5bnRIcbrbTOOc79xjivKaF4/VkQGgd4IPZlNKX4YoMtldVIe
  46  UyCo/RE9oZMHpvsMhH4VFlE3wZ6AR27qxpb5dwARAQABwsBfBBgBAgAJBQJayLJHAhsMAAoJ
  47  EEfRBCncz5bcNWAIAKFCWJE6RqUjdshPGy/GLUBfr3dk3M1jjmyvM9SwV9Am7cTyoeJmMG0I
  48  rGJINH7HVQqpfeb7SOiQIrBDC0MVyuP6aYnOD2FACSf1plK6bj2CdJAbJupBOC5Fp3p2+Jkz
  49  0ojwQWJul3FTpDqpgat3UX/FySr6em+Jxnfn4dPJ+5wudTQLNdDUw2GHXIKewFnJxZFGVKrV
  50  LeGoZ1J9Tcckw7R2BtUrZNgIExxzLD7G+wE48uBP1WVpOWYMcyHslXlA9sSCGSAOPNGaecwL
  51  nAZvnFlCbNmNrVMiwGgVydeH+oXIkXzjzov8NZtbxJzjgyCi9gIcKj730jtgAjRCKfScI64=
  52 Message-ID: <7c84f530-fc12-0f4e-8a1c-7e58a1b498c3@fibraservi.eu>
  53 Date: Sat, 16 May 2020 13:30:51 +0200
  54 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
  55  Thunderbird/68.7.0
  56 MIME-Version: 1.0
  57 In-Reply-To: <ff622773af59baea76786e85e28649a3941e69e5.camel@fibraservi.eu>
  58 X-Content-Filtered-By: Mailman/MimeDel 2.1.23
  59 Subject: Re: [libre-riscv-dev] Introduction and Questions
  60 X-BeenThere: libre-riscv-dev@lists.libre-riscv.org
  61 X-Mailman-Version: 2.1.23
  62 Precedence: list
  63 List-Id: Libre-RISCV General Development
  64  <libre-riscv-dev.lists.libre-riscv.org>
  65 List-Unsubscribe: <http://lists.libre-riscv.org/mailman/options/libre-riscv-dev>,
  66  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=unsubscribe>
  67 List-Archive: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/>
  68 List-Post: <mailto:libre-riscv-dev@lists.libre-riscv.org>
  69 List-Help: <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=help>
  70 List-Subscribe: <http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev>,
  71  <mailto:libre-riscv-dev-request@lists.libre-riscv.org?subject=subscribe>
  72 Reply-To: Libre-RISCV General Development
  73  <libre-riscv-dev@lists.libre-riscv.org>
  74 Content-Type: multipart/mixed; boundary="===============8438699356721995198=="
  75 Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org
  76 Sender: "libre-riscv-dev" <libre-riscv-dev-bounces@lists.libre-riscv.org>
  77
  78 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
  79 --===============8438699356721995198==
  80 Content-Type: multipart/signed; micalg=pgp-sha1;
  81  protocol="application/pgp-signature";
  82  boundary="14KFMkcVJ7dQDl7UpCgxT0L7T9Verovsv"
  83
  84 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
  85 --14KFMkcVJ7dQDl7UpCgxT0L7T9Verovsv
  86 Content-Type: multipart/mixed; boundary="NyNGFtqQ9YKwV65VvuYvJnNWW9hlClfKH"
  87
  88 --NyNGFtqQ9YKwV65VvuYvJnNWW9hlClfKH
  89 Content-Type: text/plain; charset=utf-8
  90 Content-Transfer-Encoding: quoted-printable
  91 Content-Language: en-US
  92
  93
  94 Op 16/05/2020 om 11:47 schreef Staf Verhaegen:
  95 > Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]:
  96 >>
  97 >> Hmmm, ignoring WAW will significantly limit the ability of the core to=
  98
  99 >> exploit ILP, which is one of the fundamental reasons for going OOO.
 100 > I've wondered about this myself. Can you give concrete example of where=
 101
 102 > not supporting a WAW hazard blocks ILP ?
 103 > I am asking because just a WAW hazard could be easily avoided by a good=
 104
 105 > peep hole optimizer in software because it would see that the output of=
 106
 107 > the first write is never used.
 108
 109 Ok after some reflection I do see the most possible performance
 110 difference in procedures calls. Most of the time in procedures some
 111 scratch registers are pushed on the stack at entering.
 112
 113 Assume a write to a scratch register is still pending when doing a
 114 procedure. With real register renaming the register stack push does not
 115 need to block until write to register is complete, if it doesn't the
 116 register push will block.
 117
 118 The question is special hardware provision need to be done to optimize
 119 this case or if one would rely on proper inlining of functions by the
 120 compiler for performance critical code. Personally I don't see a problem
 121 with relying on the latter.
 122
 123 greets,
 124 Staf.
 125
 126
 127
 128 --NyNGFtqQ9YKwV65VvuYvJnNWW9hlClfKH--
 129
 130 --14KFMkcVJ7dQDl7UpCgxT0L7T9Verovsv--
 131
 132
 133 --===============8438699356721995198==
 134 Content-Type: text/plain; charset="utf-8"
 135 MIME-Version: 1.0
 136 Content-Transfer-Encoding: base64
 137 Content-Disposition: inline
 138
 139 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz
 140 Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn
 141 Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj
 142 di1kZXYK
 143
 144 --===============8438699356721995198==--
 145
 146