rpal napisał: Wówczas takie programowanie przestaje się znacząco różnić od zwykłego C.
Tia... a tworzenie zmiennych, zmienianie ich rozmiarów i dynamiczna alokacja pamięci są nawet prostsze (;
Do niektórych zastosowań assembler ma sens, ale tych zastosowań jest coraz mniej - niestety lub stety - zależy co kto lubi. Ja początkowo uważałem, że assembler jest najlepszy i koniec. No może i tak jest, ale do pewnych części programu, bo pisanie całości kodu w asm nie ma najmniejszego sensu.
Jeśli ktoś chce liczyć transformatę fouriera w C++, to jest to głupi pomysł, bo dobrze napisany kod w asm będzie kilkudziesięciokrotnie szybszy i mniejszy. Jeśli jednak ktoś w asm próbuje pisać na przykład warstwę obsługi programu - menu (wielopoziomowe), jakieś graficzne bajery na wyświetlacze graficzne - to raczej sztuka dla sztuki.
W C, gdy okaże się, że jednak lepiej policzyć coś na liczbach 16-bitowych wystarczy zmienić pare literek, a kompilator zadba o resztę (jeśli kod jest dobrze napisany). W asm taka operacja to droga przez mękę... Czy ktoś już stworzył odpowiednik funkcji printf w asm? <:
Swego czasu, gdy pisałem algorytm rysowania na wyświetlaczu graficznym (640x480) skośnej linii, udało mi się po długich bojach stworzyć go w 100% w assemblerze. Wykonanie jednej linii trwało (mniej więcej) 3000 cykli. Napisany w kilkukrotnie krótszym czasie algorytm w C (o wiele prostszy!) zajmował procesorowi o 2% więcej czasu...
Dodam również, że całe życie nie lubiałem programowania obiektowego, ale ostatnio tak mnie urzekł C#, że chyba będę musiał spróbować zaprząc Cortexa do wykonywania kodu w C++. Bo owszem - pełną kontrolę nad czasem to może się w asm ma, ale nad» tym co się dzieje w całym programie już o wiele mniejszą niż w C, czy C++. Żeby zmasakrować stos w C trzeba napisać naprawdę kiepski program. Żeby totalnie wywalić procesor, trzeba się naprawdę postarać. Żeby to samo osiągnąć w asm wystarczy zapomnieć o jednej rzeczy (łatwej do przeoczenia) i już jest po sprawie...
No ale co kto lubi. Jedni wolą całość - szybki, bezpieczny i efektowny program, inni wolą grzebać się w ręcznym przydzielaniu pamięci ze stosu dla funkcji pisanych w asm.
Prawda jest taka - niestety - że im język jest wyższego poziomu, tym kod w nim stworzony jest bezpieczniejszy - to tak apropo przykładu z urządzeniem z sali operacyjnej. W extremalnych przypadkach - jak ADA - w ogóle żeby popełnić jakiś błąd trzeba się nagimnastykować. W językach zarządzalnych - C# czy Java - środowisko eliminuje odwieczny problem wycieku zasobów. W językach wysokiego poziomu - C, C++ - kod jest połączeniem niskiego poziomu jak i wygody nowoczesnego programowania. A assembler? Hmm... Przypadkiem ktoś skasuje jedną literkę (komu się nie zdaża czasem źle kliknąć i rozwalić tekstu?) i na 90% program leci w maliny (złe zdejmowanie zmiennych ze stosu, powrót pod losowy adres i tym podobne rewelacje). Podobny błąd w C - w 90% przypadków program po prostu nie będzie działał właściwie, ale jedynie w uszkodzonej części lub innych - zależnych od niej.
Pół biedy jeśli program idzie w maliny od razu, ale co jeśli program co minutę traci 1 bajt pamięci przez błąd programisty? A co jeśli traci go co godzinę? Jak szybko znajdziecie taki błąd w ASM? Wtedy to pacjent operowany zbyt długo może odczuć na sobie efekt 100% kontroli nad zasobami mikrokontrolera. Zwolennikom 100% kontroli nad wszystkim, uważającym to za bezpieczniejsze, proponuję porównanie bezpieczeństwa jazdy samochodem naszpikowanym elektroniką (te wszystkie ABSy, kontrola wtrysku, spalania, skręcania, cofania, wspomaganie kierownicy, hamulców itp.) z Fiatem 125p (100% kontroli nad silnikiem i elementami samochodu). Doskonała analogia do wysokiego poziomu i assemblera.
Wydaje mi się, że znajdujemy się w pewnym ważnym historycznie punkcie. Cortex-M3 - procesor o kosmicznej wydajności 1.25DMIPS/MHz w stosunku do swojej śmiesznej ceny (najtańszy 11zł, modele extremalnie wypasione - do 30zł) - sprawia, że nawet do najgłupszych rzeczy nie ma sensu używać jakichś archaicznych rdzeni typu '51, bo po co? Skoro są droższe (niektóre ADuC od Analoga to w ogóle kosmos cenowy), wolne, słabe, mają mało pamięci, mało peryferiów i ciężko się je programuje w C. Dowolna ATmega powyżej ATmegi16 jest droższa niż najtańszy Cortex, więc po co się w ogóle męczyć i pisać kod na niewygodną architekturę Harvardzką w 8-bitowym rdzeniu, który może ma jakiś ułamek DMIPS/MHz? O ile ARM7 nie zdołał zburzyć hegemonii 8-bitowców (bo był drogi, system przerwań mało wygodny oraz wolny), to już Cortex krok po kroku zabija 8-bitowce. A razem z nimi assemblera w normalnych zastosowaniach, bo - powiedzmy sobie to szczerze - w kodzie nie wymagającym super szybkich obliczeń (FFT) - 99% programistów nigdy nie będzie lepszych niż kompilator. Programista jest w stanie całościowo patrzeć może 100 linijek w przód i 100 linijek w tył. Dla kompilatora takie granice nie istnieją - równie dobrze może dokonać optymalizacji bazując na tym co zrobił 10000 liniej wcześniej, albo zaplanować optymalizację 100000 linii do przodu. Dana funkcja używana jest tylko w jednym miejscu - można ją więc włączyć do ciała funkcji wywołującej bezpośrednio. Kod obsługi pętli jest dłuższy niż jej ciało - można więc ją rozwinąć. Dla kompilatora taka zmiana trwa mikrosekundę. Dla człowieka - wielokrotnie dłużej.
To tyle odemnie w tym przydługawym poście [;
4\/3!!