Not applicable
Jun 25, 2013
01:06 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 25, 2013
01:06 AM
Hi All,
Many of the DAVE examples and apps specify variables of type uint8_t and uint16_t. I am just migrating from the 8 bit 8051 world to the 32 bit ARM world and I would normally use the smallest size variable type where possible.
So I am wondering if there is any advantage in declaring variables in my own code smaller than uint32_t or int32_t for the 32 bit xmc4500.
Any advice greatly appreciated.
Aaron
Many of the DAVE examples and apps specify variables of type uint8_t and uint16_t. I am just migrating from the 8 bit 8051 world to the 32 bit ARM world and I would normally use the smallest size variable type where possible.
So I am wondering if there is any advantage in declaring variables in my own code smaller than uint32_t or int32_t for the 32 bit xmc4500.
Any advice greatly appreciated.
Aaron
- Tags:
- IFX
5 Replies
Not applicable
Jun 25, 2013
02:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 25, 2013
02:48 AM
Hi Aaron Walsh,
You could save some memory space when using possible smallest size variable type. But if you use DAVE Apps, you need to match the variable type defined in API. Are you really concern abouth the memory space?
Best regards,
Zain
You could save some memory space when using possible smallest size variable type. But if you use DAVE Apps, you need to match the variable type defined in API. Are you really concern abouth the memory space?
Best regards,
Zain
Not applicable
Jun 25, 2013
05:52 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 25, 2013
05:52 AM
Hi Zain,
Thanks for your reply. No I'm not really concerned about the memory space, my choice would be to use 32 bit variables throughout my code unless forced to do otherwise by DAVE apps etc.
I'm wondering if more instructions are required to cast to and from uint8_t rather than just use uint32_t. What are the advantages / disadvantages of declaring less than 32 bit ?
Here is an example structure from the DAVE App ADC001 showing uint8_t and uint16_t declarations...
typedef struct ADC001_ResultHandleType
{
uint8_t GroupNo;
uint8_t ChannelNo;
uint16_t Result;
}ADC001_ResultHandleType;
Best regards
Aaron
Thanks for your reply. No I'm not really concerned about the memory space, my choice would be to use 32 bit variables throughout my code unless forced to do otherwise by DAVE apps etc.
I'm wondering if more instructions are required to cast to and from uint8_t rather than just use uint32_t. What are the advantages / disadvantages of declaring less than 32 bit ?
Here is an example structure from the DAVE App ADC001 showing uint8_t and uint16_t declarations...
typedef struct ADC001_ResultHandleType
{
uint8_t GroupNo;
uint8_t ChannelNo;
uint16_t Result;
}ADC001_ResultHandleType;
Best regards
Aaron
Not applicable
Jun 28, 2013
02:39 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 28, 2013
02:39 AM
Hi Aaron,
You may refer to Cortex-M3 Processor web page to understand the reason of declaring uint8_t, uint16_t. (http://www.arm.com/products/processors/cortex-m/cortex-m3.php)
Look for "Instruction width" & "Compact data footprint" under "Moving from 8/16-bit" tab.
Here are some highlights:
1) The ARM Cortex-M processors utilize the ARM Thumb®-2 technology which makes Cortex-M processors support a fundamental base of 16-bit Thumb instructions. In many cases a C compiler will use the 16-bit version of the instruction unless the operation can be carried out more efficiently using a 32-bit version.
2) Cortex-M processors have support for 8-bit and 16-bit data transfers, making efficient use of data memory. This means programmers can continue to use the same data-types as they have in 8/16-bit targeted software.
Best regards,
Sophia
You may refer to Cortex-M3 Processor web page to understand the reason of declaring uint8_t, uint16_t. (http://www.arm.com/products/processors/cortex-m/cortex-m3.php)
Look for "Instruction width" & "Compact data footprint" under "Moving from 8/16-bit" tab.
Here are some highlights:
1) The ARM Cortex-M processors utilize the ARM Thumb®-2 technology which makes Cortex-M processors support a fundamental base of 16-bit Thumb instructions. In many cases a C compiler will use the 16-bit version of the instruction unless the operation can be carried out more efficiently using a 32-bit version.
2) Cortex-M processors have support for 8-bit and 16-bit data transfers, making efficient use of data memory. This means programmers can continue to use the same data-types as they have in 8/16-bit targeted software.
Best regards,
Sophia
Not applicable
Jul 01, 2013
09:22 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 01, 2013
09:22 AM
Thank you as usual Sophia.
Not applicable
Jul 17, 2013
12:25 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 17, 2013
12:25 AM
This all makes sense now. 8 and 16 bit variables can be used. There is no advantage in terms of memory used, they just roll over at 255 and 65535 (even though they are in 32 bit memory locations).
A quick experiment shows that code size is the same for manipulating 8, 16 and 32 bit variables unless casting is required.
The example below shows that adding 32 bit numbers requires the same number of instructions as adding 8 bit numbers. Adding an 8 bit number to a 32 bit number also requires the same number of instructions.
However, adding a 32 bit number with casting to an 8 bit number requires 2 more instructions.
Best regards
Aaron
A quick experiment shows that code size is the same for manipulating 8, 16 and 32 bit variables unless casting is required.
The example below shows that adding 32 bit numbers requires the same number of instructions as adding 8 bit numbers. Adding an 8 bit number to a 32 bit number also requires the same number of instructions.
However, adding a 32 bit number with casting to an 8 bit number requires 2 more instructions.
uint32_t Var32_A;
uint32_t Var32_B;
uint8_t Var8_A;
uint8_t Var8_B;
Var32_A += Var32_B;
0x08004316 fa 68 ldr r2, [r7, #0xc]
0x08004318 bb 68 ldr r3, [r7, #0x8]
0x0800431a d3 18 add r3, r2, r3
0x0800431c fb 60 str r3, [r7, #0xc]
Var8_A += Var8_B;
0x0800431e fa 79 ldrb r2, [r7, #0x7]
0x08004320 bb 79 ldrb r3, [r7, #0x6]
0x08004322 d3 18 add r3, r2, r3
0x08004324 fb 71 strb r3, [r7, #0x7]
Var32_A += Var8_B;
0x08004326 bb 79 ldrb r3, [r7, #0x6]
0x08004328 fa 68 ldr r2, [r7, #0xc]
0x0800432a d3 18 add r3, r2, r3
0x0800432c fb 60 str r3, [r7, #0xc]
Var8_A += (uint8_t)Var32_A;
0x0800432e fb 68 ldr r3, [r7, #0xc]
0x08004330 da b2 uxtb r2, r3
0x08004332 fb 79 ldrb r3, [r7, #0x7]
0x08004334 d3 18 add r3, r2, r3
0x08004336 fb 71 strb r3, [r7, #0x7]
Best regards
Aaron