How much memory does alignment use in C?
I have this program:
__attribute__((section(".graph"))) __attribute__((aligned(16)))
uint16_t FLASH_BUFFER2[FLASH_SECTOR_SIZE];
int main ()
{
printf("Hallo World"n);
}
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
Edit : The technically correct question is "does it reserve FLASH_SECTOR_SIZE * 2 * 16 bytes in memory? (2 for uint16_t and 16 for alignment)"
c memory embedded
asked Nov 21 '18 at 18:13
TasosTasos
4761724
|
show 6 more comments
I have this program:
__attribute__((section(".graph"))) __attribute__((aligned(16)))
uint16_t FLASH_BUFFER2[FLASH_SECTOR_SIZE];
int main ()
{
printf("Hallo World"n);
}
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
Edit : The technically correct question is "does it reserve FLASH_SECTOR_SIZE * 2 * 16 bytes in memory? (2 for uint16_t and 16 for alignment)"
c memory embedded
asked Nov 21 '18 at 18:13
TasosTasos
4761724
2
hum, where else do you think it could be?
– OznOg
Nov 21 '18 at 18:14
I have an embedded system with 1MB available RAM, theFLASH_SECTOR_SIZEis 65536. So this should take the entire memory. They gave me the code like this and I am wondering the same thing as you to be honest.
– Tasos
Nov 21 '18 at 18:16
1
I guess this is done on purpose, the memory is certainly handled manually latter. this is probably because you do not have access to standard malloc/free (my guess)
– OznOg
Nov 21 '18 at 18:18
Hm I do see 1 malloc() call in the code
– Tasos
Nov 21 '18 at 18:21
obviously here there are not, but I imagine this is just a demonstration sample... that said I'm just trying to guess, the board must have some documentation you may look at to get accurate info.
– OznOg
Nov 21 '18 at 18:24
|
show 6 more comments
I have this program:
__attribute__((section(".graph"))) __attribute__((aligned(16)))
uint16_t FLASH_BUFFER2[FLASH_SECTOR_SIZE];
int main ()
{
printf("Hallo World"n);
}
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
Edit : The technically correct question is "does it reserve FLASH_SECTOR_SIZE * 2 * 16 bytes in memory? (2 for uint16_t and 16 for alignment)"
c memory embedded
asked Nov 21 '18 at 18:13
TasosTasos
4761724
I have this program:
__attribute__((section(".graph"))) __attribute__((aligned(16)))
uint16_t FLASH_BUFFER2[FLASH_SECTOR_SIZE];
int main ()
{
printf("Hallo World"n);
}
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
Edit : The technically correct question is "does it reserve FLASH_SECTOR_SIZE * 2 * 16 bytes in memory? (2 for uint16_t and 16 for alignment)"
c memory embedded
c memory embedded
asked Nov 21 '18 at 18:13
TasosTasos
4761724
asked Nov 21 '18 at 18:13
TasosTasos
4761724
edited Nov 25 '18 at 19:56
Tasos
asked Nov 21 '18 at 18:13
TasosTasos
4761724
asked Nov 21 '18 at 18:13
TasosTasos
4761724
asked Nov 21 '18 at 18:13
TasosTasos
4761724
4761724
2
hum, where else do you think it could be?
– OznOg
Nov 21 '18 at 18:14
I have an embedded system with 1MB available RAM, theFLASH_SECTOR_SIZEis 65536. So this should take the entire memory. They gave me the code like this and I am wondering the same thing as you to be honest.
– Tasos
Nov 21 '18 at 18:16
1
I guess this is done on purpose, the memory is certainly handled manually latter. this is probably because you do not have access to standard malloc/free (my guess)
– OznOg
Nov 21 '18 at 18:18
Hm I do see 1 malloc() call in the code
– Tasos
Nov 21 '18 at 18:21
obviously here there are not, but I imagine this is just a demonstration sample... that said I'm just trying to guess, the board must have some documentation you may look at to get accurate info.
– OznOg
Nov 21 '18 at 18:24
|
show 6 more comments
2
hum, where else do you think it could be?
– OznOg
Nov 21 '18 at 18:14
I have an embedded system with 1MB available RAM, theFLASH_SECTOR_SIZEis 65536. So this should take the entire memory. They gave me the code like this and I am wondering the same thing as you to be honest.
– Tasos
Nov 21 '18 at 18:16
1
I guess this is done on purpose, the memory is certainly handled manually latter. this is probably because you do not have access to standard malloc/free (my guess)
– OznOg
Nov 21 '18 at 18:18
Hm I do see 1 malloc() call in the code
– Tasos
Nov 21 '18 at 18:21
obviously here there are not, but I imagine this is just a demonstration sample... that said I'm just trying to guess, the board must have some documentation you may look at to get accurate info.
– OznOg
Nov 21 '18 at 18:24
2
2
hum, where else do you think it could be?
– OznOg
Nov 21 '18 at 18:14
hum, where else do you think it could be?
– OznOg
Nov 21 '18 at 18:14
I have an embedded system with 1MB available RAM, the
FLASH_SECTOR_SIZE is 65536. So this should take the entire memory. They gave me the code like this and I am wondering the same thing as you to be honest.– Tasos
Nov 21 '18 at 18:16
I have an embedded system with 1MB available RAM, the
FLASH_SECTOR_SIZE is 65536. So this should take the entire memory. They gave me the code like this and I am wondering the same thing as you to be honest.– Tasos
Nov 21 '18 at 18:16
1
1
I guess this is done on purpose, the memory is certainly handled manually latter. this is probably because you do not have access to standard malloc/free (my guess)
– OznOg
Nov 21 '18 at 18:18
I guess this is done on purpose, the memory is certainly handled manually latter. this is probably because you do not have access to standard malloc/free (my guess)
– OznOg
Nov 21 '18 at 18:18
Hm I do see 1 malloc() call in the code
– Tasos
Nov 21 '18 at 18:21
Hm I do see 1 malloc() call in the code
– Tasos
Nov 21 '18 at 18:21
obviously here there are not, but I imagine this is just a demonstration sample... that said I'm just trying to guess, the board must have some documentation you may look at to get accurate info.
– OznOg
Nov 21 '18 at 18:24
obviously here there are not, but I imagine this is just a demonstration sample... that said I'm just trying to guess, the board must have some documentation you may look at to get accurate info.
– OznOg
Nov 21 '18 at 18:24
|
show 6 more comments
2 Answers
2
active
oldest
votes
No. __attribute__((aligned(16))) just ensures that FLASH_BUFFER2 is put on a 16-byte boundary. It will still reserve FLASH_SECTOR_SIZE * sizeof(uint16_t) bytes.
When I've used that attribute in the past, it was because the DMA controller or the mechanism used for writing to/from internal flash memory required that the RAM location be on a 16-byte boundary. Because you are doing this on an embedded system, you could be dealing with the same thing.
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
It is indeed used to a write to a FLASH and I figured the same reason
– Tasos
Nov 21 '18 at 18:54
add a comment |
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
No. Type uint16_t is 16 bits wide, not 16 bytes. Memory is indeed reserved for the array, but its size is FLASH_SECTOR_SIZE * 2 bytes.
The __attribute__ syntax you present is not part of standard C, so what it means depends on your compiler, but I see no reason whatever to think that it makes the array not actually have memory reserved for it after all, or that it changes the amount of memory reserved. Probably, __attribute__((aligned(16))) simply ensures that the start address of the array is aligned on a 16-byte boundary.
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
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%2f53418234%2fhow-much-memory-does-alignment-use-in-c%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
No. __attribute__((aligned(16))) just ensures that FLASH_BUFFER2 is put on a 16-byte boundary. It will still reserve FLASH_SECTOR_SIZE * sizeof(uint16_t) bytes.
When I've used that attribute in the past, it was because the DMA controller or the mechanism used for writing to/from internal flash memory required that the RAM location be on a 16-byte boundary. Because you are doing this on an embedded system, you could be dealing with the same thing.
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
It is indeed used to a write to a FLASH and I figured the same reason
– Tasos
Nov 21 '18 at 18:54
add a comment |
No. __attribute__((aligned(16))) just ensures that FLASH_BUFFER2 is put on a 16-byte boundary. It will still reserve FLASH_SECTOR_SIZE * sizeof(uint16_t) bytes.
When I've used that attribute in the past, it was because the DMA controller or the mechanism used for writing to/from internal flash memory required that the RAM location be on a 16-byte boundary. Because you are doing this on an embedded system, you could be dealing with the same thing.
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
It is indeed used to a write to a FLASH and I figured the same reason
– Tasos
Nov 21 '18 at 18:54
add a comment |
No. __attribute__((aligned(16))) just ensures that FLASH_BUFFER2 is put on a 16-byte boundary. It will still reserve FLASH_SECTOR_SIZE * sizeof(uint16_t) bytes.
When I've used that attribute in the past, it was because the DMA controller or the mechanism used for writing to/from internal flash memory required that the RAM location be on a 16-byte boundary. Because you are doing this on an embedded system, you could be dealing with the same thing.
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
No. __attribute__((aligned(16))) just ensures that FLASH_BUFFER2 is put on a 16-byte boundary. It will still reserve FLASH_SECTOR_SIZE * sizeof(uint16_t) bytes.
When I've used that attribute in the past, it was because the DMA controller or the mechanism used for writing to/from internal flash memory required that the RAM location be on a 16-byte boundary. Because you are doing this on an embedded system, you could be dealing with the same thing.
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
answered Nov 21 '18 at 18:35
contrapantscontrapants
600214
600214
It is indeed used to a write to a FLASH and I figured the same reason
– Tasos
Nov 21 '18 at 18:54
add a comment |
It is indeed used to a write to a FLASH and I figured the same reason
– Tasos
Nov 21 '18 at 18:54
It is indeed used to a write to a FLASH and I figured the same reason
– Tasos
Nov 21 '18 at 18:54
It is indeed used to a write to a FLASH and I figured the same reason
– Tasos
Nov 21 '18 at 18:54
add a comment |
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
No. Type uint16_t is 16 bits wide, not 16 bytes. Memory is indeed reserved for the array, but its size is FLASH_SECTOR_SIZE * 2 bytes.
The __attribute__ syntax you present is not part of standard C, so what it means depends on your compiler, but I see no reason whatever to think that it makes the array not actually have memory reserved for it after all, or that it changes the amount of memory reserved. Probably, __attribute__((aligned(16))) simply ensures that the start address of the array is aligned on a 16-byte boundary.
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
add a comment |
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
No. Type uint16_t is 16 bits wide, not 16 bytes. Memory is indeed reserved for the array, but its size is FLASH_SECTOR_SIZE * 2 bytes.
The __attribute__ syntax you present is not part of standard C, so what it means depends on your compiler, but I see no reason whatever to think that it makes the array not actually have memory reserved for it after all, or that it changes the amount of memory reserved. Probably, __attribute__((aligned(16))) simply ensures that the start address of the array is aligned on a 16-byte boundary.
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
add a comment |
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
No. Type uint16_t is 16 bits wide, not 16 bytes. Memory is indeed reserved for the array, but its size is FLASH_SECTOR_SIZE * 2 bytes.
The __attribute__ syntax you present is not part of standard C, so what it means depends on your compiler, but I see no reason whatever to think that it makes the array not actually have memory reserved for it after all, or that it changes the amount of memory reserved. Probably, __attribute__((aligned(16))) simply ensures that the start address of the array is aligned on a 16-byte boundary.
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
When I run it, does it reserve FLASH_SECTOR_SIZE * 16 bytes in memory?
No. Type uint16_t is 16 bits wide, not 16 bytes. Memory is indeed reserved for the array, but its size is FLASH_SECTOR_SIZE * 2 bytes.
The __attribute__ syntax you present is not part of standard C, so what it means depends on your compiler, but I see no reason whatever to think that it makes the array not actually have memory reserved for it after all, or that it changes the amount of memory reserved. Probably, __attribute__((aligned(16))) simply ensures that the start address of the array is aligned on a 16-byte boundary.
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
edited Nov 21 '18 at 18:56
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
answered Nov 21 '18 at 18:51
John BollingerJohn Bollinger
79.7k74175
79.7k74175
add a comment |
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%2f53418234%2fhow-much-memory-does-alignment-use-in-c%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
2
hum, where else do you think it could be?
– OznOg
Nov 21 '18 at 18:14
I have an embedded system with 1MB available RAM, the
FLASH_SECTOR_SIZEis 65536. So this should take the entire memory. They gave me the code like this and I am wondering the same thing as you to be honest.– Tasos
Nov 21 '18 at 18:16
1
I guess this is done on purpose, the memory is certainly handled manually latter. this is probably because you do not have access to standard malloc/free (my guess)
– OznOg
Nov 21 '18 at 18:18
Hm I do see 1 malloc() call in the code
– Tasos
Nov 21 '18 at 18:21
obviously here there are not, but I imagine this is just a demonstration sample... that said I'm just trying to guess, the board must have some documentation you may look at to get accurate info.
– OznOg
Nov 21 '18 at 18:24