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;
}
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
|
show 9 more comments
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
1
Probably unrelated (your code compiles, does it?), butregister
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 tryGROUP.myRegister.B.bitfield2 = 0x60;
? Does bitfield1 also change ?
– luci88filter
Nov 22 '18 at 10:00
It produces very strange result. The value of register becomes0x00818181
.
– Mark
Nov 22 '18 at 10:09
@Mark Not that strange,0x8181
is pretty close to0x6060
left-shifted twice...
– luci88filter
Nov 22 '18 at 10:22
|
show 9 more comments
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
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
c gcc assembly struct bit-fields
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?), butregister
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 tryGROUP.myRegister.B.bitfield2 = 0x60;
? Does bitfield1 also change ?
– luci88filter
Nov 22 '18 at 10:00
It produces very strange result. The value of register becomes0x00818181
.
– Mark
Nov 22 '18 at 10:09
@Mark Not that strange,0x8181
is pretty close to0x6060
left-shifted twice...
– luci88filter
Nov 22 '18 at 10:22
|
show 9 more comments
1
Probably unrelated (your code compiles, does it?), butregister
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 tryGROUP.myRegister.B.bitfield2 = 0x60;
? Does bitfield1 also change ?
– luci88filter
Nov 22 '18 at 10:00
It produces very strange result. The value of register becomes0x00818181
.
– Mark
Nov 22 '18 at 10:09
@Mark Not that strange,0x8181
is pretty close to0x6060
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
|
show 9 more comments
1 Answer
1
active
oldest
votes
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?
Removing__attribute__((packed))
solved the problem. Thank you!
– Mark
Nov 22 '18 at 12:32
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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?
Removing__attribute__((packed))
solved the problem. Thank you!
– Mark
Nov 22 '18 at 12:32
add a comment |
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?
Removing__attribute__((packed))
solved the problem. Thank you!
– Mark
Nov 22 '18 at 12:32
add a comment |
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?
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?
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 to0x6060
left-shifted twice...– luci88filter
Nov 22 '18 at 10:22