[ASM] Addition (Immediate)

nutze die Pointeregister "r24:r25", XH:L,YH:L, ZH:L

bei r24:r25 bin ich mir nicht mehr ganz sicher

addiw  ?H:L,$08 ;da wird C automatisch addiert

Man kann die Verwendung von r25 vermeiden, aber mehr fällt mir nicht 
ein:

1

ldi r24,8

2

add r8,r24

3

ldi r24,0

4

adc r9,r24

Wie ist denn deine komplette Aufagenbstellung???

> ist auch nichts gewonnen, finde ich
Kommt auf die Sichtweise an: beide Lösungen benötigen 4 Takte, die mit 
adiw hat 1 Wort weniger, benutzt aber r25.

Oft reserviere ich mir für das gesamte Programm ein Register 'null', 
manchmal auch 'effeff', zur ständigen Verwendung:

1

.def  null   = r2

2

.def  effeff = r3

3

4

  clr  null

5

  clr  effeff

6

  dec  effeff

Thomas Elger schrieb:

> "Subtract Immediate" - geht vielleicht
> sowas:
>
>

1

>   subi r8,-8

2

>   subic r9,-1

3

>

Nein, leider nicht. Die ganzen Immediate-Ops (auch andi, ori, cbr, sbr) 
lassen sich nur auf die obere Hälfte des Registersatzes anwenden, also 
R16 und höher.

Dort ist die Immediate-Subtraktion aber tatsächlich oft sehr nützlich 
als Additionsersatz. Übrigens heißt die Variante mit Übertrag nicht 
subic, sondern sbci.

@Christian:

Damit läßt sich auch im konkreten Fall wenigstens ein Takt einsparen:

movw R25:R24,R9:R8
subi R24,Low(-8)
sbci R25,High(-8)

_zero_reg_ ist nicht vorhanden und gepflegt?

Marc Vesely schrieb:
>  bei mir wird r4 auf 0x00 gesetzt und r5 auf 0xFF.
>  Zwei Befehle am Anfang

Wie schafft man das mit zwei Befehlen?

S. Landolt schrieb:
> Marc Vesely schrieb:
>>  bei mir wird r4 auf 0x00 gesetzt und r5 auf 0xFF.
>>  Zwei Befehle am Anfang
>
> Wie schafft man das mit zwei Befehlen?

Das ist einfach, da nach Reset alle Register auf Null initialisiert 
sind, schafft man das sogar mit einem Befehl, z.B.:

dec R5

oder auch

com R5

Aus beliebiger Ausgangssituation benötigt man allerdings wirklich 
mindestens drei Takte.

> da nach Reset alle Register auf Null initialisiert sind

Danke, wieder was gelernt.

sbiw kann da nicht weiterhelfen?

Wenn du Code etwas umstrukturierst (um hoehere Register statt r8++ zu 
nutzen)
kannst du doch adiw benutzen.
Das macht die Addition mit einem Befehl in 2 Takten

c-hater schrieb:
>S. Landolt schrieb:
>> Marc Vesely schrieb:
>>>  bei mir wird r4 auf 0x00 gesetzt und r5 auf 0xFF.
>>>  Zwei Befehle am Anfang
>>
>> Wie schafft man das mit zwei Befehlen?

>Das ist einfach, da nach Reset alle Register auf Null initialisiert
>sind, schafft man das sogar mit einem Befehl, z.B.:

>dec R5

>oder auch

>com R5

>Aus beliebiger Ausgangssituation benötigt man allerdings wirklich
>mindestens drei Takte.

Nur zur Info, aus beliebiger Ausgangssituation geht das auch mit zwei 
Takten:

1

clr r4

2

ser r5

Kommando zurück!

"ser" geht nur für die oberen 16 Register.

A. K. schrieb:
> c-hater schrieb:
>> Das ist einfach, da nach Reset alle Register auf Null initialisiert
>> sind
>
> Ist das irgendwo dokumentiert?

Das würde mich auch interessieren, und seit wann. Bei meinen Neueren 
scheint es so zu sein, bei den steinalten AT90S8515 und AT90S4433 ist es 
nicht so.

Marc Vesely schrieb:
>  general purpose register werden *NICHT AUF NULL GESETZT*

Stimmt tatsächlich, ist auch bei einem ATmega1284P so.
Habe ich doch noch etwas gelernt, nämlich niemandem auf Anhieb zu 
glauben (auch nicht mir selbst).

HI

>Bei meinen Neueren
>scheint es so zu sein, bei den steinalten AT90S8515 und AT90S4433 ist es
>nicht so.

Bei denen gab es gar keine GPIORs. Die sind mit ATmega164P/324P/644P 
oder/und ATmega48/88/168 aufgetaucht.

MfG Spess

Es ging um die normalen Arbeitsregister r0..r31.

S. Landolt schrieb:

> Es ging um die normalen Arbeitsregister r0..r31.

Jepp, und hier muß ich zu meiner peinlichen Schande gestehen, dass ich 
da eindeutig absoluten Bullshit verbreitet habe. Sie werden definitiv 
nicht auf Null initialisiert, sondern befinden sich wie der SRAM in 
undefiniertem Zustand.

Das kommt davon, wenn man meistens mit dem Simulator entwickelt (der sie 
tatsächlich auf Null initialisiert), aber doch gewohnheitsmäßig immer 
den sicheren Weg wählt und alles benutzte Zeug explizit initialisiert.

Deswegen ist es mir echt wirklich niemals aufgefallen, dass der 
Simulator auch in dieser Beziehung nicht das RL abbildet. Verdammt, wäre 
auch nur einmal in irgendeinem Projekt der Codespace gerade so knapp 
geworden, daß ich in die Versuchung gekommen wäre, ein paar Code-Worte 
bei der Initialisierung zu sparen, dann hätte ich das wahrscheinlich 
schon seit langem gewußt...

Axel Schwenke schrieb:
> addiere8:
>
>         ldi r24,8
>         add r8,r24
>         brcc weiter
>         inc r9
>
> weiter:

Dann viel Spaß bei der Fehlersuche!
inc ist etwas anderes als add oder adc, denn es rührt dass carry bit 
nicht an.

> inc ist etwas anderes als add oder adc, denn es rührt dass carry
> bit nicht an.

Daran besteht kein Zweifel, allein - welche Rolle spielt das bei der 
ursprünglichen Fragestellung, der Addition eines konstanten Bytewertes 
auf das Registerpaar r9:r8? Und ein eventueller Überlauf ließe sich per 
Z-Flag abfragen.

Axel Schwenke schrieb:
> Bei unsigned Arithmetik ist ein Überlauf eine
> ganz normale Sache.

Stimmt.
Aber oft interessiert es ja doch, ob ein Überlauf aufgetreten ist, und 
dazu fragt man i.d.R. hinter dem Label "weiter" den Cy ab.
Wenn aber jemand blauäugig den orthodoxen Code durch diese "Optimierung" 
ersetzt hat, wird er (hoffentlich) etwas über Fehlerfortpflanzung 
lernen.
...oder auch nicht, wenn er nur oberflächlich testet.
Vielleicht zerschellt dann ja nur mal wieder eine Sonde auf dem Mars.

Marc Vesely schrieb:
> Am Ende waren genau 2046 Bytes im Flash.

Ein ähnliche Situation entsteht auch heutzutage noch, im 
Bootloader-Bereich nämlich.


lrep schrieb:
> Wenn aber jemand blauäugig den orthodoxen Code durch diese "Optimierung"
> ersetzt hat, wird er (hoffentlich) etwas über Fehlerfortpflanzung
> lernen.

Wo ist der Zusammenhang zwischen schlampiger Programmierung und 
'Fehlerfortpflanzung'?