logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

XMega128 - Zwiększanie liczby czterobajtowej w Asemmblerze

ASMnauka_ 30 Paź 2015 18:14 1188 18
  • #1 15108873
    ASMnauka_
    Poziom 15  
    Cześć
    Aktualnie liczbę czterobajową zwiększam następująco
    Kod: AVR assembler
    Zaloguj się, aby zobaczyć kod

    Oczywiście po wczesniejszym załadowaniu jej do rejestrów R16 do R19.
    Czy istnieje inny sposób zwiększania takiej liczby ?
  • #2 15108972
    BlueDraco
    Specjalista - Mikrokontrolery
    Oczywiście. Możesz napisać w C:
    i = i +1

    albo
    ++ i

    albo i ++
  • #4 15109056
    BlueDraco
    Specjalista - Mikrokontrolery
    Ale po co? Jeśli chodzi o jakość kodu, to przeciętny programista asemblerowy z przeciętnym kompilatorem raczej przegrywa na architekturach z wieloma rejestrami - takich jak AVR wszelkiej maści.
  • #6 15109302
    ASMnauka_
    Poziom 15  
    excray, co prawda się pomyliłeś, lecz i tak Ci dziękuję.
    Nie przejmuj się.
    Jest taki sposób.
    Kod: AVR assembler
    Zaloguj się, aby zobaczyć kod

    Co prawda ADIW wykonuje się dwa cykle, ale zwiększa liczbę dwu bajtową (do 65535) w rejestrach
    Z - R30:R31
    SUBI - 1 cykl
    SBCI - 1 cykl
    ADD - 1 cykl
    ADC - 1 cykl


    Dodano po 3 [minuty]:

    szczywronek napisał:
    Tak tylko podpowiem, że interesujące rezultaty (przy nauce asm), może dać podglądanie kompilatów z języków wyższego poziomu.

    Czy w AVR Studio jest to możliwe ?
    Tak się składa, że posiadam dwie wersje tego programu.
  • #8 15109664
    jnk0le
    Poziom 18  
    Obok pliku .hex powinien być .lss
    Asm przydaje się głównie przy optymalizacji handlerów przerwań no i oczywiście bardzo restrykcyjne protokoły jak USB/PAL. Całą resztę da sie w C zoptymalizować na tyle aby nie trzeba było grzebać w asmie.
  • #9 15110045
    BlueDraco
    Specjalista - Mikrokontrolery
    Dawno temu, kiedy AVR nagle podrożały, przesiadłem się ostatecznie na tańsze Cortexy i od tamtej pory NIGDY nie miałem potrzeby optymalizowania czegokolwiek w asemblerze, bo i kompilatory generują kod na ogół lepszy nież programista i same najtańsze procesory są z 10 razy szybsze od drogich AVR. Pozy tym przy odpowiednich peryferiach na pokładzie znika potrzeba implementowania zaawansowanych protokołów transmisji w oprogramowaniu (co zresztą poważnie ogranicza możliwości całego projektu, bo 99% czasu procesora wyżera implementacja zależności czasowych - vide interfejs WS2812, co w przyzwoitych procesorach robi się na SPI, a implementacje programowe na AVR zajmują się głównie transmisją, a na szybką i inteligentną animację nie zostawiają czasu.

    Ta gra naprawdę nie jest warta świeczki. Czasy, gdy na rynku uC były tylko 51 i PIC, których nie daje się wydajnie programować w C, już dawno minęły.

    W procesorze 32-bitowym inkrementacja 32-bitowego rejetru wymaga jednej instrukcji. Po co tracić czas na rozwiązywanie problemów, które samemu się wygenerowało przez niewłaściwy zapewne do danego zastosowania wybór procesora?
  • #10 15110071
    tronics
    Poziom 38  
    Cytat:
    i same najtańsze procesory są z 10 razy szybsze od drogich AVR

    Tak tanie, tak szybkie, że kastrata Cortex M0 szybko łatano w formę M0+ :) Nie mogę teraz znaleźć, był test pokazujący wyższość ARM (nawet energetyczną) nad AVR (xmega) z tym, że ta wyższość wychodziła dopiero przy benchu na integerach, do 16bit AVR nawet jako tako sobie radził.
    Cytat:
    co w przyzwoitych procesorach robi się na SPI

    Rzeczony procesor ma sprzętowe SPI i DMA więc jest pozbawiony wad, które z uporem przypisujesz wszystkim AVR (bit banding ewentualnie ciągłe dokarmianie sprzętowego bloku peryferiów w przerwaniach).

    Ale wracając do tematu - generację .lss z tego co pamiętam trzeba włączyć.
    Właściwości projektu, toolchain, AVR/GNU common i "zaptaszkować" .lss
    No chyba, że już mnie pamięć zawodzi i jest domyślnie wybrane.
  • #11 15110112
    excray
    Poziom 41  
    Kolego @BlueDraco ta dyskusja toczyła się już setki razy na forum. Nie uszczęśliwiajmy na siłę. Każdy programuje to co chce i w języku jaki chce.
  • #12 15110119
    kamyczek
    Poziom 38  
    Dawno temu programista ,to był człowiek z wiedzą ,który znał asembler i potrafił myśleć binarnie . Ale że człowiek sobie upraszcza to dziś mamy arma w czajniku który przyspiesza mało optymalny bo uniwersalny kod. Rzeczywiście działa szybciej na 100MHz zegarze w stosunku do starej 0C51 która miała cykl rozkazowy 12 taktów zegara czyli przy zawrotnych 24MHz wykonywała 2 miliony operacji na sekundę . Poza tym o jakiej wiedzy można mówić pisząc lcd: "Jestem programistą ... " w porównaniu z 1kB kodu który wsadza kompilator w miejsce instrukcji ,którą napisał facet . Dla was koledzy ktoś ten kod "makroinstrukcji napisał w asemblerze tak na marginesie. Jeśli więc używacie języków wyższego poziomu dla ludzi z mniejszą wiedzą ,to bierzcie pod uwagę to ,że znajomość asemblera załatwia za was kompilator , i jak komuś zginie kod i zostanie sam hex czy bin to leży i kwiczy bo z hexa to zostaje zrobić tylko kod w asemblerze koledzy programiści od języków wyższego poziomu ....8 bitowy mikrokontroler potrzebuje minimum 4 cykli zegara na dodawanie takiej liczby szybciej będzie tylko w 16 i 32 bitowych mikrokontrolerach . Amen ..
  • #13 15110171
    BlueDraco
    Specjalista - Mikrokontrolery
    Kamyczek: nie te asemblery, nie te kompilatory. Programowanie nowych architektur w asemblerze jest mało sensowne, bo kod generowany przez kompilator jest na ogół lepszy niż kod asemblerowy średniego programisty. Zdziwiłbyś się, jak krótki i sprytny kod generuje kompilator dla wielu instrukcji i konstrukcji języka wysokiego poziomu.

    Sztuka programowania aseblerowego miała sens w starych architekturach, gdzie programista mógł się wykazać zdolnością kombinowania i wygenerować kod znacznie krótszy i szybszy od tego, co potrafił kompilator. W większości nowych 32-bitowców programista kompilatorowi nie podskoczy. Zresztą i na AVR w wielu przypadkach kompilator radzi sobie lepiej od programisty z zarządzaniem stadem rejestrów.

    Pożytek ze zdeasemblowango hexa też znikomy, bo jaki jest sens modyfikować kod asemblerowy, kiedy kod w C jest znacznie łatwiejszy do odpluskwienia? Dekompilatory C zresztą też istnieją... ;)

    Wydajność, to nie tylko dodawanie liczb o jakiejś długości - to również np. adresowanie struktur danych w pamięci - wielokrotnie szybsze w procesorach 32-bitowych z powodu dostępności długich rejstrów i potrzebnych trybów adresowania (rejestr + stała).

    Naprawdę trudno jest znaleźć przykład projektu na AVR, którego nie dałoby się zrobić znacznie lepiej (większa funkcjonalność) i wydajniej na Cortexie o połowę tańszym niż rzeczony AVR - wiem, bo parę takich wieloletnich projektów miałem zrobionych na starych i nowych uC, a zmiana uC na nowszy zawsze obniżała koszty urządzenia.
  • #14 15110309
    Konto nie istnieje
    Konto nie istnieje  
  • #15 15110378
    ASMnauka_
    Poziom 15  
    kamyczek i excray, Macie rację !!!
    Nie wiem, po co ta dyskusja.
    BlueDraco , jeśli juz coś piszesz, to proszę, by było to coś konstruktywnego na temat, który założył autor.
    Ale do sedna.
    Jest trzeci sposób dodawania liczby czterobajtowej.
    Kod: AVR assembler
    Zaloguj się, aby zobaczyć kod

    Podsumowując temat.
    Z tych trzech sposobów
    1
    Kod: ARM assembler
    Zaloguj się, aby zobaczyć kod

    2
    Kod: AVR assembler
    Zaloguj się, aby zobaczyć kod

    3
    Kod: ARM assembler
    Zaloguj się, aby zobaczyć kod

    pierwszy jest najlepszy, ponieważ potrzebuję jedynie czterech rejestrów, natomiast w drugim i trzecim aż osiem !
    Każdy z nich potrzebuje tylko czterech cykli zegarowych na zwiększenie liczby.
    Nie wiem, czy istnieje jeszcze inny sposób.
    Przeglądając listę instrukcji Asemmblera dla XMegi nic więcej nie znalazłem.
    Na zakończenie ...
    kamyczek napisał:
    ...to bierzcie pod uwagę to ,że znajomość asemblera załatwia za was kompilator . Amen ..

    Zatem temat uważam za wyczerpany.
  • #16 15110408
    tmf
    VIP Zasłużony dla elektroda
    Zauważ, że sposób pierwszy umożliwia tylko inkrementację 32-bitowej liczby, natomiast sposoby 2 i 3 to ogólne sposoby dodawania i odejmowania dwóch 32-liczb. Sposób z ADIW co prawda nie daje szybszego kodu, ale za to skraca go o jedno słowo. I teraz zawrto sobie potestować avr-gcc i zobaczyć, że to co odkryłeś wykorzystuje kompilator stosownie do potrzeb.
    BTW, jest jeszcze jedno zastosowanie asemblera, zarówno na AVR, jaki i na ARM - przetwarzanie grafiki. Niestety kompilator w krótkich fragmentach, krytycznie czasowego kodu lubi się gubić, człowiek nad wstawkami z kilkudziesięciu instrukcji dobrze panuje.
  • #17 15110482
    ASMnauka_
    Poziom 15  
    tmf napisał:
    BTW, jest jeszcze jedno zastosowanie asemblera, zarówno na AVR, jaki i na ARM - przetwarzanie grafiki. Niestety kompilator w krótkich fragmentach, krytycznie czasowego kodu lubi się gubić, człowiek nad wstawkami z kilkudziesięciu instrukcji dobrze panuje.

    Co Masz na myśli pisząc przetwarzanie grafiki ?
    Konwersję z koloru 8-bit do 16, lub 24 bit itp. ?
  • Pomocny post
    #18 15111255
    tmf
    VIP Zasłużony dla elektroda
    Konwersję koloru z różnych formatów, np. 565 na 888, alfablending, blending przy antyaliasingu, operacje logiczne pomiędzy maską i obrazem. Nieprzypadkowo nawet na PC spore części sterownika grafiki są napisane w asemblerze.
  • #19 15111367
    ASMnauka_
    Poziom 15  
    tmf napisał:
    Konwersję koloru z różnych formatów, np. 565 na 888

    I w tym przypadku muszę się zgodzić.
    Sam na początku wczytywałem pliki BMP zapisane w 24 bitowym formacie kolorów z karty SD.
    Niestety konwersja w locie (programowo) jest bardzo czasochłonna i zbędnie obciąża mikro kontroler.
    Po czasie doszedłem do wniosku, że o wiele lepiej zapisywać pliki graficzne od razu w formacie 16 bitowym (dzieląc kolor piksela na dwa).
    A teraz tylko pętla for ze skokiem = 2 i ładowanie starszej części koloru piksela na port C, oraz młodszej części na port D.
    O wiele wygodniejsza, jak i szybsza metoda.
REKLAMA