[英]STM32 gcc optimization produces different result
我正在嘗試使用 STM32F4(SW4STM32 IDE 中的 gcc)將 RGB 緩沖區解碼為適合 LED RGB 矩陣的行。 下面的代碼在設置編譯器優化 -O0 時完美運行。
使用 -O1 優化編譯時,代碼會產生不同的結果。 (還有-O2、-O3)。 當使用-O1 .
優化設置為this.c文件而已,其他文件還是-O0。
有人能發現為什么優化會改變代碼邏輯/行為嗎?
uint8_t badr[24576] = { 0xff , 0x2a, .... };
struct s_color_t
{
uint8_t r;
uint8_t g;
uint8_t b;
} ;
//__attribute__((packed))
typedef struct s_color_t color_t;
#define WIDTH 128
#define HEIGHT 64
#define COLOR_SIZE sizeof(color_t)
#define R0_POS 0x01
#define G0_POS 0x02
#define B0_POS 0x04
#define R1_POS 0x08
#define G1_POS 0x10
#define B1_POS 0x20
#define enc_color(c, s, r) (c & s)? r : 0
color_t dispBuf[ WIDTH * HEIGHT];
uint8_t dispLine[WIDTH];
void fillBuf()
{
uint8_t *dbuf = (uint8_t *) dispBuf;
memcpy(dbuf, badr, WIDTH * HEIGHT * COLOR_SIZE);
}
void enc_row(uint8_t slice, uint16_t row, uint8_t *rBuf)
{
uint8_t reg;
color_t *upPtr = dispBuf + row * WIDTH * COLOR_SIZE;
color_t *dnPtr = dispBuf + (row + (HEIGHT / 2)) * WIDTH * COLOR_SIZE;
uint8_t *destPtr = rBuf;
uint8_t sn = (1 << slice);
for (int i=0; i < WIDTH; i++) {
reg = 0;
reg |= enc_color((*upPtr).r, sn, R0_POS);
reg |= enc_color((*upPtr).g, sn, G0_POS);
reg |= enc_color((*upPtr).b, sn, B0_POS);
reg |= enc_color((*dnPtr).r, sn, R1_POS);
reg |= enc_color((*dnPtr).g, sn, G1_POS);
reg |= enc_color((*dnPtr).b, sn, B1_POS);
*destPtr = reg;
upPtr ++;
dnPtr ++;
destPtr ++;
}
}
void do_func()
{
uint8_t *ptrLine = dispLine;
fillBuf();
for (int s=0; s < 8; s++) {
for (int i=0; i< (HEIGHT/2); i++) {
enc_row(s, i, ptrLine);
printf("line %3i ", i);
for(int c=0; c<WIDTH; c++) {
printf("%02X, ", ptrLine[c] & 0xFF);
}
printf("\r\n");
}
}
}
謝謝贊猞猁。 事實上,如果一個人計划稍后使用優化,他應該設置檢查點來驗證代碼是否產生與優化相同的結果。
上面的錯誤結果是指針計算造成的。 我將上面的兩個語句替換為:
upPtr = &dispBuf[row * WIDTH];
dnPtr = &dispBuf[(row + (HEIGHT / 2)) * WIDTH];
在調試期間(打開優化),刪除了幾個函數(即操作由編譯器完成。)
說到嵌入式,與其他設備的接口信號也可能會改變速度。 您可能會超頻或更短的脈沖。
使用 -O1,代碼執行時間減少了 60%。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.