<div dir="ltr">I think this is sort of begging to separate the concept of "assembler mode" (which wants to be a numeric encoding) from features which are bit oriented.<div><br></div><div>Anyway for now I guess the least ugly is to use 3 feature bits.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jan 5, 2014 at 4:01 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Sun, Jan 05, 2014 at 09:57:21PM +0000, David Woodhouse wrote:<br>
> On Sun, 2014-01-05 at 22:51 +0100, Joerg Sonnenberger wrote:<br>
> > At the moment, In64BitMode is a toogle between two valid modes.<br>
> > Without copying things around in random places (like to the<br>
> > fragments), that's somewhat sane. But the more places are dealing with<br>
> > feature bits, the more important it becomes to ensure the correctness.<br>
> > Does that make sense?<br>
><br>
> Yeah, but the correctness aspect is simply and succinctly stated as<br>
> "Mode16Bit and Mode64Bit are mutually exclusive" — that is, the value<br>
> set {1,1} is invalid.<br>
><br>
> I don't see the merit in inverting them both just to declare that {0,0}<br>
> is invalid instead. Can you show a "likely" coding error or paradigm<br>
> which would make that actually useful?<br>
<br>
</div></div>If the feature bits are not copied in one place, a bad mode is choosen.<br>
Not using {0,0} as invalid encoding prevents exactly that.<br>
<div><div><br>
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>~Craig
</div></div>