Re: [PATCH 6/7] target/ppc: Reorder PPC2 flags

I don't have a strong opinion on this either way, but I don't think we
need a decision on this before allowing this patch set to proceed
either.  Therefore...

Reviewed-by: Glenn Miles <[email protected]>

Thanks,

Glenn

On Mon, 2026-07-20 at 18:35 +0530, Chinmay Rath wrote:
> On 7/15/26 20:11, Shivang Upadhyay wrote:
> > On Wed, 2026-07-15 at 18:26 +0530, Chinmay Rath wrote:
> > > +    PPC2_BCDA_ISA206   = 0x0000000000040000ULL,
> > >       /* PPE42
> > > instructions                                                    */
> > > -    PPC2_PPE42         = 0x0000000000800000ULL,
> > > +    PPC2_PPE42         = 0x0000000000080000ULL,
> > >       /* PPE42X
> > > instructions                                                   */
> > > -    PPC2_PPE42X        = 0x0000000001000000ULL,
> > > +    PPC2_PPE42X        = 0x0000000000100000ULL,
> > >       /* PPE42XM
> > > instructions                                                  */
> > > -    PPC2_PPE42XM       = 0x0000000002000000ULL,
> > > +    PPC2_PPE42XM       = 0x0000000000200000ULL,
> > >   
> > Hi Chinmay,
> > 
> >   Would it be fine if we can do something like this instead?
> > 
> > PPC2_PPE42XM  = (1ull << 21);
> > 
> > It would be easy to see where the gaps are from next time.
> Hi Shivang,
> Thanks for the suggestion. I agree with you. Looking at the shift 
> numbers and making sure they are in consecutive incremental order would 
> make gaps less likely. However if we are to switch to this way, there 
> are about 40 such flags in cpu.h which will have to be reset in this 
> fashion. Hence should be a different patch in itself as the objective of 
> this series is different. Plus it would also bring in the risk of 
> someone shifting a bit by a value that might cause an overflow. So one 
> would have to take care of that while adding a new flag. So this way or 
> the original way, one does need to take care of couple things while 
> adding future flags.
> 
> Regards,
> Chinmay
> 
> > ~Shivang.
> >