Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:21 PM, Jimi Xenidis wrote:
I have some and use them in some code, they represent ISA 2.06 MAVN=1
(version 2)
Can I keep them?
if so, should I put them somewhere useful to others?
Examples:
union mas1 {
u32 _val;
struct {
u32 v:1;
u32 iprot:1;
u32 tid:14;
u32 _reserved_1:2;
u32 ind:1;
u32 ts:1;
u32 tsize:4;
u32 _reserved_2:8;
};
};
Uugh, we really have avoided unions for such things and it would be nice to
keep it that way.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: union/struct representations for MAS Registers
I have some and use them in some code, they represent ISA
2.06 MAVN=1 (version 2)
Can I keep them?
if so, should I put them somewhere useful to others?
Examples:
union mas1 {
u32 _val;
struct {
u32 v:1;
u32 iprot:1;
u32 tid:14;
u32 _reserved_1:2;
u32 ind:1;
u32 ts:1;
u32 tsize:4;
u32 _reserved_2:8;
};
};
Bitfields are rather non-portable, the compiler has a lot of choice
about how to align the bits in memory.
Their use to map anything physical is doomed to portabilily issues.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:25 PM, Kumar Gala wrote:
On Aug 10, 2011, at 12:21 PM, Jimi Xenidis wrote:
I have some and use them in some code, they represent ISA 2.06 MAVN=1
(version 2)
Can I keep them?
if so, should I put them somewhere useful to others?
Examples:
union mas1 {
u32 _val;
struct {
u32 v:1;
u32 iprot:1;
u32 tid:14;
u32 _reserved_1:2;
u32 ind:1;
u32 ts:1;
u32 tsize:4;
u32 _reserved_2:8;
};
};
Uugh, we really have avoided unions for such things and it would be nice to
keep it that way.
I like nice, I'll convert
-JX
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:25 PM, David Laight wrote:
I have some and use them in some code, they represent ISA
2.06 MAVN=1 (version 2)
Can I keep them?
if so, should I put them somewhere useful to others?
Examples:
union mas1 {
u32 _val;
struct {
u32 v:1;
u32 iprot:1;
u32 tid:14;
u32 _reserved_1:2;
u32 ind:1;
u32 ts:1;
u32 tsize:4;
u32 _reserved_2:8;
};
};
Bitfields are rather non-portable, the compiler has a lot of choice
about how to align the bits in memory.
I'm ok with the masking stuff.
However, I'm actually surprised this is true given the maturity of our ABIs.
-JX
Their use to map anything physical is doomed to portabilily issues.
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: union/struct representations for MAS Registers
Bitfields are rather non-portable, the compiler has a lot of choice about how to align the bits in memory. I'm ok with the masking stuff. However, I'm actually surprised this is true given the maturity of our ABIs. The C standard says nothing at all about how bitfields are implemented, I think the first bit might be 0x1, 0x80, 0x100 or 0x8000 when treated as a 32bit value, regardless of the endianness. Different architectures can (and do) assign things in different ways. So code that is ok on ppc might fail on arm or x86 (etc). David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: union/struct representations for MAS Registers
On Aug 10, 2011, at 12:38 PM, David Laight wrote: Bitfields are rather non-portable, the compiler has a lot of choice about how to align the bits in memory. I'm ok with the masking stuff. However, I'm actually surprised this is true given the maturity of our ABIs. The C standard says nothing at all about how bitfields are implemented, I think the first bit might be 0x1, 0x80, 0x100 or 0x8000 when treated as a 32bit value, regardless of the endianness. Different architectures can (and do) assign things in different ways. So code that is ok on ppc might fail on arm or x86 (etc). David I think PPCs a bit sane and what Jimi was proposing the union for is something that would never need to be portable (as it a PPC specific register). Still, prefer the shifts, masks macros as that's what I've been reading using in ppc land forever ;) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
