Assembler a C++ czyli wybór szybciej czy taniej...

Mam pytanie. Po co w dzisiejszych czasach jeszcze niektóre firmy robią sprzęty elektroniczne oparte na Atmega jak to przecież ile kasy trzeba wydać by zatrudnić programistów assemblera, dłużej się przecież programuje w assemblerze niz w C. To nie lepiej kupić o 100zł droższą płytkę, która pomieści przekompilowany kod w C++ czy Bascomie niż męczyć się z assemblerem? Jakie są zalety jeszcze assemblera oprócz tego, że ten sam program napisany w czystym assemblerze zajmuje mniej pamięci niż taki sam program ale napisany w C++ czy Bascomie i przekompilowany na kod maszynowy (czyli na assemblera)?

Trollujesz, czy o drogę pytasz? Pomyśl, że inwestujesz własne pieniądze w produkcję >100 urządzeń, których nikt nie kupi bo będą o 100 zł droższe niż te od konkurencji

Pozdrawiam,
Dr.Vee

aha czyli po prostu to że informatyk siedzi tydzień programując w Assemblerze a nie 1 dzień programując w C++ (ewentualnie Bascomie) bardziej się opłaca wydać kasę na te 5 dni informatykowi niż kupić 100 takich płytek, no w sumie racja.

Skąd pewność, że informatycy w tych firmach piszą wyłącznie w assemblerze? równie dobrze mogą pisać w C.

pomozcie19 napisał:

Jakie są zalety jeszcze assemblera oprócz tego, że ten sam program napisany w czystym assemblerze zajmuje mniej pamięci niż taki sam program ale napisany w C++ czy Bascomie i przekompilowany na kod maszynowy (czyli na assemblera)?

A takie kolego że czasami aplikacja wymaga rygorystycznych zależności czasowych i kod napisany w ASM gwarantuje że "program się nie rozjedzie".

pomozcie19 napisał:

czyli po prostu to że informatyk siedzi tydzień programując w Assemblerze a nie 1 dzień programując w C++ (ewentualnie Bascomie) bardziej się opłaca wydać kasę na te 5 dni informatykowi niż kupić 100 takich płytek, no w sumie racja.

A co jeżeli nie będzie 100 płytek a 1000....10 000? Wszystko zależy od tego co urządzenie ma robić i w jakim czasie ma być wdrożone do sprzedaży.
Wyobraź sobie że nagle resetuje się układ podtrzymywania życia na sali operacyjnej bo ktoś "machnął" szybko program w C++ na super szybkiego i wydajnego ARM9 Z drugiej strony urządzenie do zapalania lampek choinkowych nie wymaga "super niezawodności" i tutaj na taki reset nikt się "nie obrazi"

Asembler daje pelna kontrole nad procesorem. Sa aplikacje ktore wymagaja scisle okreslonych zaleznosci czasowych. Piszac w C nie masz nad tym pelnej kontroli. Dlatego jeszcze pisze sie programy w asemblerze. Zwlaszcza na mikrokontrolery pokroju Atmega, gdzie zasoby nie sa duze, a architektura prosta i przewidywalna. Nie ma co sie rozwodzic nad wyzszoscia jednego nad drugim. Warto korzystac (i znac) z dobrodziejstw jakie niosa oba jezyki programowania. Jak zawsze prawda lezy gdzies po srodku... Tak naprawde czas programisty +/- 5 dni to jest nic w porownaniu z tym jakie szkody moze poniesc uzytkownik zle napisanego programu...

Żałuję że nie posługuję się sprawnie językiem maszynowym a jedynie na tyle aby tworzyś wstawki. Może także żał wynika z własnego lenistwa. Jednak to co poprzednicy napisali o pełnej kontroli nad procesorem to święta prawda istotnie ma się go całkowicie w garści. Unika się np. "cudów" związanych z neiwłaściwą optymalizacją kodu. Kiedyś kilka dni głowiłęm się nad dziwnym zachowaniem zmiennych zanim załapałem że kompilator tworzy je po swojemu. Myślę że praktyka czyni mistrza i coś takiego jak wydłużony czas programowania w tym języku przestaje być problemem. Poza tym pewne fragmenty kodu można zawrzeć w makrach lub gotowych procedurach, zwłaszcza te często używane. Wówczas takie programowanie przestaje się znacząco różnić od zwykłego C.

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!!

Freddie Chopin:
"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ł)"
Jak Ci handlowiec z Twojej(albo jakiejś innnej) firmy znajdzie procesor za 10.99zł to będziesz na niego pisał program.
"Niewidzialna ręka rynku" jest nie tylko niewidzialna ale też ślepa, głucha i nierozumna.
Mnóstwo dobrych rozwiązań padło pod rządami "menagerów".

Sporo w tym prawdy, ale przeważnie to konstruktor narzuca (choć częściowo) układ. W końcu jak do zrobienia jest układ do przetwarzania obrazu, to nie handlowcy będą szukać układu (i znajdą na przykład 89C52 za 4zł) tylko konstuktor musi powiedzieć czego potrzebuje. Również nie handlowiec będzie wybierał układy do nowego projektu, bo jeśli by to potrafił zrobić, to byłby konstruktorem a nie handlowcem.

Menagerowie to już inna sprawa, ale tutaj zasadniczo trafia się na ludzi, którzy są w stanie zrozumieć, że można mieć układ za 50gr mniej, który będzie 100x wolniejszy, a więc soft będzie zapewne nieszczególnie cudowny pod względem wydajności, albo odżałować te 50gr i mieć tą kwestię z głowy.

Mówię całkiem serio - ARM7 ze średniej półki to średnio 30-40zł. To o wiele więcej niż ATmega8. Ale Cortex za 11zł to już tylko trochę więcej [;

Zasada ta oczywiście nie dotyczy "betonu", ale większość ludzi jest w stanie skumać, że nawet super optymalny program w asm na '51 nie będzie szybszy niż normalnie napisany program w C/C++ na Cortexa. Po prostu nie ma takiej możliwości fizycznie [;

4\/3!!

Freddie Chopin napisał:

ale większość ludzi jest w stanie skumać, że nawet super optymalny program w asm na '51 nie będzie szybszy niż normalnie napisany program w C/C++ na Cortexa. Po prostu nie ma takiej możliwości fizycznie [;

4\/3!!

I tutaj nie masz racji...bo '51 to nie tylko AT89C51 i tego typu pochodne. Analog produkuje 12MIPS'owe '51 a ciekawe jest to że nie jest to mikrokontroler a przetwornik A/D ...zresztą bardzo dobry i wart swojej ceny. Podobne rzeczy "robi" Silicon Laboratories ze swoimi 100MIPS'owymi '51.
Swego czasu na elce ktoś próbował dogadać się programowo w ASM z protokołem USB na ARM7..niestety nawet przy podkręconym zegarze rdzeń "nie wyrabiał".
A co Cortex'ów osobiście uważam że są przereklamowane, bo przynajmniej do tego co ja potrzebowałem STM32 był "za wolny" ...a o błędach w rejestrach nie wspomnę .

markosik20 napisał:

Analog produkuje 12MIPS'owe '51 a ciekawe jest to że nie jest to mikrokontroler a przetwornik A/D ...zresztą bardzo dobry i wart swojej ceny. Podobne rzeczy "robi" Silicon Laboratories ze swoimi 100MIPS'owymi '51.

Kwestię mylenia się muszę niestety odbić do Ciebie. Celowo przy '51 nikt nie podaje Ci informacji o DMIPSach, bo mogłoby to wymagać notacji naukowej, a nie zwykłej. MIPSy to nie wszystko, bo chyba nie sądzisz, ze 1MIPS 8-bitowej '51 (CISC) odpowia 1MIPSowi 32-bitowego RISCa. Cortex-M3 ma 1.25DMIPS/MHz, ARM7 - 0.9DMIPS/MHz, a '51? Będzie choć 0.1? Wątpię... Za sam fakt 8-bitowości jest on - na dzień dobry - 4x wolniejszy, a jeszcze zestaw instrukcji i czas ich trwania... Może 0.01DMIPSa/MHz? Jak '51 osiągną GHz, to wtedy można porównywać je z Cortexem - do tego czasu nie ma to żadnego sensu...

Cytat:

Swego czasu na elce ktoś próbował dogadać się programowo w ASM z protokołem USB na ARM7..niestety nawet przy podkręconym zegarze rdzeń "nie wyrabiał".

Świadczy to raczej jedynie o kiepskich zdolnościach programistycznych piszącego, a nie o kiepskości ARM7.

Cytat:

A co Cortex'ów osobiście uważam że są przereklamowane, bo przynajmniej do tego co ja potrzebowałem STM32 był "za wolny" ...a o błędach w rejestrach nie wspomnę .

No cóż - DSP to jeszcze nie jest, ale jest całkiem blisko, bliżej niż takie na przykład dsPICe (IMHO).

4\/3!!

Hehe, widzę że koledze to chyba ktoś płaci za reklamowanie tego Cortex'a . Nie uważam bynajmniej że rdzeń '51 (AVR) jest szybszy od Cortex'a czy ARM7. Zresztą takie porównywanie nie miałoby sensu. Każdy rdzeń ma swoją listę rozkazów ASM i każda ma ponad 80% z nich wykonywanych w jednym cyklu.

Freddie Chopin napisał:

Cytat:

Swego czasu na elce ktoś próbował dogadać się programowo w ASM z protokołem USB na ARM7..niestety nawet przy podkręconym zegarze rdzeń "nie wyrabiał".

Świadczy to raczej jedynie o kiepskich zdolnościach programistycznych piszącego, a nie o kiepskości ARM7.

Świadczy to nie o kiepskich zdolnościach programisty a o występujących różnicach w rozkazach ASM. Dla rdzenia ARM7 zajmowało to 7 cykli zegara dla rdzenia AVR 2 lub 3 (już nie pamiętam dokładnie). Chodziło wtedy o odczyt stanu na pinie portu.

Swego czasu porównałem odczyt danych z karty SD i wyświetlania ich na kolorowym LCD wykonanych na AVR i LPC2103 oraz STM32 i ....o dziwo aż takich znacznych różnic nie było jakby to wynikało z tych MIPS czy DMIPS.

Uważam że każdy rdzeń ma swoje wady i zalety i wszystko zależy od tego do czego (i przez kogo) ma być użyty to jeden będzie się nadawał lepiej drugi gorzej. Wiadomo że teraz wszystkie urządzenia posiadają kolorowe LCD z dodatkowymi "bajerami" i nikt nie będzie "zatrudniał" do pracy 8-bitowców lecz są jeszcze takie branże gdzie koszt wprowadzenia do sprzedaży nowych produktów jest wielokrotnie wyższy niż zysk uzyskany z ich sprzedaży i bazuje się na starych sprawdzonych i przetestowanych rozwiązaniach.

Wracając do tematu, popieram opinię że języki wyższego poziomu pozwalają na bardziej efektywne tworzenie oprogramowania jednak znajomość asemblera i wykonywanie wstawek ASM jest bardzo znacząca i nie zastąpi go zwiększanie coraz bardziej szybkości taktowania.
Oczywiście na 100 pisanych programów do różnych zastosowań pewnie tylko jeden będzie wymagał pełnej kontroli nad fragmentami kodu....ale zawsze to jest ten 1%.

Coś mi się widzi, że kolega Freddie Chopin strasznie "nie lubi" rdzenia '51
Jest wolny to fakt. Mimo to w latach jego świetności powstało wiele ciekawych rozwiązań i moim zdaniem do nauki programowania jest idealny.
I tu proponował bym właśnie zabawy z assemblerem.
Nie mam pojęcia dlaczego wszyscy zachwycają się tak bardzo AVR'ami?
Osobiście jeżeli trzeba zrobić coś "na szybko i pewnie" wybieram współczesne rozwiązania '51 a nie AVR'a.
Oczywiście nie znaczy to, że musimy korzystać tylko z '51. Wszystko zależy od tego co trzeba zrobić i w jakiej cenie.
Faktem również jest to, że ST rozpoczęło od jakiegoś czasu politykę otwierania się na rynek. Stąd popularność (i cena) CORTEX'a M3 ale nie tylko. I nie chodzi wcale o reklamę tylko o pokazanie, że istnieją też inne procesory niż AVR'y. Czasem mam wrażenie, że jak ktoś już opanuje jedną maszynę to się zachwyca tylko tym jednym rozwiązaniem i przestaje śledzić rynek nowości.
Pojawiło się STM8A(S), które cenowo już pokonało Atmela (np. ATTINY44 jest droższy o około 25% w hurcie niż standardowa oferta dla STM8S103K3)

I jeszcze kilka słów o projekcie kolegi Freddie Chopin. Ostatnio przeglądałem Twoją stronę i to co widziałem jest imponujące. Szkoda tylko, że wszystko kręci się tylko wokół ARMów.
Szukałem ostatnio właśnie programatorów typu "OPEN SOURCE" dla STM8 z marnym skutkiem. Straszne brakuje mi rodzaju rozwojowego "kombajnu" do programowania wielu urządzeń. Ale to raczej jest mocno skomplikowane (chociażby dlatego, że część instrukcji JTAG jest utajniana przez producentów)

kol. Freddie, to co napiszę to prośba a nie złośliwość. Zastrzegam się bo nie chcę być źle zrozumiany. Widzę że masz informacje co do rzeczonego Cortexa, napisz ile kosztują narzędzia i jakie, oraz czy jest darmowe oprogramowanie typu AVRStudio o ile jest. Interesuje mnie też info typu programator i evaluation board. Będę wdzięczny za ew. informacje i jak się te koszta mają do AVR-ów. Pozdrawiam.

rpal napisał:

.. napisz ile kosztują narzędzia i jakie, oraz czy jest darmowe oprogramowanie typu AVRStudio o ile jest. Interesuje mnie też info typu programator i evaluation board. Będę wdzięczny za ew. informacje i jak się te koszta mają do AVR-ów. Pozdrawiam.

Akurat tutaj jest podobnie jak w AVR .
Środowisko programistyczne - Eclipse + np: Codesourcery - free
Środowisko do debugowania (programowania) - openocd - free
Programator na LPT - WIGGLER - (bardzo przypomina ST200 dla AVR).
Co do płyt ewaluacyjnych poszukaj...jest tego trochę.

Dzięki kol. markosik trzeba się w takim razie tym czymś zająć. Acha to "coś" w jakich jest obudowach, wystarczy zwykłe smd czy też bardziej wyrafinowanej metody montarzu potrzebuje ?

No nie do końca jest podobnie - w końcu pisząc program na AVRa w gcc można nie mieć pojęcia co to makefile. Tutaj zaś pojęcie mieć trzeba o makefile, skryptach linkera i do tego jeszcze o assemblerowych startupach - jest trochę gorzej. No i te darmowe debuggery... do ideału brakuje im całkiem sporo (podgląd rejestrów peryferyjnych w wygodny sposób).

Anyłej - w istocie - wszystko co jest potrzebne na kompa jest darmowe (płatne też jest of course).

Nie istnieje coś takiego jak "programator" do ARMa - albo JTAG, który jest debuggerem, albo można ładować soft poprzez firmowe bootloadery (UART w LPC i STM32, USB w SAM).

Evaluation board to inna sprawa, ale na mikrosterowniki.pl mają fajną płyteczkę z Cortexem, któej największą zaletą jest to, że mozna ją wpiąć do płytki stykowej (; - ma wyprowadzenia w jednym rzędzie goldpinów. Koszt takiej płyteczki to 90zł, więc drogo (bo w zasadzie nic na niej nie ma). Ciekawa opcja to Primer - niesamowicie rozbudowany zestaw za bardzo małą kasę, ale wadą jest to, że raczej ciężko coś do niego podłączyć.

4\/3!!

Freddie Chopin napisał:

No nie do końca jest podobnie
4\/3!!

Podobnie nie znaczy identycznie .
Co do darmowego debuggera to nie ma co narzekać, choć rzeczywiście mogłaby ta funkcja podglądu rejestrów być bardziej przejrzysta jednak jest to przydatne raczej na początku uruchamiania peryferiów......później mając gotowe biblioteki wystarczy je odpowiednio implementować.
Co do programatora praktycznie każdy JTAG do ARM jest też jego programatorem i modyfikując w niewielkim stopniu popularnego STK200 do AVR mamy Wiggler'a do ARM .

A'propos płytki ewaluacyjnej, to zmajstrowałem takową dla Cortexa-M3 (procek STM32F103). Standardowe wyposażenie: LEDy, przyciski, LCD HD44780, JTAG, do tego USB, 2xUART zrealizowane jako wyjścia USB (poprzez FT232), CAN i Ethernet oraz gniazdo do kart SD/MMC. Wszystko zaprojektowane jest tak, aby można było procek dowolnie podłączyć do peryferiów "napłytkowych" krótkimi kabelkami (rozwiązanie zaczerpnięte z płytki Propoxu dla LPC2148). Jak tylko przyślą mi gotową PCB z płytkarni zrobię kilka testów i dam znać co i jak. Jeśli bylibyście zainteresowani, można zamówić płytki hurtowo.

kol. Zaquadnik masz pierwszego chętnego. Pokonałem lenistwo i popatrzyłem sobie na stosowane w tych Cortexach obudowy. Niestety na moje oko rozmiar rastra wykracza już poza amatorskie wykonastwo obwodów drukowanych wliczającv w to gotowy laminat światłoczuły. Z racji wieku nabyłem juz kilka dodatnich dioptri i montaż smd staje się dla mnie coraz bardziej uciążliwy

Zatem chętnie podłaczę się pod gotową PCB jak już będzie po testach.

pomozcie19 napisał:

To nie lepiej kupić o 100zł droższą płytkę, która pomieści przekompilowany kod w C++ czy Bascomie niż męczyć się z assemblerem?

I wypadasz z rynku bo klient kupi o 100 zł tańszy produkt konkurencji.

UDMA napisał:

I wypadasz z rynku bo klient kupi o 100 zł tańszy produkt konkurencji.

Z tym 100 PLN bym kolego nie przesadzał a piszę to z autopsji gdyż na co dzień param się sprzedawaniem wyjątkowo drogich "rzeczy" generalnie nie będących artykułem pierwszej potrzeby i powiem tyle że to czy coś jest tańsze o tamtego to wcale nie powód aby kupić to tańsze. Myślę że wiele osób bez wdawania się w szczegóły przyzna mi rację

To są różne rynki.
Jak ktoś robi odtwarzacz MP3 albo golarkę w ilości 10M-sztuk to zatrudnia 100 Hindusów i 1000 Chińczyków i piszą mu w assemblerze przez miesiąc.
Każdy cent robi różnicę-najlepiej procesor 4-bitowy a nie 8.
A debugowanie niepotrzebne-jak się zawiesi to się wyrzuci.
Ale jak mam maszynę za 1M euro od pracy której zależy produkcja za 10M euro to spokojnie poczekam i dopłacę za oprogramowanie (zdebugowane) za 10k euro.

Mam małe doświadczenie w programowaniu mikrokontrolerów, piszę raczej aplikacje na PC w C++ i w javie. Żyjemy w czasach gdzie do rozwiązania różnych problemów używamy różnych języków. Zrobiłem sobie taki prosty termometr cyfrowy i do jego zaprogramowania wybrałem asm. Wg mnie użycie C++(mojego ulubionego języka) byłoby nieporozumieniem. Może kiedyś powstanie technologia która nie będzie tak rozrzutna jeśli chodzi o wiedzę potrzebną do jej opanowania.

A jeśli chodzi o problem autora (w skrócie " po co dzisiaj asm?") asm pozwala złapać kontroler na flaki i zrobić z nim co się chce. Są firmy które mają naprawdę spory popyt na swoje produkty, takie firmy interesuje głównie jakość, chcą tworzyć technologie nieskazitelną pod każdym względem. W takiej firmie doświadczony programista asm zawsze znajdzie robotę za naprawdę dobre pieniądze.

Jedni wola samochód inni wolą motocykl ... Tu jest tak samo . Asembler wymaga znajomości budowy mikrokontrolera i większego wkładu pracy przy pisaniu oprogramowania. C jest szybsze w pisaniu , łatwiejsze i wygodniejsze. Jednak zaleta asemblera jest taka ,że daje najmniejszą objętość kodu wynikowego , szybkość działania programu i jego niezawodność.

kamyczek napisał:

Jednak zaleta asemblera jest taka ,że daje najmniejszą objętość kodu wynikowego , szybkość działania programu i jego niezawodność.

Aby napisać w ASM program który będzie mniejszy, szybszy i bardziej niezawodny niż taki sam napisany w C, to trzeba być naprawdę mistrzem. Jeden z tych elementów na raz osiągnie większość programistów, dwa na raz - pare procent, wszystkie trzy - promil populacji na granicy błędu statystycznego.

Kompilatory i technika optymalizacji idą do przodu - obecne kompilatory są naprawdę dobre i tyle...

4\/3!!

Myśle, że na każdym nowym procesorze (który oczywiście będziesz używać) warto napisać "Hello world" w assemblerze

Najbardziej myląca jest w tym wszystkim nazwa "język wyższego poziomu" który świadczy nie o umiejętnościach programisty ale o ich braku. Czyli im wyższy poziom języka tym niższy poziom programisty. dla wielu liczy się wygodnictwo i szybkość pisania ja osobiście wolę asemblera bo to co pisze działa zawsze tak jak powinno ...

Witam
Różnica między ASM i C polega na dostępie gotowych bibliotek do tego drugiego, niekoniecznie darmowych. W ASM obsługę różnych peryferii trzeba pisać samemu, a w C ściąga się z sieci bibliotekę i gotowe. Co prawda, darmowe są do bani, ale kto się przejmuje że komercyjne trzeba kupić, jak można je mieć za darmo.
Sama umiejętność programowania to wymyślanie prawidłowo i efektywnie algorytmów i nie sądzę że w C będzie szybciej niż w ASM, chyba że znajdowanie błędów. Ale kompilator C potrafi tak namieszać że nie wiadomo gdzie leży błąd.