AVR a dva seriaky
milan
milan@bastl.sk
Pátek Prosinec 12 11:29:38 CET 2008
ASM v ziadnom pripade nie je prezity. To je ako by ste tvrdili, ze
instrukcie CPU su prezite - ved ASM je iba ich symbolicky zapis. Akurat
ze dnes nie je tak casto nutne ho pouzivat.
Jasne som povedal, nastroj treba spravne zvolit. Ak sa robi GUI v ASM -
chybne zvoleny nastroj. C v aplikacii kritickej na casovanie (ako
napriklad sw UART) - chybne zvoleny nastroj.
S tou efektivitou to tiez nebyva vzdy ruzove. Kolko casu clovek dokaze
zabit hladanim sposobu, ako prinutit kompilator aby urobil kod kratsi
alebo rychlejsi? V mnohych pripadoch je prepisanie kritickej casti do
ASM je efektivnejsie.
A ono to nie je vzdy len o efektivite, dnes sa zabuda hlavne na kvalitu.
Zatlkat sroby kladivom je urcite rychlejsie a efektivnejsie, ale nie je
to to prave orechove.
Ja dolozim iny priklad - riesil som rychle citanie z SD karty cez SPI na
Atmega64 - muselo to byt cez prerusenia, aby sa stihal obcerstvovat
display. C nemalo sancu. Prepisanie prerusovacej rutiny do ASM (plus par
trikov) - 6-nasobne urychlenie.
Ze budete s elektrickym srobovakom rychlejsi? Urcite, v mnohych
pripadoch ano. Ale nie vzdy. A zatial co vy budete hladat sposob ako sa
s nim dostat do uzkej medzery, ja so svojim klasickym srobovakom budem
davno hotovy ...A to "nie vzdy" ide.
M.
Martin Moštěk wrote:
> Dulezity je cil a ne nastroje - s tim nezbyva nez souhlasit, ale zkuste
> se na to prosim podivat i z pohledu efektivity sve prace. Pokud totiz
> budu delat vetsi projekt v C, tak cas nezbytne nutny k dosazeni uspechu
> bude nesporne kratsi, nez tvorba projektu v ASM.
> Toto sve tvrzeni rad dolozim praktickou zkusenosti ze zivota : Muj
> zamestnavatel je dodavatel leteckych pristroju a jeden tento typ
> pristoje (palivomer) byl vyvijen v ASM, doba na vyvoj byla 2 roky.
> Jelikoz se vsak ke konci vyvoje objevily jiste problemy (chyby v ASM v
> zavislosti na HW) byl nakonec obdobny palivomer postaven na jinem CPU
> ovsem v C. Vyvoj byl delan komplet znovu (na zelene louce) jinym
> clovekem, doba potrebna na vyvoj - 1 rok.
> Vim, ze jeden priklad nerika vse, ale kdyz si vypujcim Vase prirovnani -
> s elektrickym sroubovakem budu mit hotovo driv nez s rucnim.
>
> Nikomu nenutim C, pouze konstatuji, ze ASM jako takove je jiz mirne
> prezite, i kdyz pripoustim, ze se bez nej nebude nejspis nikdy obejit,
> napriklad v DSP pro FFT a podobne rychle zalezitosti.
>
> Cele toto moje psani od zacatku smerovalo k zastani se pisatele
> puvodniho subjektu, ktery spravne vypozoroval, ze s C je vyvoj mnohem
> snazsi, rychlejsi a pri pouziti dobreho C -> ASM prekladace i efektivni.
> Martin.
>
>
> milan napsal(a):
>
>> Vidite. a pre ten soft UART plati pravy opak - "nie je otazka ci sa
>> vratit od C k ASM, ale otazka je kedy".
>>
>> Inac, vase argumenty su uplne pomylene. Na kazdom projekte ma byt
>> dolezity ciel, a nie nastroje. Inymi slovami - potrebujem dosiahnut
>> nejaky vysledok a podla toho zvolim nastroje. Niekde staci
>> interpretovany BASIC, niekde C a niekde je treba assembler.
>>
>> Uvediem iny ekvivalent vasej argumentacie: Pouzivat obycajny srobovak je
>> prezitok, vsak mame elektricke. A ak nieco praskne, dame tam hrubsi
>> material, ak sa niekam nevleze, urobime vacsiu skrinu. A pritom s
>> obycajnym rucnym srobovakom ziaden problem...pekna blbost, vsak? :)
>>
>> Ak dovolite, aby o projekte rozhodoval nastroj, zatvarate si cestu pri
>> hladani optimalnych rieseni - a vysledkom moze byt vzpominane video
>> alebo DVD rekorder Samsung, kde pri vypinani sa 3 sekundy nic nedeje,
>> potom sa objavi napis OFF a potom sa vypne.
>>
>> To, ze takyto pristup je dnes bezny, patri medzi velke tragedie sucasnosti.
>>
>> Tak, a mame flame na piatok :)
>>
>> Milan
>>
>>
>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list@list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
Další informace o konferenci Hw-list