2012-06-03 77 views
0

對此問題進行了一點介紹,
在我發佈此文檔之前,我試圖在google/stack上搜索這些內容,但大多數內容都不清楚。
我有一個基於cortex-a8的電路板,我正在其上運行裸機RTOS,顯示器(framebuffer)有點慢,因爲我目前還沒有爲我的目標實現DMA,但並不是那麼慢,但是我注意到了一個改進的機會。在我的CPU和工具鏈組合中,32位數學運算,數據訪問比16位訪問快,顯示器是16位rgb565,所以一些framebuffer操作比他們可能會慢一些(其中一些使用memcpy,memmove和memset,其中照顧數據對齊等)。在單個更大的數據類型中存儲兩種數據類型

我試圖將兩個像素塞進一個32位數據類型,並使用它來訪問內存(對齊,據我記得,即使不,我的CPU在硬件中支持未對齊的內存訪問,所以問題不應該是這樣的)。請注意,我不是在談論我的實現速度,而是我得到的一個奇怪的影響,我懷疑是因爲我如何將兩個像素塞入到一個32位數據類型。

這裏是我的fb_putc

if (((unsigned char)c > 32) && ((unsigned char) c < 127)) { 
    check_for_scroll(49); 

    // fontdata starts from ASCII 33 shifted by logarithm(base2, font_height) 
    c -= 33; 
    c <<= 4; 

    uint16_t pallete_16[2] = {fb.fg_color, fb.tg_color}; 

    uint32_t y; 
    uint32_t *pixel_32; 
    uint32_t fb_shifter; 
    uint32_t pixel_32_holder; 
    uint32_t fb_bg_32 = ((pallete_16[1] << 16) | (pallete_16[1])); 
    /* 
    * Each pixel is 16 bits, we access them using 32 bit data type, 
    * which is faster for aligned memory access. Also many architectures 
    * have free bit shifts with each instruction so we use that too. 
    */ 
    pixel_32 = (uint32_t *) fb.config->base; 
    pixel_32 += (((fb.cursor.y * (FONT_HEIGHT * fb.config->width)) + ((fb.cursor.x * (FONT_WIDTH)))) 
        /((sizeof(uint32_t))/(sizeof(uint16_t)))); 
    for (y = 0; y < 16; y++) { 
     for (unsigned x = 7; x >= 0; x -= 2) 
     { 
      if (fontdata[c + y] & (1 << x)) { 
       pixel_32_holder = (pallete_16[0] << 16); 
      } else { 
       pixel_32_holder = (pallete_16[1] << 16); 
      } 
      if (fontdata[c + y] & (1 << (x -1))) { 
       pixel_32_holder |= (pallete_16[0] & 0xffff); 
      } else { 
       pixel_32_holder |= (pallete_16[1] & 0xffff); 
      } 
      *pixel_32++ = pixel_32_holder; 
     } 
     // Panel stride = width (480) - font_width (8) 
     pixel_32 += (472/((sizeof(uint32_t))/(sizeof(uint16_t)))); 
    } 

    fb.cursor.x++; 
} 

關於我哪裏錯了任何幫助的大部分?我對編程有點新,並且以此爲愛好。

回答

1

你的想法在將它們寫入存儲器之前組合2個像素是正確的。 ARM的寫緩衝硬件將以這種方式更高效地使用,代碼運行速度更快。我不認爲以這種形式混合C和ASM會產生最好的結果。堅持純粹的ASM將保證你使用有條件執行的指令。另外,爲調色板使用數組可能會導致編譯器輸出非常低效的代碼。這是一種在純ASM中更高效地執行此操作的方法。展開循環是一個好主意。這是處理雙字節字體數據的每個字節的代碼。

@ Register usage 
@ R0 = source data pointer 
@ R1 = destination data pointer 
@ R2 = foreground color (loaded outside of loop) 
@ R3 = background color (loaded outside of loop) 
@ R4,R5 = temp registers 
@ Assumes that the most significant short of each 32-bit word is on the left 

    ldrb r4,[r0],#1 @ source bitonal image data 
@ first pair of pixels 
    tst r4,#0x80 
    movne r5,r5,r2,LSL #16 
    moveq r5,r5,r3,LSL #16 
    tst r4,#0x40 
    orrne r5,r5,r2 
    orreq r5,r5,r3 
    str r5,[r1],#4 
@ second pair of pixels 
    tst r4,#0x20 
    movne r5,r5,r2,LSL #16 
    moveq r5,r5,r3,LSL #16 
    tst r4,#0x10 
    orrne r5,r5,r2 
    orreq r5,r5,r3 
    str r5,[r1],#4 
@ third pair of pixels 
    tst r4,#0x8 
    movne r5,r5,r2,LSL #16 
    moveq r5,r5,r3,LSL #16 
    tst r4,#0x4 
    orrne r5,r5,r2 
    orreq r5,r5,r3 
    str r5,[r1],#4 
@ fourth pair of pixels 
    tst r4,#0x2 
    movne r5,r5,r2,LSL #16 
    moveq r5,r5,r3,LSL #16 
    tst r4,#0x1 
    orrne r5,r5,r2 
    orreq r5,r5,r3 
    str r5,[r1],#4 

更新稍微簡單的代碼

+0

從我相信,第二個指令應該歸零R5,但爲什麼呢?感謝您的幫助和努力。 – sgupta

+0

哦,明白了,所以你在使用r5來臨時存儲合併的結果之前..應該在寫之前完全閱讀。 再次感謝。 – sgupta

0

我已經修復了在過去幾個小時內編譯器吃掉我的頭後,通過使用asm一次存儲兩個像素,但現在似乎還有一些其他問題,因爲字符出現亂碼,除了少數幾個,我我不知道世界是什麼原因造成這個...

至於包裝中的像素,這是我最後使用的(只是櫃面有人在未來可能需要這樣做)

if (((unsigned char)c > 32) && ((unsigned char) c < 127)) { 

    check_for_scroll(FB_MAX_Y_UNDER); 

    uint32_t pixel_32_tmp; 
    uint16_t pallete[2] = { (fb.fg_color), (fb.tg_color)}; 
    uint32_t *pixel_32 = (uint32_t *)fb.base +((((fb.cursor.y << 13)-(fb.cursor.y << 9))+(fb.cursor.x << 3)) >> 1); 

    c -= 32; 
    c <<= 4; 

    for (int y = 0; y < 16; y++) { 
     unsigned char font_bits = fontdata[c + y]; 

     if (font_bits & 0x80) { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     if (font_bits & 0x40) { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     *pixel_32++ = pixel_32_tmp; 

     if (font_bits & 0x20) { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     if (font_bits & 0x10) { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     *pixel_32++ = pixel_32_tmp; 

     if (font_bits & 0x08) { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     if (font_bits & 0x04) { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     *pixel_32++ = pixel_32_tmp; 

     if (font_bits & 0x02) { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("mov %0, %1, lsl $16" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     if (font_bits & 0x01) { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[0])); 
     } else { 
      __asm__ volatile("orr %0, %0, %1" : "=r" (pixel_32_tmp) : "r" (pallete[1])); 
     } 
     *pixel_32++ = pixel_32_tmp; 

     pixel_32 += 236; 
    } 
    fb.cursor.x++; 
}