<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 8, 2018 at 8:58 PM, Nico Williams <span dir="ltr"><<a href="mailto:nico@cryptonector.com" target="_blank">nico@cryptonector.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Jan 08, 2018 at 06:35:36AM -0500, John Levine wrote:<br>
> In article <<a href="mailto:7f4174cb-b842-1314-587a-dd32711a81bf@symas.com">7f4174cb-b842-1314-587a-<wbr>dd32711a81bf@symas.com</a>> you write:<br>
> >> One of them is VLIW, or "Very Long Instruction Word," <br></span></blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> ><br>
> >Intel EPIC -> Itanium -> nobody liked that path.<br></span></blockquote><div>.... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Provided it doesn't speculate behind the compiler's back, you could just<br>
disable speculation by having the compiler emit slower, more sequential<br>
code.  <br></blockquote><div> </div><div>An attacker is not constrained by the graces of the compiler doing the </div><div>correct things.  An attacker would be happy to edit a binary to do bad things. </div><div>A well behaved user community sure.<br>Multiple compiler vendors  ???</div><div><br></div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">  T o m    M i t c h e l l</div></div>
</div></div>