AVR a dva seriaky

[milan]

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
>