[PATCH v2 02/14] [x86] Add basic support for .code16

[Craig Topper]

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.

Anyway for now I guess the least ugly is to use 3 feature bits.


On Sun, Jan 5, 2014 at 4:01 PM, Joerg Sonnenberger
<joerg at britannica.bec.de>wrote:

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



-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140105/7700a218/attachment.html>