AVR Assembler Trick gesucht

Aussterbende Art schrieb:
> Meine Frage dazu: Kann man das ganze (4 Instruktionen) auch in 3
> schaffen?

Ja, das geht. Aber wahrscheinlich würdest du dir eine weitere
Einschränkung ausdenken, um auch diese Lösung auszuschließen ;-)

Edit:

Wenn du deinen Code so umstrickst, dass die Zahl statt in R10:R11 in
einem günstigeren Registerpaar steht, kannst du Anzahl der nötigen
Instruktionen auf 2 und sogar auf 1 reduzieren.

Aussterbende Art schrieb:
> Meine Frage dazu: Kann man das ganze (4 Instruktionen) auch in 3
> schaffen? Es ist nicht erlaubt, die "0" in einem globalen Register zu
> speichern.

 2 Mal Wert laden, 2 Mal Register addieren ( und das auch noch mit
 niedrigen Registern ) in 3 Instruktionen ?

 Bist du selbst auf die glorreiche Idee gekommen oder hat dir jemand
 dabei geholfen ?

Aussterbende Art schrieb:
> Leider habe ich bewusst das Registerpaar <16 gewählt.

Und warum hast du das getan? Um dir (und dem AVR) das Leben unnötig
schwer zu machen?

Yalu X. schrieb:
> Wenn du deinen Code so umstrickst, dass die Zahl statt in R10:R11 in
> einem günstigeren Registerpaar steht, kannst du Anzahl der nötigen
> Instruktionen auf 2 und sogar auf 1 reduzieren.

 Wenn die Oma einen Schwanz hätte, wäre sie Opa.


Aussterbende Art schrieb:
> Leider habe ich bewusst das Registerpaar <16 gewählt. Sonst wäre es mit
>
> subi
> sbci
>
> noch relativ einfach.

 Und mit:

1

 adiw  yl, 10

 noch einfacher.

 EDIT:

1

  movw  r24, r10

2

  adiw  r24, 10

3

  movw  r10, r24

Ich ärgere mich schon wieder, dass ich dieses sinnlos konstruierte 
Scheinproblem gelesen habe. Manchmal fragt man sich wirklich was das 
soll.

Marc V. schrieb:
> Yalu X. schrieb:
>> Wenn du deinen Code so umstrickst, dass die Zahl statt in R10:R11 in
>> einem günstigeren Registerpaar steht, kannst du Anzahl der nötigen
>> Instruktionen auf 2 und sogar auf 1 reduzieren.
>
>  Wenn die Oma einen Schwanz hätte, wäre sie Opa.

Marc V. schrieb:
> Und mit:
>  adiw  yl, 10
> noch einfacher.

Aber nur, wenn Oma == Opa:
- Code muss auf anderes Registerpaar umgestrickt werden dürfen.
- Eines der oberen 4 Registerpaare muss frei verfügbar sein.
- ADIW-Instruktion muss vorhanden sein (in einigen älteren AVRs ist das
  nicht der Fall).

>  EDIT:
>   movw  r24, r10
>   adiw  r24, 10
>   movw  r10, r24

Auch hier nur, wenn Oma == Opa:
- Eines der oberen 4 Registerpaare muss frei verfügbar sein.
- ADIW- und MOVW-Instruktion muss vorhanden sein.

Da ADIW nicht gerade in die Kategorie

Aussterbende Art schrieb:
> schräge Assemblerbefehle

fällt, sondern ganz im Gegenteil sogar die naheliegendste Lösung des
Problems darstellt, bin ich oben davon ausgegangen, dass auch der TE
diesen Gedanken hatte, ihn aber aus irgendeinem Grund wieder verworfen
hat.

Yalu X. schrieb:
> fällt, sondern ganz im Gegenteil sogar die naheliegendste Lösung des
> Problems darstellt, bin ich oben davon ausgegangen, dass auch der TE
> diesen Gedanken hatte, ihn aber aus irgendeinem Grund wieder verworfen
> hat.

 Kaum, sonst hätte er das als verboten aufgeführt.

Aussterbende Art schrieb:
> schaffen? Es ist nicht erlaubt, die "0" in einem globalen Register zu
> speichern.

 TE sagt, dass nur Null speichern nicht erlaubt ist.

 Ergo, was nicht ausdrücklich verboten ist, ist erlaubt.

 Obwohl:
Aussterbende Art schrieb:
> Nun gibt es ja doch so einige schräge Assemblerbefehle. Vielleicht gibts
> da noch einen anderen Trick?

 Es ist eher eine schräges Problem.
 Und ziemlich sinnlos (für mich).

Aussterbende Art schrieb:
> Leider habe ich bewusst das Registerpaar <16 gewählt.

Man kann sich aber auch nen Knopf an die Backe nähen, die Hose mit ner 
Kneifzange anziehen, nen Pudding ans Knie nageln usw.

Aussterbende Art schrieb:
> Es ist nicht erlaubt, die "0" in einem globalen Register zu
> speichern.

In Assembler ist man eh Einzelkämpfer und muß sich selber keine 
unsinnigen Verbote auferlegen.

In früheren Assemblerzeiten habe ich sogar 2 Register genullt und konnte 
dann mit MOVW ein Registerpaar nullen.

Peter D. schrieb:
> In früheren Assemblerzeiten habe ich sogar 2 Register genullt und konnte
> dann mit MOVW ein Registerpaar nullen.

 Man kann es auch übertreiben ;-)
 Obwohl, bei mir war r4 immer Null und r5 immer 0xFF, nur habe ich heute
 überhaupt keine Ahnung mehr warum das so war und was ich dadurch so
 gewonnen habe.
 Irgendeinen Grund muss ich aber schon gehabt haben...

Marc V. schrieb:
> Man kann es auch übertreiben ;-)

Nö.
Es rechnet sich schon ab dem 2. 16Bit-Clear.
Für ungenutzte Register gibt es kein Geld zurück.

Peter D. schrieb:
> Für ungenutzte Register gibt es kein Geld zurück.

Es sei denn, man lässt die gleich bei der Herstellung weg. Das hat Atmel 
bei den kleinsten AVRs mit den ersten 16 Registern gemacht. ;-)

A. K. schrieb:
> Es sei denn, man lässt die gleich bei der Herstellung weg. Das hat Atmel
> bei den kleinsten AVRs mit den ersten 16 Registern gemacht. ;-)

Diese halbierten AVRs haben zudem den Vorteil, dass SUBI und SBCI auf
sämtliche Datenregister anwendbar ist, weswegen sich die Frage nach
dem Assembler-Trick gar nicht erst gestellt hätte ;-)

Aussterbende Art schrieb:
> wenn ich jetzt einen tiny mit nur 16 Registern habe, kann ich nicht
> einfach einige Register für Konstanten reservieren, da 16 Register nicht
Aussterbende Art schrieb:
> Daher kam auch das Beispiel mit add 10. Wenn r10:r11 vorher 250:0 ist,

 Aha.
 Und woher kommen r10:r11 wenn du einen Tiny mit nur r16=>r31 hast ?

Aussterbende Art schrieb:
> Ich habe z.B. folgenden Code (aus meiner Routine hwmul16x16_signed):
>
> [...]
> ;+ src1L*src2H*256
> mulsu src2H,src1L
> sbc dst4,Gzero
> add dst2,Gmul0
> adc dst3,Gmul1
> adc dst4,Gzero

 Sure.
 Und hier folgender Code aus meiner ( Uuuups - und Atmels Routine
 mul16x16_s):

1

   mulsu r21, r22; (signed)bh * al

2

   sbc r19, r2

3

   add r17, r0

4

   adc r18, r1

5

   adc r19, r2

Aussterbende Art schrieb:
> wenn man etwas falsch verstehen will, versteht man
> etwas falsch

Nö, der TO trägt dazu wesentlich bei, wenn er den nötigen Kontext erst 
viel später nachreicht. Es ist doch klar, daß man erstmal vom standard 
AVR ausgeht.
Die reduzierten ATtiny unterscheiden sich nicht nur in der 
Registeranzahl, sondern haben auch große Unterschiede beim Befehlssatz.

Aussterbende Art schrieb:
> ldi hilfsregister,10
> add r10,hilfsregister
> ldi hilfsregister,0
> adc r11,hilfsregister

R10, R11 gibt es nicht. Es sind die unteren Register weggefallen, d.h. 
sie haben nur R16..R31.
Es muß also heißen:

1

subi r26, low(-10)

2

sbci r27, high(-10)

c-hater schrieb:
> du mußt mehr Takte investieren, wenn du kein NULL-Register
> spendieren willst oder kannst.

Es gibt weder R0..R15, noch ein MOVW. Daher können alle Register mit 
Konstanten rechnen und ein Zero-Register würde nichts einsparen.

c-hater schrieb:
> Hihi, da sieht man die tiefe Weisheit beim 6502 bezüglich des im ersten
> Moment absonderlich anmutenden Verhaltens des Carryflags bei der
> Subtraktion...

Das ist nur so lange absonderlich, bis man sich den Aufbau einer ALU 
ansieht.

c-hater schrieb:
> Grundfalsches Argument.

Die einfachste Form der Subtraktion ist die Addition des 
Einerkomplements. Also ein Adder mit invertiertem rechtem Operand. Damit 
erhält man die Subtraktion von 6502 und ARM. Bei der Subtraktion von AVR 
und x86 wird zusätzlich das C-Flag davor und danach invertiert.

Trotzdem bleibt das ein sinnloser thread.

Aussterbende Art schrieb:
> Leider habe ich bewusst das Registerpaar <16 gewählt.

Dann ändere das oder leb mit den Einschränkungen. Falls das nicht geht 
und deine Softwareperformance  mit dem läppischen einen Takt und Befehl 
in die Kniee geht (was ich nicht glaube, aber manchmal entscheidet 
tatsächlich ein einziger zus. Takt über Lösbarkeit oder nicht, wenn ein 
ganz hartes timing erforderlich ist), liegt der eigentliche Fehler noch 
viel früher - in der Wahl des Prozessors. Auf absolute Kante gestrickte 
Designs muss sich heute keiner mehr antun, da geht man ganz geschmeidig 
in die nächstgrössere Liga. Das tüfteln am Limit kann Spass machen, 
effektiv ist es nicht. Es dauert oft sehr lange (mit ungewissem Ausgang) 
und spätere selbst kleine Änderungen können einen wieder aus der Bahn 
werfen.
Ist natürlich blöd, wenn man das in Assembler programmiert hat und dann 
den MC wechselt - da fängt man wieder bei Null an. Das kann natürlich 
ein Grund sein, warum man diesen Schritt hinauszögert :-)

Liebe Leute, muß mich hier auch noch mal einbringen. Der TO hat 
offensichtlich mal was von Assembler-Tricks gehört und stellt sich nun 
diesen "Kinderkram" drunter vor. In den Anfängen der 
Assembler-Programmierung hatte man um jedes Bit zu kämpfen und hat 
deshalb neben sogenanntem "Selbstmodifizierenden-Code" - ich überlasse 
es dem TO, rauszufinden, was das ist - auch in Registern "Befehle" 
versteckt. Jeder kann sich vorstellen, was das für einen lesbaren Code 
gab, aber es hat geholfen...*fett Das nennt man Assenbler-Tricks!!* 
Selbstmodifizierenden-Code nennt man heute übrigens wichtig: generischen 
Code. Habe aber noch kein wirkliches Beispiel gesehen...oder habe es 
nicht verstanden :-)
Gruß Rainer
Und ich zitiere jetzt noch mal W.Busch: "wenn jemand, der mit Mühe kaum, 
gekrochen ist auf einen Baum, schon glaubt, dass er ein Vöglein wär, so 
irrt sich der..." die lange Version kann sich jeder ohne Mühe im Net 
ansehen.

...peinlich, ich wollte "das" fett machen...

Meine Güte, der TO nennt sich selbst "Aussterbende Art" und will 
irgendwo einen einzelnen Takt sparen, mit Randbedingungen, wo es nicht 
sinnvoll geht. Begründet ist das auch nicht ordentlich.

Ich nenn das mal Trollerei und mehr nicht.

Ja ja, wenn er sich aber an wirklichen Tricks berauschen will, dann 
könnten ihm die Hinweise ja vielleicht helfen. Natürlich bin ich da auch 
mehr als skeptisch, weil sich die "Trick-Ebene" deutlich verschoben hat. 
Auf Userebene mit einem 4-Finger-Grätschgriff, den nich niemand kannte, 
die aktuelle Wassertemperatur auf den Balearen angezeigt bekommen, ist 
auch ein Trick...für heutiges Verständnis..
Gruß Rainer

Tricks gab's z.B. beim ZX81.
Der hatte Code-Sequenzen, die je nach Einsprungpunkt völlig 
unterschiedliche Dinge taten. Entweder was rechnen oder, 1Byte weiter 
angesprungen, Screen-Output.
Ist aber nicht wirklich neu, das macht auch die Natur bei Gen-Sequenzen.

Carl D. schrieb:
> Tricks gab's z.B. beim ZX81.
> Der hatte Code-Sequenzen, die je nach Einsprungpunkt völlig
> unterschiedliche Dinge taten. Entweder was rechnen oder, 1Byte weiter
> angesprungen, Screen-Output.
> Ist aber nicht wirklich neu, das macht auch die Natur bei Gen-Sequenzen.

Hi, ich weiß ja was du meinst, aber der TO nicht...und ich glaube nicht, 
dass man ihm den Zahn mit den Tricks ziehen kann, indem man ihm was aus 
der Programmiersteinzeit erzählt. Das waren Tricks! Ohne Zweifel. Heute 
sind Tricks was anderes. Erspare mir Beispiele, sonst rege ich mich auf 
(Helge Schneider)
Rainer

Eicke Falber schrieb im Beitrag #5500309:
> Irgend ein armes feiges Modlöschferkel

Und irgendein feiges anonymes Gastferkel spammt den Thread zu...

Ach, das ist nur Moby, ein Troll mit Hausverbot.

Daher ist es auch vollkommen egal, was er wozu schreibt.

Vielleicht begreift er es ja doch noch irgendwann :-)

Skripte habe ich angepasst.

Manche Gäste sind hier schon echt ein asoziales Pack...

Theor schrieb:
> Rainer V. schrieb:
>> [...] hat [...] auch in Registern "Befehle" versteckt. [...]
>
> Das hört sich interessant an. Sich selbst modifizierenden Code habe ich
> vor Jahrzehnten mal kennengelernt. Aber etwas, dass gerade so
> beschrieben wird, noch nicht.

Ein Stichwort aus der SNES-Szene nennt sich "Open Bus". Das wurde zwar 
ziemlich sicher nicht in realer Software genutzt, allerdings beim 
Exploiten von Super Mario World und anderen Spielen.

Ansonsten kann man auch bestimmte Hardwareregister zur Codeausführung 
benutzen, wenn sie im ausführbaren Adressraum gemappt sind. Es hindert 
einen auf einem kleinen ARM-Cortex niemand daran, einfach mal in die 
GPIO-Register zu springen; solange da gültige Opcodes stehen, tut das.

Theor schrieb:
> Habe nur vorhin an "Register" im Sinne der von der ALU für die Operanden
> oder das Resultat benutzten Register gedacht. Aber diese Art Register
> muss ja Rainer nicht gemeint haben.

Ein AVR mappt seine 32 Register auch in den Adressraum.
Aber ausführbar werden die davon (leider) trotzdem nicht. :-)

Theor schrieb:
> Irgendein Trick mit dem ein Registerinhalt in das Befehlsregister
> kommen kann, dass ja an sich nicht zugreifbar ist (jedenfalls ist
> mir da keine CPU bekannt). Oder halt was ganz Anderes.

Der i8080 (und auch die kompatiblen, also i8085/Z80) machen genau das 
für ihre Interrupts. Wenn ein Interrupt verarbeitet werden soll, dann 
legt die Hardware den auszuführenden Opcode auf den Bus, und die CPU 
führt den aus. Das darf auch ein Multibyte-Befehl sein, üblich waren 
aber die RST-Befehle.

Der Z80 kannte noch zwei weitere Interrupt-Modi (fixe Adresse bzw. 
Vektorinterrupt), die es beim i8080 nicht gab.

S. R. schrieb:
> üblich waren aber die RST-Befehle.

Das war auch der Grund für deren Existenz.

Theor schrieb:
> Dachte eher an irgendwas "abgefeimtes". :-) Keine Ahnung. Irgendein
> Trick mit dem ein Registerinhalt in das Befehlsregister kommen kann,

Das gab es ganz offiziell bei manchen früheren Rechnern. Abstammend vom 
TI 990 Minicomputer hatten auch deren TMS9900 Mikroprozessoren einen 
"Execute" Befehl, der exakt das machte. Er führte den Operand als Befehl 
aus.

S. R. schrieb:
> Ein AVR mappt seine 32 Register auch in den Adressraum.

Nur bei den alten Modellen.  Die Xmega mappen die GPRs nicht mehr in den 
RAM (also LD* / ST*) Adressraum, und der SFR-Offset (also Offset 
zwischen RAM- und I/O-Adressen für IN, OUT, etc.) ist 0x0 statt 0x20.

Ich denke immer noch, dass das was wir "Alten" mal unter Tricks 
verstanden haben, heute eine völlig andere Bedeutung gewonnen hat. Der 
TO hat versucht, eine simple Operation auf Registern zu "optimieren". 
Ist ein legitimes Unterfangen, zumal oft eben viele Wege nach Rom 
führen. Und die Überlegung, eine Operation in diesem Sinne optimal zu 
codieren, ist eben auch schlau!
Habe vor dieser langen Zeit mal das Glück (??!!) gehabt, einen 
Forth-Code neben einem Assembler_Code dieses berühmten A-B-Algorithmus , 
der in Schachspielen verwendet wurde (wird?) in die Hände zu kriegen. 
Ich kann euch nur sagen, wenn Tricks, dann da! Und ich habe nichts 
verstanden :-)
Gruß Rainer

Rainer V. schrieb:
> Und ich habe nichts verstanden :-)

Ich habe mal einen Krypto-Algorithmus von einer Sprache, die ich nicht 
kann (C#) in eine Sprache, die ich kann (C) überführen dürfen. Da habe 
ich auch nichts verstanden.

Rainer V. schrieb:
> Ist ein legitimes Unterfangen, zumal oft eben viele Wege nach Rom
> führen. Und die Überlegung, eine Operation in diesem Sinne optimal zu
> codieren, ist eben auch schlau!

Naja, heutzutage kann und muss man wesentlich globaler optimieren. 
Üblicherweise ist genug Rechenzeit vorhanden, so dass man sich nur auf 
die wirklich relevanten Verarbeitungsschritte konzentrieren braucht. 
Dazu kommt die Existenz von Beschleunigern.

Es spielt keine Rolle, ob die Pipeline 10% mehr oder weniger für die 
Verwaltung braucht, wenn 99% der Gesamtrechenzeit für die einzelnen 
Schritte draufgehen. In der früheren Rechentechnik liegen die 
Verhältnisse anders.

Zeit ist Geld.

So viel verschwendete Zeit habe ich schon lange nicht mehr gesehen.

Lieber ARM dran schrieb im Beitrag #5500489:
> Joachim Feist schrieb im Beitrag #5500485:
>> Gegen Zensur und
>> Aussperrung!
>
> Was genau ist eigentlich das Ziel dieser Aktion? Wann wärst du
> zufrieden?
Ich finde, das muss uns nicht interessieren.



Stefanus F. schrieb:
> Ist doch egal, ob hier zensiert wird und was das genau sein soll. Der
> Betreiber des Forums darf das, denn es gehört ihm.
>
> Wer das doof findet, kann ja ein anderes Forum eröffnen und betreiben.
Eben.




S. Landolt schrieb:
> Paul Watzlawick: Anleitung zum Unglücklichsein: "Mehr desselben"
>


> Die Bedeutung dieses Mechanismus für unser Thema liegt auf der Hand. Er
> kann ohne die Notwendigkeit einer Spezialausbildung auch vom Anfänger
> angewandt werden - ja, er ist so weit verbreitet, daß er seit den Tagen
> Freuds Generationen von Spezialisten ein gutes Ein- und Auskommen
> bietet; wobei allerdings zu bemerken ist, daß sie ihn nicht das
> Mehr-desselben-Rezept, sondern Neurose nennen.
>   Doch nicht auf den Namen soll es uns ankommen, sondern auf den Effekt.
> Dieser aber ist garantiert, solange der Unglücksaspirant sich an zwei
> einfache Regeln hält: Erstens, es gibt nur eine mögliche, erlaubte,
> vernünftige, sinnvolle, logische Lösung des Problems, und wenn diese
> Anstrengungen noch nicht zum Erfolg geführt haben, so beweist das nur,
> daß er sich noch nicht genügend angestrengt hat. Zweitens, die Annahme,
> daß es nur diese einzige Lösung gibt, darf selbst nie in Frage
> gestellt werden; herumprobieren darf man nur an der Anwendung dieser
> Grundannahme.
Klasse. Erinnert mich an einen gewissen Physik-Rebellen, wie heißt der 
nochmal, der mit seinen Bindl-Teilchen?   :)

Theor schrieb:
> Naja. Vielleicht ist Rainer ja so gut und erklärt mal was er denn, mit
> "[...] hat [...] auch in Registern "Befehle" versteckt. [...]" gemeint
> hat. Das wäre nett.

Also sorry, das ist alles unendlich lange her und Code kann ich bestimmt 
nicht mehr auftreiben. Ich meine aber, dass einer der "Gags" war, 
Ergebnisse von Rechnungen als Maschinenbefehl zu interpretieren. Und 
natürlich sind heute Tricks auf einem ganz anderen Level angesiedelt. 
Und wie schon gesagt, Optimierung eines Stückchens Assembler-Codes ist 
mit "Trick" ganz und gar unpassend benannt.
Gruß Rainer