AVR Assembler Trick gesucht

[Aussterbende Art (Gast)]

Hallo!

Es soll in das Registerpaar r10:r11 der Wert 10 addiert werden.

ldi hilfsregister,10
add r10,hilfsregister
ldi hilfsregister,0
adc r11,hilfsregister

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. Folgendes zählt also NICHT:

ldi hilfsregister,10
add r10,hilfsregister
adc r11,die_ewige_null

Nun gibt es ja doch so einige schräge Assemblerbefehle. Vielleicht gibts 
da noch einen anderen Trick?

[René H. (Gast)]

Hausaufgaben?

Grüsse,
René

[Yalu X. (yalu) (Moderator)]

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 (Gast)]

Nö. Keine Hausaufgaben. Hobbyprogrammierer.

Wenn es ginge, würde ich wahrscheinlich als nächstes fragen, ob es auch 
mit

cp
cpc

gehen würde.

[Marc V. (Firma: Vescomp) (logarithmus)]

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 (Gast)]

Leider habe ich bewusst das Registerpaar <16 gewählt. Sonst wäre es mit

subi
sbci

noch relativ einfach.

[Aussterbende Art (Gast)]

Und leider gibt es kein cpci...

[Yalu X. (yalu) (Moderator)]

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?

[Marc V. (Firma: Vescomp) (logarithmus)]

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:

 adiw  yl, 10

 noch einfacher.

 EDIT:

  movw  r24, r10
  adiw  r24, 10
  movw  r10, r24

[H.Joachim S. (crazyhorse)]

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

[Yalu X. (yalu) (Moderator)]

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.

[Marc V. (Firma: Vescomp) (logarithmus)]

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).

[Lieber ARM dran (Gast)]

Achja, der easyAVR! Wie kompliziert das doch alles bei ARM ist:

adds r10, #10

duch und wech.

[Peter D. (peda)]

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.

[Stefan F. (Gast)]

> Man kann sich aber auch nen Knopf an die Backe nähen

Nach so einem Spruch hat mein Onkel das mal tatsächlich gemacht - 
angeblich. Ich hätte es gerne gesehen.

[Lieber ARM dran (Gast)]

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

Wäre das nicht eine gute Gelegenheit, Aliase für die Register zu wählen, 
und dann die Belegung bequem umändern zu können?

[Peter D. (peda)]

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.

[Marc V. (Firma: Vescomp) (logarithmus)]

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

[Peter D. (peda)]

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.

[(prx) A. K. (prx)]

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. ;-)

[Yalu X. (yalu) (Moderator)]

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 (Gast)]

Ja ich seh schon, wenn man etwas falsch verstehen will, versteht man 
etwas falsch und der TO muss ein Volldepp sein. Immer. Denn nur der 
eigene Verstand ist ein guter Verstand und alle anderen sind sowieso 
Idioten.

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


wenn ich jetzt einen tiny mit nur 16 Registern habe, kann ich nicht 
einfach einige Register für Konstanten reservieren, da 16 Register nicht 
viele sind. Bei den tinys mit 32 Registern mache ich das natürlich so. 
Nun habe ich mal nachgedacht, ob ich meine Makros so umschreiben kann, 
dass sie nicht mehr auf Gzero angewiesen sind. Das sbc xxx,Gzero kann 
ich gut durch sbci xxx,0 ersetzen. Allerdings geht das beim adc nicht, 
da ein imaginäres adci nicht das gleiche macht wie ein sbci.

Daher kam auch das Beispiel mit add 10. Wenn r10:r11 vorher 250:0 ist, 
und ich 10 hinzufüge, müsste r10:r11 hinterher 4:1 sein. Ein sbci würde 
daraus aber 4:255 machen.

[Marc V. (Firma: Vescomp) (logarithmus)]

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):

   mulsu r21, r22; (signed)bh * al
   sbc r19, r2
   add r17, r0
   adc r18, r1
   adc r19, r2

[Peter D. (peda)]

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:

subi r26, low(-10)
sbci r27, high(-10)

[c-hater (Gast)]

Aussterbende Art schrieb:

> Daher kam auch das Beispiel mit add 10. Wenn r10:r11 vorher 250:0 ist,
> und ich 10 hinzufüge, müsste r10:r11 hinterher 4:1 sein. Ein sbci würde
> daraus aber 4:255 machen.

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

Aber zurück zum Thema:

Deine ursprüngliche Fragestellung stellt NICHT das Problem dar, 
welches du jetzt beschreibst. Du hättest gleich mit dem tatsächlichen 
Problem rausrücken sollen, dann hättest du die Lösung bereits. Nun, im 
konkreten Fall hieße sie allerdings auch nur: es gibt nicht wirklich 
eine, du mußt mehr Takte investieren, wenn du kein NULL-Register 
spendieren willst oder kannst.

Die optimale Lösung hängt vom Gesamtproblem ab. Also: was spart das 
nicht als NULL eingesetzte Register anderswo ein? Ist das mehr als das, 
was es bei der Multiplikation kostet oder nicht?

[Peter D. (peda)]

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.

[(prx) A. K. (prx)]

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 (Gast)]

Peter D. schrieb:

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

Du hast definitiv das Problem nicht verstanden...

Das ist nicht schlimm, der TO selber hat dafür gesorgt, indem er im 
Originalposting ein Problem dargestellt hat, was garnicht sein Problem 
ist. Nachdem er aber nun mit dem rausgerückt hat, was tatsächlich sein 
Problem ist, kann man es verstehen.

Du hast das wohl bloß nicht mehr gelesen, sonst hättest du (vielleicht) 
auch meine Antwort darauf verstanden...

Kann ich dir nicht wirklich zum Vorwurf machen. War Glückssache 
meinerseits, dass ich erst an der Stelle in den Thread eingestiegen bin, 
als der TO mit seinem tatsächlichen Problem rausgerückt hat.

[c-hater (Gast)]

A. K. schrieb:

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

Grundfalsches Argument. Eine ALU kann durchaus verschieden aufgebaut 
sein. Siehe halt ALU.6502 vs. ALU.AVR8.

Worauf ich abziehlte war: Weil die ALU des 6502 so aufgebaut ist, wie 
sie aufgebaut ist, verhält sich das Carryflag dort halt anders als als 
beim AVR8. Und im konkreten Fall wäre es sehr nützlich, würde es sich 
beim AVR8 genauso verhalten wie beim 6502. Denn dann könnte man sbci an 
der inkriminierten Stelle tatsächlich einsetzen ohne einen Takt mehr 
verschwenden zu müssen.

Tut es aber halt leider nunmal nicht, das ist der Punkt...

[(prx) A. K. (prx)]

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.

[H.Joachim S. (crazyhorse)]

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 :-)

[Rainer V. (a_zip)]

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.

[Rainer V. (a_zip)]

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

[S. R. (svenska)]

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.

[Rainer V. (a_zip)]

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

[Carl D. (jcw2)]

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.

[Rainer V. (a_zip)]

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

[Theor (Gast)]

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.
Hast Du da zufällig etwas nähere Informationen, Links oder Anderes? Das 
wäre nett.

[Lieber ARM dran (Gast)]

Eicke Falber schrieb im Beitrag #5500304:
> Stellt Eure Beiträge immer
> wieder rein!

Kannst du erläutern, was genau das bezweckt? Die Mail-Postfächer der 
Abonnenten verstopfen?

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

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

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

[Chris D. (myfairtux) (Moderator)]

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.

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

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

[Lieber ARM dran (Gast)]

Joachim Feist schrieb im Beitrag #5500485:
> Gegen Zensur und
> Aussperrung!

Was genau ist eigentlich das Ziel dieser Aktion? Wann wärst du 
zufrieden?
1. Deine Beiträge bleiben so bestehen, und somit ist irgendwann alles 
voller Spam-Beiträge, das Forum wird unbenutzbar und dann 3.
2. Die Moderatoren springen von einer Brücke, und dann 3.
3. Das Forum wird dichtgemacht
4. Du willst einfach nur alle Mitleser ärgern und dazu bringen diesen 
Thread zu ignorieren
5. ??

[Lieber ARM dran (Gast)]

Würdest du es eigentlich auch als Zensur ansehen, wenn man dich daran 
hindert in Zeitschriften-Redaktionen einzudringen und eine eigenen 
Inhalte einzuschleusen? Findest du, jeder ist dazu verpflichtet alle 
Meinungen weiterzugeben?

[Stefan F. (Gast)]

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.

[S. Landolt (Gast)]

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.

[S. R. (svenska)]

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.

[Stefan F. (Gast)]

Bei den Moderatoren ist das Löschen und Schreiben diverser Scripte Teil 
ihres Jobs.

> Vielleicht begreifen die Loeschmods irgendwann dass sich in einem
> öffentlichen (!) Forum niemand aussperren lässt.

Dass hier jemand ist, der dies nicht zu akzeptieren vermag, haben die 
Moderatoren schon vor weit mehr als einem Jahr verstanden und zahlreiche 
andere Mitglieder haben es auch mitbekommen.

Genügt das nicht? Was soll diese alberne Macht-Demonstration? Du kannst 
nicht gewinnen, weder technisch, noch juristisch.

Du demonstrierst hier lediglich ein ziemlich infantiles Gemüt, und gehst 
allen anderen dabei auf den Sack. Wie fühlst du dich dabei? Ich verrate 
Dir was: Normale und halbwegs normale Menschen würden sich in deiner 
Rolle schlecht fühlen. Viele würden sich nicht einmal gegen Bezahlung so 
verhalten. Der Freak bist du, aber das wissen wir schon lange. Drucke es 
aus und hänge es an all deine Fenster, falls es Dir Genugtuung bringt.

[Theor (Gast)]

S. R. schrieb:
> 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.

Dankeschön.

Ja, klar. Memory-Mapped-IO mit Code und Daten im selben Adressbereich. 
Ist natürlich völlig richtig. Da habe ich allerdings spontan, nicht 
dran gedacht. Das Dankeschön ist in diesem Punkt für die Erinnerung 
daran.

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. (Natürlich gibt es auch CPUs die 
ihre "ALU-Register" im Datenspeicher adressierbar haben. Aber das fällt 
ja irgendwie in den Bereich des obigen Punktes).

Dachte eher an irgendwas "abgefeimtes". :-) Keine Ahnung. 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.

Jedenfalls, danke ich Dir für die Antwort.

[S. R. (svenska)]

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.

[(prx) A. K. (prx)]

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

Das war auch der Grund für deren Existenz.

[(prx) A. K. (prx)]

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.

[Johann L. (gjlayde)]

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.

[Rainer V. (a_zip)]

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

[S. R. (svenska)]

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.

[Theor (Gast)]

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.

[Wolfgang S. (wsm)]

Zeit ist Geld.

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

[M.A. S. (mse2)]

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?   :)

[Rainer V. (a_zip)]

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