Re: [RFA] New bitflags type and eflags on i386/x86-64

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Apr 22, 2002 at 06:08:09PM +0200, Michal Ludvig wrote:
> Daniel Jacobowitz wrote:
> >On Mon, Apr 22, 2002 at 05:15:34PM +0200, Michal Ludvig wrote:
> >
> >>Hi all,
> >>I've created a new typecode TYPE_CODE_FLAGS with appropriate functions 
> >>and used it in builtin_type_i386_eflags type. I did this to be able to 
> >>print i386's and x86-64's FLAGS register in a symbolic form, instead of 
> >>printing it in a hexadecimal and decimal notation.
> >>
> >First of all, please include ChangeLog entries; it makes patches easier
> >to digest quickly.
> 
> I did a while later (as soon as I noticed it went without ChangeLog).
> 
> >Second, I see that you assume a TYPE_CODE_FLAGS type is the size of a
> >long.  I'm not fond of that. 
> 
> unpack_long() returns type LONGEST.
> IMHO it is the biggest integer I can have, isn't it? I don't assume it 
> is just 'long'...

unpack_long returns LONGEST.  Why not have a flagword bigger than that?

> >I would prefer if you instead added
> >support to c-valprint.c for something like Pascal's TYPE_CODE_SET (see
> >p-valprint.c) and used that.  It should be exactly what you're looking
> >for.  Basically, you create an enum describing the bit position (not
> >mask) for each flag, and then call create_set_type with that type as
> >the domain_type.
> 
> I was about to use TYPE_CODE_SET, but I don't know how to add names to 
> its elements. With FLAGS they are written during initialization. Also 
> FLAGS is more simple than SET appears to be. Unfortunately I used pascal 
> too long ago to remember how the set type behaves like...

I described that in my message.  If you create an enum first,
everything should just work.  I don't see the virtue in adding another
type here.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer