Precautions for using bitfield struct variables in programming of mainstream controllers (such as arm and DSP)

Source: http://blog.csdn.net/peasant_lee/article/details/5592190

Many people engaged in electronic software programming are getting started with 51 single-chip microcomputer or other low-end single-chip microcomputer, which is very short of SRAM. As we all know, 51 single-chip microcomputer has a bit addressing space, and the corresponding development environment Keil C51 certainly also supports bit variables. With the development of electronic chip products, the current main controller Lin has made great improvements in both the SRAM space and the coed space. The current SRAM is just a few K and dozens of K. The bit addressing function of 51 single-chip microcomputer has never been inherited and has become an antique. In actual programming applications, some information does not need to occupy a complete byte during storage,
It takes only a few or one binary bit. For example, many variables, especially flags, do not need to occupy a byte space. Common examples: Only one bit of bool variable (0 or 1 ). So what should we do if we need a variable that is less than a byte space for saving the SRAM storage space instead of 51 Single-Chip Microcomputer compiling environment? Bitfield struct comes in handy. A bitfield struct is called a bitfield or a bitfield ". The so-called "bit field" refers to dividing the binary character in a byte into several different regions and showing the digits of each region. Each domain has a domain name, which allows operations by domain name in the program. In this way, several different objects can be represented by a byte binary field.

The declaration of bitfield struct is as follows:

 

Struct bit domain structure name

{Type specifier Domain Name: Bit domain length };

　

For example:

Struct bitzone
{
Int A: 8;
Int B: 2;
Int C: 6;
};

 

Of course, there are other default bit domain names and bit domain lengths. What do you mean? You can refer to other materials and many of them are explained.

The definition of bitfield struct variables is the same as that of calling the same struct variables. It is estimated that everyone is familiar with it. I will not talk about it here, but what I want to say is, the bitfield struct can undoubtedly save some variable storage space. However, because many controllers, such as DSP, arm, and other high-end single-chip microcomputer, do not have a location-addressable area, they need to implement a data structure similar to a location operation, you need to perform operations such as bit & or shift on the byte where the current BIT is located. In this case, whether the code is beautiful or not, the amount of generated code is too large, and the CPU cycle is too large. In other words, to save this SRAM, the cost is that the Code is bloated and the machine runs slowly. I have tested DSPs and ARM development environments. How can we choose between them? Let's take a look at the specific situation.
Nervous, the Code is not tight, and it doesn't matter if you slow down a few machine cycles. Use it for that line. If you are all nervous, and the CPU is very busy and cannot be busy any more, you have to make a compromise. The so-called "fish and bear's paw" cannot have both sides.

 

//////////////////////////////////////// ///////////////////////////////////

 

The following is an example of code I wrote a long time ago to show my evidence:

 

//////////////////////////////////////// ///////////////////////////////////

 

Case 1: The structure below defines the bitfield struct.

Typedef struct _ decode_parameter

{

Uint16 selectindex;

Uint16 decodeindex;

............

............

Struct _ bit

{

Uint16 fileover: 1;

Uint16 validname: 1;

Uint16 playstatus: 2;

................

................

................

} Bit;

 

} Decode_parameter;

 

//////////////////////////////////////// ///////////////////////////////////

 

Case 2: The following struct does not contain bitfield variables.

Typedef struct _ decode_parameter

{

Uint16 selectindex;

Uint16 decodeindex;

// Remove the bit fields above. Each bit field directly defines the bit char variable:

Uint8 fileoverflag;

Uint8 validname;

Uint8 playstatus;

.......................

.......................

 

} Decode_parameter;

 

//////////////////////////////////////// ///////////////////////////////////

 

Compare instances: make the same judgment during use.

 

//////////////////////////////////////// ///////////////////////////////////

 

Case 1: If (side. Bit. fileover & side. Bit. validname & side. Bit. playstatus)

The generated assembly code is:

0x08004632 48e4 LDR r0, [PC, #912]; @ 0x080049c4

0x08004634 f8b00044 ldrh r0, [r0, #0x44]

0x08004638 f3c00000 ubfx r0, R0, #0, #1

0x0800463c b310 CBZ r0, 0x08004684

0x0800463e 48e1 LDR r0, [PC, #900]; @ 0x080049c4

0x08004640 f8b00044 ldrh r0, [r0, #0x44]

0x08004644 f3c01000 ubfx r0, R0, #4, #1

0x08004648 b1e0 CBZ r0, 0x08004684

0x0800464a 48de LDR r0, [PC, #888]; @ 0x080049c4

0x0800464c f8b00044 ldrh r0, [r0, #0x44]

0x08004650 f3c01041 ubfx r0, R0, #5, #2

0x08004654 b1b0 CBZ r0, 0x08004684

 

//////////////////////////////////////// ///////////////////////////////////

 

Case 2: If (side. fileover & side. validname & side. playstatus)

The generated assembly code is:

0x0800421c 48c5 LDR r0, [PC, #788]; @ 0x08004534

0x0800421e f8900044 ldrb r0, [r0, #0x44]

0x08004222 b1b8 CBZ r0, 0x08004254

0x08004224 48c3 LDR r0, [PC, #780]; @ 0x08004534

0x08004226 f8900048 ldrb r0, [r0, #0x48]

0x0800422a b198 CBZ r0, 0x08004254

0x0800422c 48c1 LDR r0, [PC, #772]; @ 0x08004534

0x0800422e f8900049 ldrb r0, [r0, #0x49]

0x08004232 b178 CBZ r0, 0x08004254

 

See the difference? Obviously, 2 has three fewer commands. It is obvious that the unique ubfx (bit segment extraction) command of crotex m3 is added. If you are interested in other compilation Code commands, check relevant information. You may think that in the hundreds of M or hundreds of M CPUs, the three instruction cycles are nothing, so it is wrong, if the judgment is in the main cycle with a very frequent cycle (the only way to go for each main cycle), a command contains several machine cycles, then these cycles, it is true that there is more than one product. I also personally tested the difference between the two methods in MP3 decoding and playback.