[elektro] C kérdés

[SZIGETI Szabolcs]

Nem akarok beleszólni (de!), mert nem tanulmányoztam a kódot nagyon,de pár
dolgot nem értek. Ha jól értem, itt bitenként akarsz kivinni egy bájtot.
Miért kell begyömöszölni, egy inte, majd ott shiftelni és mindenféle fura
pointerbűvészkedéssel nézegetni a már egyet shiftelt legnagyobb
helyiértéket? Az ilyen fura dolgokkal általában nem tud mit kezdeni az
optimalizáló. Miért nem jó az, hogy
U_int8 shift;
...
if (új érték kell) {
       shift = *p++;}
color = shift & 0x80 ? pcolor : bcolor;
shift =<<1;
LCD_HW_OUT_DATA(color);
...

Esetleg még a belső bitshiuftelő részt egy külön 0-7ig menő ciklusba
szervezhetnéd, ez is segíthet az optimalizálón. Persze ekkor meg kell
oldalni, hogy mi legyen a maradékkal, ha nem 8 többszöröse az x mérete.

De ezek csak úgy tippek, sok más -szerintem- jóval áttekinthetőbb megoldás
is lehetne. Ami szemmel áttekintehető, annak az optimalizáló is örülni
szokott, ez a tapasztalatom.

Szabolcs


2015. június 8. 14:29 hg12345 írta, <hg12345 at freemail.hu>:

> Hi, azt hitem érthető amit írtam... Röviden közvetlenül a C nem kezeli az
> átvitel "C" a status regiszterben.Ezért ha kiszeretnél shiftelni egy
> változót (regisztert) akkor azt a ZERO flagre vezeti vissza, ez nem jár sok
> plusz munkával csak feleslegesen shiftel (ez manapság nem gond, mert
> mindegy, hogy mennyi a shift egy lépésben megteszi) de utána van egy
> maszkolás és egy feltételes elágazás. A maszkoláshoz egy másik regiszter is
> igénybe kell venni. Ez se probléma, de pont ebben az esetben a két
> színkódból csak ez egyiket tudja regiszterben tartani!Ez minimum 2 vagy 3
> utasítással több mint kéne. Egy nagyobb méretű kijelző esetén
> másodpercenként több millió utasítás....Maga a részlet összesen két
> lépésből áll asm-ben, egy shiftelés és "C" szerinti ugrás......  void
> LCD_BmpC1(uint16_t x, uint16_t y, uint16_t xsize, uint16_t ysize,  uint16_t
> pcolor,  uint16_t bcolor, uint8_t *p )  //2 color BMP
> {
>   unsigned int shift;
>   unsigned int xi,yi;
>   unsigned int color;
>   LCD_SetWindows(x,y,x+xsize-1,y+ysize-1);     //blokk beállítása
>   LCD_HW_CS_CLR;
>   for(yi=0;yi<ysize;yi++)
>   { for(xi=0;xi<xsize;xi++)
>     {     if ((xi&0x7)==0 )                   //new byte read
>       { shift=*p++; }
>       shift<<=1;
>       color=bcolor;
>       if ((((unsigned char*)&shift)[1])&0x01)
>         color=pcolor;
>       LCD_HW_OUT_DATA(color);
>     }
>   }
> //  LCD_HW_CS_SET;
>   LCD_SetDisplayEnd();
> }A legtömörebb kódot -O3 és -Otime adja, de amit produkál, amit csinál
> annál jobbat nem nehéz csinálni. A fenti kódot nem lehet megcsinálni
> DMA-val, kivéve ha olyan DMA van a rendszerben ami kezel a shitet és mellé
> még lookup táblát is
> használ.----------------------------------------------------------------------------------------------------------------------------------------------------Nem
> akarom felülírni a C kódot, amit fordít az teljesen megfelelő számomra.De
> néhány sor miatt elegendő lehetne egy fele sebességű uC-rel is. Az
> esetemben egy járatosabb uC típus lenne.
> Lajos Rancz <lajos.rancz at gmail.com> írta:
> >Helló!
> >
> >Ebből nem sokat lehet érteni.
> >
> >Üdv
> >
> >
> >
> >2015. június 8. 12:34 hg12345 írta, <hg12345 at freemail.hu>:
> >
> >> Hi, van megoldás, hogy C forrás szinten ASM betét nélkül a C-t
> >> használja.Egy kétszínű BMP/FONT képet éni maximális teljesítménnyel
> >> megjeleníteni.Bizonyos sebesség felett már nem a kiküldés korlátozza a
> >> megjelenítési sebességet, hanem a program.Maga a kép kishiftelő
> >> algoritmusban van a nulla tesztelés visszavezetése miatt kb 30-40%
> >> tartalék... jó lenne ezt kihasználni. ASM betétben nem gond, de
> >> szimpatikusabb lenne hordozható kivitelben. Ismereteim szerint ez nem
> >> lehetséges, de a remény hal meg utoljára...........
> >> -----------------------------------------
> >>           elektro[-flame|-etc]
> >-----------------------------------------
> >          elektro[-flame|-etc]
> -----------------------------------------
>           elektro[-flame|-etc]