Struct and bitfield strange behaviour





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







1















I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]









share|improve this question




















  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22


















1















I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]









share|improve this question




















  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22














1












1








1








I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]









share|improve this question
















I am trying to modify bitfields in register. Here is my struct with bitfields defined:



struct GROUP_tag
{
...
union
{
uint32_t R;
struct
{
uint64_t bitfield1:10;
uint64_t bitfield2:10;
uint64_t bitfield3:3;
uint64_t bitfield4:1;
} __attribute__((packed)) B;
} __attribute__((aligned(4))) myRegister;
...
}

#define GROUP (*(volatile struct GROUP_tag *) 0x400FE000)


When I use the following line:



GROUP.myRegister.B.bitfield1 = 0x60;


it doesn't change only bitfield1, but bitfield2 as well. The register has value 0x00006060.



Code gets compiled to the following assembly code:



ldr r3,[pc,#005C]
add r3,r3,#00000160
ldrb r2,[r3,#00]
mov r2,#00
orr r2,#00000060
strb r2,[r3,#00]
ldrb r2,[r3,#01]
bic r2,r2,#00000003
strb r2,[r3,#01]


If I try with direct register manipulation:



int volatile * reg = (int *) 0x400FE160;
*reg = 0x60


the value of register is 0x00000060.



I am using GCC compiler.



Why is the value duplicated when I use struct and bitfields?



EDIT



I found another strange behaviour:



GROUP.myRegister.R = 0x12345678; // value of register is 0x00021212
*reg = 0x12345678; // value of register is 0x0004567, this is correct (I am programming microcontroller and some bits in register can't be changed)


My approach to change register value (with struct and bitfield) gets compiled to:



ldr r3,[pc,#00B4]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000078
strb r2,[r3,#0160]
ldrb r2,[r3,#0160]
mov r2,#00
orr r2,#00000056
strb r2,[r3,#0161]
ldrb r2,[r3,#0162]
mov r2,#00
orr r2,#00000034
strb r2,[r3,#0162]
ldrb r2,[r3,#0163]
mov r2,#00
orr r2,#00000012
strb r2,[r3,#0163]






c gcc assembly struct bit-fields






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 22 '18 at 11:20







Mark

















asked Nov 22 '18 at 9:36









MarkMark

586




586








  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22














  • 1





    Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

    – Aconcagua
    Nov 22 '18 at 9:54











  • I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

    – Mark
    Nov 22 '18 at 9:58













  • What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

    – luci88filter
    Nov 22 '18 at 10:00











  • It produces very strange result. The value of register becomes 0x00818181.

    – Mark
    Nov 22 '18 at 10:09











  • @Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

    – luci88filter
    Nov 22 '18 at 10:22








1




1





Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

– Aconcagua
Nov 22 '18 at 9:54





Probably unrelated (your code compiles, does it?), but register is a keyword in C, so you shouldn't ever use it as name.

– Aconcagua
Nov 22 '18 at 9:54













I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

– Mark
Nov 22 '18 at 9:58







I renamed some variables in my code and forgot that register is a keyword. I edited the question. My code compiles.

– Mark
Nov 22 '18 at 9:58















What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

– luci88filter
Nov 22 '18 at 10:00





What happens if you try GROUP.myRegister.B.bitfield2 = 0x60; ? Does bitfield1 also change ?

– luci88filter
Nov 22 '18 at 10:00













It produces very strange result. The value of register becomes 0x00818181.

– Mark
Nov 22 '18 at 10:09





It produces very strange result. The value of register becomes 0x00818181.

– Mark
Nov 22 '18 at 10:09













@Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

– luci88filter
Nov 22 '18 at 10:22





@Mark Not that strange, 0x8181 is pretty close to 0x6060 left-shifted twice...

– luci88filter
Nov 22 '18 at 10:22












1 Answer
1






active

oldest

votes


















4














Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer


























  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32














Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427820%2fstruct-and-bitfield-strange-behaviour%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer


























  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32


















4














Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer


























  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32
















4












4








4







Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?






share|improve this answer















Ah, I get it. The compiler is using strb twice to write the two least significant bytes to a Special Function Register. But the hardware is performing a word write (presumably 32 bits) each time, because byte writes to Special Function Registers are unsupported. No wonder it doesn't work!



As to how you can fix this, that depends on your compiler, and how much it knows about SFRs. As a quick and dirty fix, you can just use bit manipulation on R; instead of



GROUP.myRegister.B.bitfield1 = 0x60;


use e.g.



GROUP.myRegister.R = (GROUP.myRegister.R & ~0x3FF) | 0x60;


PS Another possibility: it looks like you have turned off optimisation (I see a redundant ldrb r2,[r3,#00] instruction in there). Perhaps if you turn it on, the compiler will come to its senses? Worth a try...



PPS Please change uint64_t to uint32_t. It's making my teeth hurt!



PPPS Come to think of it, that packed may be throwing the compiler off, causing it to assume that the bitfield struct may not be word-aligned (and thus forcing byte-by-byte acesss). Have you tried removing it?







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 22 '18 at 12:11

























answered Nov 22 '18 at 11:47









TonyKTonyK

12.9k42560




12.9k42560













  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32





















  • Removing __attribute__((packed)) solved the problem. Thank you!

    – Mark
    Nov 22 '18 at 12:32



















Removing __attribute__((packed)) solved the problem. Thank you!

– Mark
Nov 22 '18 at 12:32







Removing __attribute__((packed)) solved the problem. Thank you!

– Mark
Nov 22 '18 at 12:32






















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53427820%2fstruct-and-bitfield-strange-behaviour%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Guess what letter conforming each word

Port of Spain

Run scheduled task as local user group (not BUILTIN)