[elektro] C aritmetika?

hg12345 hg12345 at freemail.hu
Sun Apr 4 10:15:52 CEST 2010


Nem tudom elég érhetően fogalmaztam. Ez egy tipikus C hiba, reméltem valaki ismeri a kikerülését.

Részletesen itt van.

A dolog nagyon egyszerű, a C program írói a következő feltételezéseket tették (az iskolában nem figyeltek)  16bit*16bit=16bit ez a legtöbb esetben így van... (náluk szorzás művelet eredménye egyezik, a tagok méretével, az iskolában az tanítják az eredmény mérete a két tag méretének összege.....:-)

egy kompenzációs számot szeretnék generálni IT ben, itt különösen problémás a rutin hívás, mert ilyenkor a teljes általános regiszter készletet menti, ha kell ha nem kell! 

int ASETS_DAcom; /// ICBUF32 ez egy long.....
int x;		
x = (((unsigned int)(Aset.ICBUF32>>12)) * ASETS_DAcom)>>4;

Az eredmény: 

  4D6E  804F20     mov.w Aset,w0
  4D70  804F31     mov.w 0x09e6,w1
  4D72  DD0944     sl w1,#4,w2
  4D74  DE004C     lsr w0,#12,w0
  4D76  710000     ior.w w2,w0,w0
  4D78  DE08CC     lsr w1,#12,w1
  4D7A  8050C2     mov.w ASETS_DAcom,w2
  4D7C  B98002     mul.ss w0,w2,w0
  4D7E  DE0048     lsr w0,#8,w0
  4D80  884FC0     mov.w w0,0x09f8

A mul.ss jó is, de itt az eredmény 32 bites és a felső 16 bitet nem (használja) csak az alsót shifteli, az eredmény hibás lesz....

Ha long x... akkor látszik igazán a metematikai zsenialítása (szenialítása:-)
  4D7C  B98002     mul.ss w0,w2,w0
  4D7E  DE0044     lsr w0,#4,w0
  4D80  200001     mov.w #0x0,w1  ;//itt törli a felső 16 bitet
  4D82  DD0A4C     sl w1,#12,w4
  4D84  DE0044     lsr w0,#4,w0
  4D86  720000     ior.w w4,w0,w0
  4D88  DE88C4     asr w1,#4,w1
  4D8A  884FC0     mov.w w0,0x09f8

mivel optimalizálva van a fordítás, és később csak 16 biten használom így látja, hogy nem kell csak az alsó word-t menteni. Röviden törölte shiftelte a semmit és még nem is használta.


Ha bármelyik  tényezőt cast-olom:

x = (((unsigned int)(Aset.ICBUF32>>12)) *((unsigned long) ASETS_DAcom))>>4;

  4D6E  804F20     mov.w Aset,w0
  4D70  804F31     mov.w 0x09e6,w1
  4D72  DD0944     sl w1,#4,w2
  4D74  DE004C     lsr w0,#12,w0
  4D76  710000     ior.w w2,w0,w0
  4D78  DE08CC     lsr w1,#12,w1
  4D7A  200001     mov.w #0x0,w1
  4D7C  8050C2     mov.w ASETS_DAcom,w2
  4D7E  DE91CF     asr w2,#15,w3
  4D80  07DABD     rcall __mulp32eds3
  4D82  DD0A4C     sl w1,#12,w4
  4D84  DE0044     lsr w0,#4,w0
  4D86  720000     ior.w w4,w0,w0
  4D88  DE08C4     lsr w1,#4,w1
  4D8A  DE8044     asr w0,#4,w0
  4D8C  884FC0     mov.w w0,0x09f8

Igy jó az eredmény, de még van egy halom PUSH és POP amit nem szeretnék..... kicsit tovább tart a másik tökéletesen kiszámítja de nem ismeri fel hogy még van az eredményben tartalék.

-----------------------------------------------

Nagyon nagy kár, hogy a segíteni akarnak a programozóknak minél kevesebb hibát elkövetni, ahelyett hogy megtanítanák a programozókat programozni. A C-ben a korlátok kikerülése több energiát és időt igényel mint a maga a programozás.




  
  Huu, ez kissé zavaros.
Felső 16 bit törölve?
Utána long-ban?
Castolás átteszi szoftver rutinba?
Vagy csak én vagyok nagyon gyenge?

2010/4/4 hg12345 <hg12345 at freemail.hu>:
> Hi C-ben kikerülhető valamilyen módon, hogy 16bit * 16bit eredmény valóban 32 bit legyen? MPLAB C (GCC 4.03) elvégzi a szorzást az eredmény tényleg 32 bites (ez HW csinálja) majd ami biztos alapon a gyorsan törli a felsö 16 bitet és az így kapott eredményt tárolja egy long változóban. A művelet elött castolom akkor jó az eredmény, nem véletlen mert 32b * 322b szorzást csinál és HW helyet szubrutin.... A fordító program írói nem ismerték a szorzás tulajdonságát?!  Üdv
>
> Fuzesi Arnold <arnold.fuzesi.lista at gmail.com> írta:
>>Mindegymihez, c-ben kellene.
>>
>>Bsd-s tipp ugy nez ki jolesz, koszi!!
>>
>>
>>Arnold
>>
>>
>>On 2010.04.04., at 1:39, Pipi <lista at puzsar.hu> wrote:
>>
>>> 2010.04.03. 20:23 keltezéssel, Fuzesi Arnold írta:
>>>> Sziasztok!
>>>>
>>>> Hol talalok strcpy strcmp stb stb forrásokat!?
>>> mihez?
>>> pl c:\MCC18\src\extended\stdclib\strcpy.asm
>>>
>>>
>>>
>>> --
>>> Pipi
>>> http://www.puzsar.hu
>>>
>>> -----------------------------------------
>>>          elektro[-flame|-etc]
>>
>>-----------------------------------------
>>          elektro[-flame|-etc]
> -----------------------------------------
>          elektro[-flame|-etc]
>

-----------------------------------------
          elektro[-flame|-etc]



More information about the Elektro mailing list