Hur mycket går det att slakta i denna kod?

[1802]

Om inte hårdvaran strulade, så kunde jag testa och se om jag är framme. I AVRStudio 4 funkar det som det är tänkt.

Ändrade lite i hex filen till original C koden från första inlägget. cpi r24, 0x64 blir den som assembler. Ändrade 64 till många olika. Avslutade med en inst där det blinkar fort. Och nu kan jag inte programmera om den . Använder Flip. Den fastnar på raderings kollen. Läser jag av så får jag $00-$ff om och om igen. Går jag ur booatloadern så blinkar det snabbt. Så programmet funkar, men det går inte få in ett nytt Skall försöka hitta Avrdude, och testa. I bootloaderläge plingar det till och enheten hittas. Provade att installera om både Flip och JAVA, men ingen lycka När det gäller labels, räcker det inte med att dokumentera väl?

Får jag börja min kod från adress $00? Är där inte några reserverade i början? I oiginal C koden från första inlägget. Så verkar det börja på $00 med en jump till $ac , men där är ju också upptaget.

[Icecap]

Om du har en bootloader ska den ju anropas först av allt...

[Nerre]

Läs databladet...

Adresserna från 0x00 är avbrottsvektorer, den första är reset-vektorn, där lägger man alltså ett hopp till början av koden (som måste ligga nånstans efter alla avbrottsvektorer).

Använder man inte avbrott (interrupt) så kan man såklart börja så kod från 0x00 men det är bra att lära sig göra rätt från början.

[snigelen]

Nu programmerar jag inte assembler så ofta, och i så fall inte avrasm (utan avr-as från avr-gcc).
Men ungefär så här brukar väl ett minimalt blink-program se ut annars. Blinkar med c:a 2.5Hz om AVR'ens klocka är 1MHz.

Kod: Markera allt

.include "m88def.inc"           ; Defines usefull constants for mega88

.org 0
        rjmp    main            ; Reset vector

main: 
        ;;  Setup stack pointer. Not really needed on modern devices.
        ldi     r16,low(RAMEND)
        out     SPL,r16
        ldi     r16,high(RAMEND)
        out     SPH,r16

        ldi     r16,(1<<PB0)
        out     DDRB,r16        ; Only PB0 on PORTB output
        

main_loop:
        sbi     PINB,PB0        ; Write a 1 to PINB.0 to toggle PB0
        clr     r24             ; Maximum delay
        rcall   delay
        rjmp    main_loop       ; Do it agian


; do a 256 loop r24 times or 256 times if r24 is zero.
; r24 and r25 are cleared.
delay:
        clr     r25             ; Clear innner loop counter
delay_1:
        dec     r25
        brne    delay_1         ; Go back if not zero
        dec     r24
        brne    delay_1         ; Do it again if not zero
        ret                     ; Return to caller

[1802]

snigelen: Och hur ser det ut efter disasm? Skall man reverse hacka, så är det lika bra att skriva rått direkt. Och kommentera bra i koden. Obs bara min åsikt. Min hex ovan tar 120 bytes, vad tar din?

[snigelen]

Min poäng (och många andras) var bara att det går att öka läsbarheten utan kostnad.

T.ex en label tar ingen plats i det assemberade programmet, det är bara ett smidigt sätt att ange adresser som sedan assemblern räknar ut åt dig. Dessutom slipper man ju gå igenom alla adresser varje gång man gjort en ändring i programmet.

Storleken på hexfilen är sällan ett relevant mått på storleken på programmet, men i det här fallet blir den 137 byte med stackinitiering (som inte behövs i detta fall) och 108 byte utan (Intels hex-format).

Annars är programmet, utan stackinitiering, på 13 instruktioner á 2 byte, dvs 26 byte (0.3% av 8k).

Du kan föresten ta bort raderna av typen "cpi r17,0x00 ; Jämför r17 med 0", eftersom de kommer direkt efter en instruktion som sätter Z-flaggan i SREG om r17 är noll. De tillför alltså ingenting.

[sodjan]

> Och hur ser det ut efter disasm?

Enda gången det är intressant är om man har "tappat bort" källkoden.
Du skriver väl nytt, så varför är disasm intressant?

> Skall man reverse hacka...

Varför ska du det (i just detta fall)?

> ...så är det lika bra att skriva rått direkt.

Vad betyder "rått"? Att medvetet göra avsteg från goda programmeringsvanor?
När är det någonsin en fördel?

[Nerre]

Det är ju en enorm skillnad på att LÄSA assembler och KODA i assembler.

Visst kan man koda i assembler, men att koda utan labels, makron, defines och liknande blir väldigt rörigt, svårt att se hur koden funkar, svårt att felsöka osv.

Hela vitsen med en bra assembler (eller för den delen kompilator) är ju att den kan hålla reda på adresser och sånt så man slipper göra fel. Det är betydligt enklare att få koden optimerad om man skriver den i C (små saker kan man eventuellt få mer kompakta med väldesignad assembler, men det är svårt att få bra och lätt att göra fel och man kan rentav missa optimeringar).

När jag började leka med AVR så skrev jag "blinka lysdiod" i både C och assembler och enda anledningen till att C gav större binär var intieringskoden som kommer med i alla C-program. Men skriver man större program åker man ändå på att skriva liknande bitar så det är bara för väldigt små program det blir nån skillnad.

Och slog jag på högsta optimering så blev koden faktiskt mer kompakt än min assemblerversion. Jag fick köra näst högsta optimering för att det skulle bli samma kod som jag gjort i assembler (med lite andra register och små skillnader visserligen, men huvudinstruktionerna var desamma).

[labmaster]

Snygg programkod snigelen. Har du skrivit den själv? Den vittnar om god kunskap och insikt i hur man skriver underhållsvänlig programkod.

I mitten på 80-talet utvecklade jag en editor eller rättare sagt implementerade emacs till en 8-bitars persondator. Det var många tusen rader programkod att hålla reda på. Utan välstrukturerad källkod och rikligt med kommentarer hade det varit helt omöjligt att få den att fungera. Jag vill minnas att utskriften på A4-format kokade ihop sig till över decimetern med pappret nästan svart.

Hade jag haft en bra C kompilator så hade jag garanterat använt denna. Nu för tiden skriver jag nästan inget i assembler längre eftersom C kompilatorerna är så bra på optimering. De enda gångerna som jag tycker det kan vara motiverat med assembler är när man skall göra tidkritiska algoritmer i DSP.

[Icecap]

Jag började också i sin tid med assembler, då först som kod under BASIC och sedan som riktiga program under CP/M-80. Efter att ha hackat assembler länga (och ganska väl faktisk) blev jag så trött på att uppfinna hjulet gång efter gång och att bläddra igenom ändlösa rader för att hitta en struntsak - så jag köpte en Pascal-kompiler.

O dra mig baklänges vad jag kunde göra saker utan att uppfinna hjulet om och om igen! Plötsligt kunde jag faktisk få funktionerna klara utan att skriva hundratal rader... En del år senare upptäckte jag C och det fungerar lika bra - fast bättre

Att sitta och harva med disassembleringar gör man för att klura ut hur ett program fungerar, sedan skriver man samma funktion i C. Då ska det dock vara ett mycket viktigt program för att göra detta...

[1802]

Behöver det vara så jobbigt med assembler om man har lite byggstenar att ta av? Klipper och klistrar inte nästan alla programerare från allt de kommer åt(inkl nätet)? Jag kan inte mycket i C, och väntar gärna med att lära mig det. Blir kanske tvungen nån dag ryyys. Kan heller inte mycket om det som inte syns vid en disasm...
Att min "loop i loop" bara gav ett error, ser jag som lyckat. Och då var felet klippt från en felaktig disassemblering, som inte jag gjort. Från Blinking_LED.lss. Vad är en .lss fil? Nån som kan avrdude för ATmega16u4 med direkt usb(read)? ATmega32u4 skall vara nästan samma, bara lite mindre minne. Man kan ändra i avrdude.conf... Men vilken "programerare" har jag? Kör ju USB direkt.

[Nerre]

Problemet med att klippa och klistra assembler är att du måste ändå gå igenom koden och ändra 4711 adresser till variabler, ändra vilka register som används osv.

Du måste också i förväg bestämma om du ska lägga en funktion inline eller inte (en C-kompilator kan välja hur den gör beroende på vad som blir mest effektivt).

Moderna kompilatorers optimering är... jag vet inte vad jag ska kalla det... grym? Börjar man gräva i det så undrar man ofta "Men hur i hela friden kunde kompilatorn komma på det där? Det är ju skitsmart!"

Jag har en gång i tiden försök sätta mig in lite i hur en kompilator fungerar (jag ville skriva en egen), men jag insåg att det var ganska komplext...

[labmaster]

Klipper och klistrar inte nästan alla programerare från allt de kommer åt(inkl nätet)?

Nej det gör de inte. Det finns något som heter upphovsrättslag och den som är duktig på att programmera tjänar inget på att klippa och klistra från andras program. Det går lika fort att skriva nytt och dessutom blir det ofta bättre.

När jag läser din tråd får jag intrycket av att du försöker gena kraftigt i kunskapsprocessen. Det får du gärna göra för mig men för din egen del är det ingen fördel. I varje fall inte om du vill lära dig ordentligt. Ta fram databladet och lär dig skriva egna program. Det är den absolut bästa, säkraste och snabbaste metoden. Det märker du om du lägger ihop tiden du lagt ned hittills i ditt projekt som denna tråd baseras på.

Kul med lite nostalgi Icecap, Pascal var det språk vi använde i de stora metodikkurserna och också de första riktiga högnivåspråk jag lärde mig. Innan hade jag harvat med Assembler och Basic. Läroboken vi använde var skriven av Anders Haraldsson som på den tiden var lektor vid LiTH i Linköping.

[Icecap]

Det har hänt att jag har hittat lösningar i form av programkod på nätet, jag tror att det är 3gg jag har gjort detta.

Jag har hittat många formler och beskrivningar som har givit mig möjlighet att förstår hur man löser en uppgift och då kunde skriva rätt program för detta men klippa från nätet och klistra i eget projekt? Närå! Inte utan ett rejäl översyn av koden jag har hittat först, kontrollräkning av resultat osv.

Förstår jag inte en kod kastar jag den om inte den är det enda sätt att lösa problemet på - och det är aldrig fallet...

Sedan är det inte stor skillnad i strukturen när man skriver program, oavsett om det är assembler, Pascal eller C (eller whatever), det är fortfarande tydliga rutiner som sköter deras jobb, kommentarer som hjälper till att man minns vad som ska ske och sedan en överordnad programsnudd som anropar de olika funktioner.

Inget slår systematik och tydlighet och bra beskrivningar! Att sitta och harva i hur andra gör kan vara kul - när man först vet hur man SJÄLV gör! Först då kan man lära sig fördelar och nackdelar för att man förstår dom.

[1802]

Visst kan man skriva rutiner som bara lånar register, och sen lämnar tillbaka dem? Och sen kan man ju använde minnes adresser med. CP(x) funkade på 6510 så jag provade även här, men din variant var bättre. Ingen avrdude här? Gissar att den klarar sig UTAN JAVA, vilket jag skulle uppskatta.