Assembler Schleifen Tricks

[H-G S. (haenschen)]

Hallo!

Ich bin im Rahmen eines Assemblerprogramms (8051) zu meinem Projekt 
zufällig auf Folgendes gestossen: Wenn ich eine 
Register-dekrementierende Schleife vorzeitig abbrechen möchte, genügt es 
vor der "ist Null"-Abfrage das Schleifenregister auf "1" zu setzen und 
somit die Abbruchbedingung auf jeden Fall erfüllen zu lassen (DJNZ Rx).

Nun frage ich mich ob es noch mehr solche Assembler-Schleifen-Kniffe 
gibt, googeln brachte nicht viel ...

[Stephan (Gast)]

das geht ja auch nicht zur Laufzeit. Das geht nur in der Simulation.
Ergo ist es kein Trick sondern die Sinnvolle Verwendung der Simulation 
oder des Debuggers.

[Stephan (Gast)]

wenn Du mal in der Simu so eine Schleife von FFh durchgeklickt hast, 
weist Du was gemeint ist :-)))

[(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)]

> googeln brachte nicht viel ...

Ja, fuer einen Trick ist der Ueberraschungseffekt auch ziemlich gering.
Das aus einer Eins nach dem Dekrementieren Null wird.
Das ist auch nicht gerade zufaellig.

Der geeignete Begriff fuer die Suchmaschine waere:
"Assembler Snippets"

Prozessoren die einen eher orthogonalen und regulaeren Aufbau haben,
werden da eher schlecht wegkommen. Da braucht Mann "Tricks" eben nicht.

Trick aus der Praxis:
Zu einer unsigned Variablen 128 dazuaddieren:
Einfach das hoechstwertige Bit (im 8 Bit Register) setzen.
Natuerlich nur sinnvoll auf Architekturen mit schnellen und
kurzen Bitbefehlen.

[Christoph db1uq K. (christoph_kessler)]

Man kann auch eine Adresse auf den Stack pushen und dann einen 
Return-from-subroutine ausführen - wenn man den Code möglichst 
unübersichtlich gestalten will. Code-obfuscation nennt sich sowas.

[H-G S. (haenschen)]

Ich habe noch einen Trick:

Wenn man eine Schleife braucht die den Wert "Null" mitnehmen muss, dann 
fragt man an ihrem Ende nicht das Erreichen von Null ab sondern den 
Überlauf und damit das Carry-Flag.

Das ist bei Adress-Verarbeitung unter Verwendung des Schleifenzählers 
hilfreich, wenn man die Adresse "Null" mitbearbeiten muss - sie also im 
Schleifenzähler stehen muss beim letzten Durchlaufen Schleife.

[Carl D. (jcw2)]

(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag 
#5052016:
> Trick aus der Praxis:
> Zu einer unsigned Variablen 128 dazuaddieren:
> Einfach das hoechstwertige Bit (im 8 Bit Register) setzen.
> Natuerlich nur sinnvoll auf Architekturen mit schnellen und
> kurzen Bitbefehlen.

Unsignd8:    127 | (1<<7) -> 255
             128 | (1<<7) -> 128
             129 | (1<<7) -> 129
             ...
             254 | (1<<7) -> 254
             255 | (1<<7) -> 255

Toller Trick.

[Johann L. (gjlayde)]

unsigned toggle (unsigned i)
{
    return i ^ (1u << 15);
}

avr-gcc:

toggle:
  subi r25,-128
  ret

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

H-G S. schrieb:
> Nun frage ich mich ob es noch mehr solche Assembler-Schleifen-Kniffe
> gibt, googeln brachte nicht viel ...

Ein sehr effektiver Trick bei Schleifen besteht darin, keine zu haben, 
oder zumindest die Anzahl Durchläufe zu reduzieren. Indem man nicht N 
mal eine kurze Schleife durchläuft, sondern N/4 mal eine längere. Loop 
unrolling. Das geht auch wenn N nicht immer durch 4 teilbar ist, wird 
nur ein wenig komplizierter. Siehe Duff’s Device in C.

[Axel S. (a-za-z0-9)]

H-G S. schrieb:

> Ich bin im Rahmen eines Assemblerprogramms (8051) zu meinem Projekt
> zufällig auf Folgendes gestossen: Wenn ich eine
> Register-dekrementierende Schleife vorzeitig abbrechen möchte, genügt es
> vor der "ist Null"-Abfrage das Schleifenregister auf "1" zu setzen und
> somit die Abbruchbedingung auf jeden Fall erfüllen zu lassen (DJNZ Rx).

Aha. Du hast also einen (IMHO sehr gewöhnlichen) Programmiertrick 
gelernt. <gähn>

> Nun frage ich mich ob es noch mehr solche Assembler-Schleifen-Kniffe
> gibt, googeln brachte nicht viel ...

Das ist kein spezifischer "Assembler" Trick. Die Manipulation des 
Schleifenzählers ist eine triviale Technik. Speziell das Setzen des 
Schleifenzählers auf den Endwert ist ein trivialer Kniff für alle 
Programmiersprachen, die keine explizite Syntax für das vorzeitige 
Beenden einer Schleife (etwa break in C) kennen. Ich habe das das 
erste Mal in einem BASIC Programm gesehen ... vor 35(?) Jahren.

Oft wird in einer solchen Situation lieber eine while statt einer 
for Schleife verwendet, wobei der Zähler dann eine gewöhnliche 
Variable ist und die Endbedingung (zähler==endwert) explizit innerhalb 
der Schleife getestet wird. Auch das ist ein allgemeingültiges Idiom für 
Schleifen mit mehreren Abbruchkriterien. Man führt eine Zustandsvariable 
ein, die die eigentliche Schleife steuert und kann dann innerhalb der 
Schleife beliebig viele Kriterien testen und die Variable entsprechend 
setzen.

[H-G S. (haenschen)]

A. K. schrieb:
> Ein sehr effektiver Trick bei Schleifen besteht darin, keine zu haben,
> oder zumindest die Anzahl Durchläufe zu reduzieren. Indem man nicht N
> mal eine kurze Schleife durchläuft, sondern N/4 mal eine längere. Loop
> unrolling. Das geht auch wenn N nicht immer durch 4 teilbar ist, wird
> nur ein wenig komplizierter. Siehe Duff’s Device in C.

Schleifen aufrollen wurde im letzten Buch über Parallel-Prozessoren 
erwähnt als Mittel zur Auslastung aller Kerne. Aber immer 4 Durchgänge 
aufzurollen ist mir unbekannt - danke dir!


Axel S. schrieb:
> Das ist kein spezifischer "Assembler" Trick. Die Manipulation des
> Schleifenzählers ist eine triviale Technik. Speziell das Setzen des
> Schleifenzählers auf den Endwert ist ein trivialer Kniff für alle
> Programmiersprachen, die keine explizite Syntax für das vorzeitige
> Beenden einer Schleife (etwa break in C) kennen. Ich habe das das
> erste Mal in einem BASIC Programm gesehen ... vor 35(?) Jahren.

Immerhin spart die Zähler-Manipulation einen Sprungbefehl hinter die 
Schleife.

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

H-G S. schrieb:
> Schleifen aufrollen wurde im letzten Buch über Parallel-Prozessoren
> erwähnt als Mittel zur Auslastung aller Kerne.

Buch nochmal lesen oder gleich wegwerfen. Loop unrolling führt nicht 
dazu, dass mehrere Prozessorkerne besser ausgelastet werden. Allenfalls 
mehrere execution units eines Kerns. Und auch das ist beim 8051 recht 
unwahrscheinlich.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Wo ihr gerade so schön über Assemblertricks schreibt und wie man 
bestimmte Routinen nennt.

Wo findet bzw. lernt man diese Dinge ?
Kommt mir jetzt nicht mit Google, denn dem muss ich auch erstmal klar 
machen was ich will. Ist halt eine Massenabfertigungsmaschine. Bei 
individuellen Problemen sucht man sich tod.

Und bitte noch mehr allgemeine AVR-Assemblertricks !


Bernd_Stein

[(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)]

Gelegentlich sorgen auch mal Compiler fuer ein "Aha"-Erlebnis.
Z.B. beim Verwursten eines Switch-Case.

Der XC8 macht aus den "Cases" jeweils ein XOR und testet auf
(Nicht-)Null.

  switch(c){
  case 'a':
  case 'A':  d=0x41;  break;
  case 'b':
  case 'B':  d=0x42;  break;
  }


  movf  (main@c),w
...
  xorlw  65^0  ; case 65
  skipnz
  goto  l886
  xorlw  66^65  ; case 66
  skipnz
  goto  l888
  xorlw  97^66  ; case 97
  skipnz
  goto  l886
  xorlw  98^97  ; case 98
  skipnz
  goto  l888
  goto  l894

Sehr raffiniert ist die Berechnung des jeweiligen Intermediatewertes...

[H-G S. (haenschen)]

Scheinbar gibt es für x86 einen Haufen Literatur über 
Assembler-Programmierung.

Aber dieser Prozessor stösst mich ab mit seinen vielen Registern etc.

[Heinz V. (heinz_v)]

H-G S. schrieb:
> Aber dieser Prozessor stösst mich ab mit seinen vielen Registern etc.

AX = Akkumulator, BX = Basisregister, CX = CountRegister, DX = 
DataRegister, BP = BasePointer, SP = Stackpointer, SI = Sourceindex, DI 
= Destinationindex, IP = Instruction Pointer Und PSW = 
ProzessorStatusWort (Flags),

Das ist doch noch recht übersichtlich...

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

(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag 
#5054197:
> Der XC8 macht aus den "Cases" jeweils ein XOR und testet auf
> (Nicht-)Null.

Macht jeder ernsthafte Compiler, nur meist mit sukzessiver Subtraktion 
statt XOR. Allein schon, weil es meist Kurzformen gibt, die nur wenige 
Bits der Konstanten im Opcode codieren, wie DEC oder 1..8 (68000).

[Axel S. (a-za-z0-9)]

Bernd S. schrieb:
> Wo ihr gerade so schön über Assemblertricks schreibt und wie man
> bestimmte Routinen nennt.
>
> Wo findet bzw. lernt man diese Dinge ?

Ich habe Programmieren gelernt indem ich

a) selber programmiert habe ... und mich dann oft geärgert habe, daß 
auch mein bester Code immer noch Faktor 2 ... 100 langsamer war als der 
vom "Klassenbesten". OK, das war kein Produktionscode, sondern Dinge wie 
Grafikeffekte auf dem C64. Und mittlerweile ist es oft anders herum. Bei 
meinem letzten Arbeitgeber hatte ich den Ruf, jedes nichttriviale 
Perl-Skript halb so lang und mit doppelter Geschwindigkeit schreiben zu 
können. Und meist sogar noch lesbarer :)

viel wichtiger war aber

b) fremden Code lesen. Das hilft natürlich nur bei nur Code, der besser 
ist als der eigene, weswegen es ohne a) dann doch nicht geht.

Andererseits sollte man solche Tricks nicht überbewerten. Die größten 
Gewinne erzielt man mit der Auswahl des am besten geeigneten 
Algorithmus, nicht damit, ein paar CPU-Zyklen hier oder da einzusparen. 
Gefragt ist also möglichst breit gestreutes Wissen. Und die 
Bereitschaft, über den Teller zu schauen und neue Entwicklungen zu 
erkennen.

[H-G S. (haenschen)]

Ich stehe selber gerade vor dem Problem, eine Speicherkarte mit einem 
seriellen EEPROM über die IO-Anschlüsse eines 8051-Systems anzusteuern.

Eine Aktualisierung der IO-Ausgabe dauert satte 3,5ms, weil ich das 
zuständige Schiebe-Unterprogramm mit Schleifen machen musste um nicht 
soviele Programmbytes zu haben.

Alles zusammen wird wohl darauf hinauslaufen, dass ein Speichervorgang 
auf die Speicherkarte mit 32kB Daten bis zu einer halben Stunde dauert.

Das schreit geradezu nach einer Optimierung des 
IO-Schiebe-Unterprogrammes, denn jede Millisekunde bringt später ein 
paar Minuten  :-)

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

@Axel Schwenke (a-za-z0-9)

Danke für deinen Erfahrungsbericht. Ich studiere Codes von PeDa und 
HannesLux. Doch das ist mir zu hoch. PeDa programmiert ja nur noch 
selten in Assembler und Hannes hat sich endgültig verabschiedet, den 
kann ich also nicht mehr fragen was er sich da gedacht hat.

Ich fragte nach diesen Dingen, da hier öfters mal Routinen bestimmte 
Namen haben und ich dachte, so etwas lernt man dann als " gelernter " 
Programmierer.

Sich abzugucken wie andere das machen, die mehr Erfahrung haben als man 
selbst, ist ein zweischneidiges Schwert. Zum einen weiß man ja gar 
nicht, ob diese Person es drauf hat und zum anderen gewöhnt man sich 
dann dessen Stil evtl. an. Und jeder weiß, wie schwierig es ist, 
schlechte Gewohnheiten los zu werden ;-)

Scott-Falk Hühn macht viele sehr gute Projekte. Was jedoch sein 
Programmierstil anbetrifft, kommt es mir vor, das er einfach nur das 
jeweilige Projekt fertig haben will und sich nicht darum kümmert, ob der 
Code  gut strukturiert bzw. lesbar ist. Das Gute ist, das man da 
wenigstens etwas durchblickt, da er nicht mit " Tricks " überflutet ist 
wie bei den anderen beiden genannten Leuten.

Aber wirklich beurteilen kann ich das nicht, habe nämlich nur eines 
seiner Projekte für mich angepasst und bin ihn für diese sehr gut 
gemachten Open Source Projekte dankbar.

Beitrag "Temperaturmesssystem Sensormodul 2 mit ATmega 8 in AVR-ASM"

http://www.hanneslux.de/


Bernd_Stein

[Axel S. (a-za-z0-9)]

Bernd S. schrieb:
> @Axel Schwenke (a-za-z0-9)
>
> Danke für deinen Erfahrungsbericht. Ich studiere Codes von PeDa und
> HannesLux. Doch das ist mir zu hoch.

> Sich abzugucken wie andere das machen, die mehr Erfahrung haben als man
> selbst, ist ein zweischneidiges Schwert. Zum einen weiß man ja gar
> nicht, ob diese Person es drauf hat und zum anderen gewöhnt man sich
> dann dessen Stil evtl. an.

Ich verstehe was du meinst, aber so schlimm ist es doch wieder nicht. Es 
geht ja erst mal nur darum, verschiedene Lösungen des gleichen Problems 
anzusehen und zu vergleichen. Im Minimum deine eigene Lösung und die von 
jemand anderem. Objektive Kriterien wie Codegröße und Laufzeit kann man 
dann unabhängig vom Stil anwenden. Nicht zu vergessen Lesbarkeit. Und 
wenn du dann etwas siehst, was ein anderer besser macht, übernimmst du 
es in dein Repertoire.

> Scott-Falk Hühn macht viele sehr gute Projekte. Was jedoch sein
> Programmierstil anbetrifft, kommt es mir vor, das er einfach nur das
> jeweilige Projekt fertig haben will und sich nicht darum kümmert, ob der
> Code  gut strukturiert bzw. lesbar ist.

Ja, das sieht man in der Tat oft. Aber wenn du das erkennen kannst, bist 
du ja schon mal einen Schritt voran gekommen. Interessant wird die Sache 
dann, wenn dir jeglicher fremder Code als umständlich und häßlich 
erscheint und du ihn besser hinschreiben könntest. Aber keine Sorge, das 
dauert eine Weile ;)

[Peter D. (peda)]

H-G S. schrieb:
> Wenn ich eine
> Register-dekrementierende Schleife vorzeitig abbrechen möchte, genügt es
> vor der "ist Null"-Abfrage das Schleifenregister auf "1" zu setzen und
> somit die Abbruchbedingung auf jeden Fall erfüllen zu lassen (DJNZ Rx).

Das hängt vom Kontext ab.
Will ich sofort raus, dann springe ich einfach raus.
Die Schleifenvariable auf 1 zu setzen hat aber den Effekt, daß der 
Schleifendurchgang noch beendet wird. d.h. bestimmte Aktionen noch 
ausgeführt werden sollen. Es ist quasi ein Merker, daß dies der letzte 
Durchgang sein soll.
Das ist aber kein Assemblertrick, sondern wird in Hochsprachen auch so 
gemacht.
In Assembler ist nur wesentlich schlechter zu durchschauen, welche 
Intention der Autor damit hat.

[Patrick J. (ho-bit-hun-ter)]

Hi

Hat nicht wirklich was mit Schleifen zu tun, aber beim 80286er hatte ich 
mir abgeguckt, daß man Register per XOR mit sich selbst auf Null setzt - 
mir ist aber nicht mehr bekannt, ob Das ein Byte gespart hat statt einem 
MOV CX,0 ein XOR CX,CX zu schreiben.

Sonst fällt halt bei Schleifen auf, daß Diese in Assembler sehr oft auf 
Null runter laufen (Zero-Flag) oder, wie oben genannt wurde, auf Carry, 
wenn die Null selber als Durchlauf gebraucht wird, wobei man dann aber 
nicht mit DEC arbeiten darf, da dort nur das ZF gesetzt wird! (zumindest 
beim AVR)

MfG

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

Patrick J. schrieb:
> mir ist aber nicht mehr bekannt, ob Das ein Byte gespart hat statt einem
> MOV CX,0 ein XOR CX,CX zu schreiben.

Das genau ist der Sinn davon. Bis heute. Die Prozessoren erkennen 
allerdings diese Spezialfälle und behandeln sie anders.

> nicht mit DEC arbeiten darf, da dort nur das ZF gesetzt wird! (zumindest
> beim AVR)

x86 auch. INC/DEC konnte manche Schleife beim Pentium 4 bös aus der 
Kurve werfen, wenn eine künstliche Abhängigkeit über das Flags-Register 
die Iterationen serialisierte. Mit ADD/SUB waren die plötzlich viel 
schneller.

[spess53 (Gast)]

Hi

>Hat nicht wirklich was mit Schleifen zu tun, aber beim 80286er hatte ich
>mir abgeguckt, daß man Register per XOR mit sich selbst auf Null setzt -

Wie wundersam

Opcode CLR ist 0010 01dd dddd dddd
Opcode EOR ist 0010 01rd dddd rrrr

Fällt dir etwas auf?

MfG Spess

[H-G S. (haenschen)]

Ich habe es geschafft meine IO-Ausgabe-Zeit von 3,5ms auf 1,4ms zu 
senken!

Ich habe die innere Schleife aufgerollt ... da war sogar ein LCALL nebst 
RET drin, also ein Unterprogrammaufruf nebst Rücksprung in der innersten 
Schleife. Hat gerade noch in den Speicher gepasst in der aufgerollten 
Form. Es sind insgesamt 8 kleine Programmteile die sich wiederholen 
durch das Aufrollen.

Die ganze Schleife aufzurollen bringt fast nichts, der Flaschenhals war 
wirklich das Innerste mit seinem Unterprogramm-Aufruf.

[Patrick J. (ho-bit-hun-ter)]

Hi

spess53 schrieb:
> Opcode CLR ist 0010 01dd dddd dddd
> Opcode EOR ist 0010 01rd dddd rrrr
>
> Fällt dir etwas auf?

Beim 80286 waren Das aber - meines Wissen - verschiedene Befehle, 
weshalb Das wohl so gemacht wurde.

Davon hat der AVR noch Mehr anzubieten ;)
EOR/CLR
ANDI/CBR
ORI/SBR
TST/AND
LSL/ADD
ROL/ADC

... fanden sich bisher ein. Eine genauso 'powerful', wie die Andere :|

MfG

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

Patrick J. schrieb:
> Beim 80286 waren Das aber - meines Wissen - verschiedene Befehle,

Ja. Ich erinnere mich bei 8086 nur an einen Befehl, der als Sonderfall 
eines anderen Befehls einen zweiten Namen bekam: XCHG AX,AX als NOP. Es 
gibt natürlich noch ein paar Sprungbedingungen mit 2 Namen, aber das 
sind einfach nur exakte Synonyme.

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

Patrick J. schrieb:
> ANDI/CBR
> ORI/SBR

Wobei ich CBR/SBR eher als Tretmine betrachte, nicht aber als nützliche 
Schreibweise. Weil anders als bei CBI/SBI und SBIC/SBIS nicht etwa eine 
Bitnummer angegeben wird, sondern eine Maske. Hätte nicht sein müssen.

[spess53 (Gast)]

Hi

>Beim 80286 waren Das aber - meines Wissen - verschiedene Befehle,
>weshalb Das wohl so gemacht wurde.

Dazu müsste ich jetzt meine X86 Assembler-Bücher heraussuchen.

>Davon hat der AVR noch Mehr anzubieten ;)

Und du meist, das mir das nach 20 Jahren AVR-Assemblerprogrammierung und 
einem eigenen Disassembler verborgen geblieben wäre?

MfG Spess

[Heinz V. (heinz_v)]

xor cx, cx vs. mov cx, 0

  219 0083  B9 00 00                          mov cx, 0
  220 0086  33 C9                             xor cx, cx
A86 V4.05 assembly of bresen04.OBJ

[Patrick J. (ho-bit-hun-ter)]

Hi

spess53 schrieb:
> und einem eigenen Disassembler verborgen geblieben wäre?

Oha, mein Disassembler hieß DEBUG (DOS) und über die Befehlsgleichheit 
beim AVR bin ich auch nur gestolpert.
Wobei sich die Sprungbefehle
BRCS/BRLO halt gesprochen besser verwenden lassen - wenn ich auf CF 
prüfen will, nehme ich 'Carry set', wenn ich auf Kleiner prüfen will, 
den mit 'LO' - liest sich einfach besser, wenn auch beim Disassemblieren 
wohl immer nur einer der Befehle zur Anzeige kommt - Da muß man dann 
halt wissen, daß Beide identisch sind.

Per CBR/SBR habe ich mich auch schon verarscht :)
Glaube, Da muß man durch (wobei die Befehle ja Clear/Set Bitssssss in 
Register heißen, wobei CBI/SBI Clear/Set Bit in IO, ohne 's' an dem Bit 
- klar, ein Lump, Der Böses dabei denkt)

MfG

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

Patrick J. schrieb:
> BRCS/BRLO halt gesprochen besser verwenden lassen - wenn ich auf CF
> prüfen will, nehme ich 'Carry set', wenn ich auf Kleiner prüfen will,
> den mit 'LO' - liest sich einfach besser,

Hinzu kommt, dass je nach Konstruktion der ALU "carry set" mal "unsigned 
lower" entspricht (AVR,x86) und mal "unsigned higher or same" 
(6502,ARM).

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Und bitte noch mehr allgemeine AVR-Assemblertricks !
>
In etwa so wie beim HC11 ( Hip Hop HC11 ) oder ist sowas heute nicht 
mehr nötig ?

http://docplayer.org/15911692-Assembler-tricks-fuer-den-68hc11.html


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Im Buch von Manfred Schwabl-Schmidt "AVR-Programmierung" Band 1 sind im 
Kapitel 11
"Die Realisierung von Programmstrukturen", Schleifentricks vorhanden, 
wie man die Durchlaufzeit verkürzen kann.

Mir ist jedoch dieser Schwabl-Schmidt, zu hoch mit seinen ganzen 
Abkürzungen wie z.B. :

lpm r0,Z+ ;r0 <- vbP[k+n - 2µ-1)]

Erstellt ihr eigentlich einen PAP, also einen Programmablaufplan, bevor 
ihr programmiert ?


Bernd_Stein

[Stefan F. (Gast)]

> Erstellt ihr eigentlich einen PAP, also einen
> Programmablaufplan, bevor ihr programmiert ?

Nö. Wenn schon, dann stark vereinfacht für's Management. Die wahre 
Komplexität gewöhnlicher Programme verstehen die ohnehin nicht.

Aber ich kommentiere viel und dokumentiere in Textform (Wiki). Oft sind 
da auch Diagramme bei, aber die beschreiben eher Abläufe der 
Geschäftslogik als den Quelltext.

[Einer K. (Gast)]

Bernd S. schrieb:
> Erstellt ihr eigentlich einen PAP, also einen Programmablaufplan, bevor
> ihr programmiert ?

Hmm...
In Form von Skizzen, in der Entwurfsphase.
Wenn es komplizierter wird.

Weit häufiger kommen bei mir Statediagramme und auch Datenflussdiagramme 
vor.
Ich finde Datenflussdiagramme werden oft unterbewertet.
Zumindest mir, sind sie häufig eine bessere Hilfe, als 
Programmflussdiagramme.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Arduino Fanboy D. schrieb:
> Hmm...
> In Form von Skizzen, in der Entwurfsphase.
> Wenn es komplizierter wird.
>
Wahrscheinlich mit Bleistift, Papier und Radiergummi - oder ?



Stefanus F. schrieb:
> Nö. Wenn schon, dann stark vereinfacht für's Management.
>

Ich finde gerade bei ASM, wo viele Zeilen "wenig" bewirken, ist es doch 
von Vorteil einen PAP zu haben, der mit wenig Blöcken, das darstellt was 
die vielen Zeilen Code eigentlich verrichten.
Mein Problem ist, das ich mit einem PAP anfange, aber dann bemerke da da 
was fehlt oder an anderer Stelle besser aufgehoben. Das Radieren ist 
dann meist so störend, das ich den PAP nicht mehr pflege, aber ihn dann 
zum Schluß erstelle.
Da jedoch schnell der Überlick fehlt, wenn mehr als eine Bildschirmseite 
getippt ist, wäre es für mich schön diese Programm im Video zu haben.
Man kann schnell geraden zeichnen und was hinkritzeln und halt 
wegradieren.
Toll wäre es, wenn man auch Teile markieren und verschieben könnte. Das 
habe ich nämlich in dem Video nicht gesehen.

Bitte keine Tipps für richtige PAP-Erstellungsprogramme.


Bernd_Stein

[Sepp (Gast)]

Ohne PAP und ausführliche Kommentare hat man doch keine Chance in 
Assembler. Aus nackten Mnemonics wird niemand schlau.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Sepp schrieb:
> Ohne PAP und ausführliche Kommentare hat man doch keine Chance in
> Assembler. Aus nackten Mnemonics wird niemand schlau.
>
Niemand, wahrscheinlich. Die Meisten => bestimmt nicht.

Genau deshalb suche ich ja das Programm, das der Inder benutzt. Hier das 
vorher vergessene Video. Die ersten 20 Sekunden bleibt es erstmal 
schwarz :

https://www.youtube.com/watch?v=BKg2hoD89jY&list=PLRuRKN7_FVgvhdj6JmelCihl6jmKHc_Xt


Bernd_Stein

[Stefan F. (Gast)]

In Assembler habe ich schon lange nicht mehr ein ganzes Programm 
geschrieben. Höchsten ein paar einzelne Zeilen, um es besser zu machen, 
als C. Das kommt nur noch selten vor, weil der Compiler immer besser 
wird und die Chips immer schneller.

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

Bernd S. schrieb:
> Genau deshalb suche ich ja das Programm, das der Inder benutzt. Hier das
> vorher vergessene Video. Die ersten 20 Sekunden bleibt es erstmal
> schwarz :

 LOL.
 Fast 15 Minuten um erfolglos zu versuchen etwas zu zeichnen und zu
 erklären, dass in jedem Datenblatt viel besser (und akzentfrei) erklärt
 wird und ausserdem viel besser gezeichnet ist.

[Sepp (Gast)]

Auf youtube ist ein Video wo einer die Verschlüsselung des Sega Saturn 
CD gecrackt hat ...da sieht man kurz ein heftiges 
Disassemblier-Programm.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Marc V. schrieb:
> LOL.
>  Fast 15 Minuten um erfolglos zu versuchen etwas zu zeichnen und zu
>  erklären, dass in jedem Datenblatt viel besser (und akzentfrei) erklärt
>  wird und ausserdem viel besser gezeichnet ist.
>
Mir geht es um das Programm das der Inder benutzt, damit damit mein PAP 
zeichnen und evtl. auch für die Dokumentation ausdrucken kann.

P.S.
Haben wir nicht gerade die Inder als Fachkräfte eingeladen zu uns ins 
Land zu kommen, da sie hervorragende Programmierer sind ?


Sepp schrieb:
> Auf youtube ist ein Video wo einer die Verschlüsselung des Sega Saturn
> CD gecrackt hat ...da sieht man kurz ein heftiges
> Disassemblier-Programm.
>
Was hat das jetzt mit dem Programm des Inders zu tun ?


Bernd_Stein

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

Bernd S. schrieb:
> Mir geht es um das Programm das der Inder benutzt, damit damit mein PAP
> zeichnen und evtl. auch für die Dokumentation ausdrucken kann.

 Word, Excel?

[Stefan F. (Gast)]

Wenn du eine Software zum Erstellen von Diagrammen suchst, kann ich Dir 
"yEd" empfehlen.

[Rainer V. (a_zip)]

Hallo, wie ich schon an anderer Stelle gesagt habe, würde ich 
Code-Optimierung, für welchen Parameter auch immer, eher selten als 
Trick bezeichnen. Natürlich muß man sich manchmal die Befehle recht 
genau anschaun, um heraus zu kriegen, wo da was zu optimieren ist, aber 
das ist doch nur die übliche Arbeit...
Größere Projekte in ASM unterteile ich konsequent in Unterprogramme, die 
leicht zu prüfen sind. Dann wird das Ganze im Hauptprogramm Stück für 
Stück zusammengebracht und läuft dann meist auch auf Anhieb :-) Hat auch 
(für mich) den Vorteil, dass ich eine hübsche Bibliothek mit Funktionen 
zur Verfügung habe, aus der ich einfach kopieren kann. Beispiel wären 
die Routinen, um ein LCD-Display anzusprechen. Das ist ein Block, der 
als Unterprogramm in den Code kommt und schon hat sich LCD als Problem 
erledigt.
Ist natürlich mein persönlicher Stil, der auch nur mir gefallen muß :-)
Gruß Rainer

[c-hater (Gast)]

Bernd S. schrieb:

> Mir ist jedoch dieser Schwabl-Schmidt, zu hoch mit seinen ganzen
> Abkürzungen wie z.B. :
>

> 
> lpm r0,Z+ ;r0 <- vbP[k+n - 2µ-1)]
> 
>

Häh? Ich denke, mir fehlt da auch gewaltig der Kontext. Jedenfalls der 
zum Verständnis des Kommentars. Der ist ja schlimmer, als C je sein 
könnte...

Was "lpm r0,Z+" macht, ist ja eigentlich selbsterklärend, zumindest 
nachdem man den Eintrag zu lpm in der instruction set reference gelesen 
hat. R0 als Ziel scheint der Kommentar auch nicht weiter zu erleuchten, 
das bleibt einfach R0 als Ziel.

Was man dem Kommentar vielleicht noch entnehmen kann, wäre der (bei 
einem Postinkrement) durchaus naheliegende Sachverhalt, dass da 
irgendwas aus einem array gelesen wird. Das sollen wohl die eckigen 
Klammern andeuten, womit dann wohl "vbP" der offensichtlich 
klartextverschlüsselte Name des arrays wäre. Na hoffen wir mal, das 
wenigstens ein entsprechend benamstes und dokumentiertes Symbol für die 
Basisadresse dieses Arrays existiert...

Aber schon in der Notation zeigt sich, dass hier ein dramatisch 
vorbelasteter Typ agiert. Denn natürlich sind eckige Klammern nicht von 
Natur aus dazu bestimmt, Array-Indizes (also Indirektionen, ggf. mit 
Offsets) zu bezeichnen. Ja, in C und Pascal und etlichen anderen 
Hochsprachen tun sie das, auch in vielen Assemblerdialakten. Aber schon 
in Pascal tun sie nicht nur das und in anderen Sprachen (z.B.: Basic in 
unzähligen Varianten) tun sie das nicht. Sowas zur Dokumentation eines 
Assembler-Quelltextes einzusetzen, dessen Assembler eben dies auch nicht 
tut... Naja, ich muss gestehen, ich mache es auch so, denn ich bin auch 
vorbelastet...

Aber innerhalb der eckigen Klammern wird es dann endgültig völlig 
abstrus. Ein unvollständiger runder Klammerausdruck. Das gibt es legal 
in keiner Sprache, die ich beherrsche...

Aber natürlich: Mit mehr Kontext würde man ziemlicher sicher k deuten 
können als eine Konstante die irgendwo "vorher" schon zum Inhalt von Z 
addiert wurde und n dürfte wohl das Postinkrement ausdrücken, aber der 
unvollständige Klammerausdruck sowie 2µ und die -1 bleiben völlig im 
Dunkeln. Wobei man -2µ und -1 vermutlich aus dem noch weiteren Kontext 
ebenfalls eruieren könnte. Bleibt diese ominöse Klammer zu erklären...

[R. F. (rfr)]

In diesem Zusammenhang wäre das Lesen eines Buches recht interessant.

Zum Beispiel dieses hier.   https://www.jjj.de/  matters Computational..
Aber der Rest ist auch interessant.

Robert

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Marc V. schrieb:
> Bernd S. schrieb:
>> Mir geht es um das Programm das der Inder benutzt, damit damit mein PAP
>> zeichnen und evtl. auch für die Dokumentation ausdrucken kann.
>
>  Word, Excel?
>
Danke, das du wenigstens konkret auf meine Frage eingehst.

Ist doch bestimmt was selbst zusammengestelltes - oder ?

Habe nur OpenOffice und dort unter Tabellendokument ( EXCEL ) bei Extras 
=> Galerie, eigentlich nur brauchbar für diese Zwecke Pfeile gefunden.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Wenn du eine Software zum Erstellen von Diagrammen suchst, kann ich Dir
> "yEd" empfehlen.
>
Ah, das sieht gut aus. Habe mir gerade dieses Video dazu angesehen. So 
weit ich verstanden habe ist es auch kostenlos.
Danke, das auch du konkret auf meine Frage eingegangen bist und ich 
wahrscheinlich doch so ein spezielles PAP-Programm nutzen werde, obwohl 
ich es nicht wollte.

c-hater schrieb:
> Bernd S. schrieb:
>
>> Mir ist jedoch dieser Schwabl-Schmidt, zu hoch mit seinen ganzen
>> Abkürzungen wie z.B. :
>>>
>> lpm r0,Z+ ;r0 <- vbP[k+n - 2µ-1)]
>>
>>
> Häh? Ich denke, mir fehlt da auch gewaltig der Kontext. Jedenfalls der
> zum Verständnis des Kommentars. Der ist ja schlimmer, als C je sein
> könnte...
>
Das mit der unvollständigen Klammer steht wirklich so im Buch, ist aber 
sehr wahrscheinlich ein Druckfehler. Da ich diesen Schwabl-Schmitdt eh 
nicht verstehe, bin ich mir da aber gar nicht so sicher.

Es ist mir leider zu aufwendig, sich über die Art und Weise wie 
Schwabl-Schmidt in ASM programmiert schriftlich auszutauschen, daher 
bleibt mir nur der Verweis auf sein Buch. Und wie nochmals erwähnt raff 
ich da 0,1% des ganzen Buches. Eigentlich habe ich es gar nicht ganz 
gelesen, da es mir zu komplex ist.

https://www.youtube.com/watch?v=ujMhxPJnJCw


Bernd_Stein

[Toxic (Gast)]

Bernd S. schrieb:
> Stefanus F. schrieb:
>> Wenn du eine Software zum Erstellen von Diagrammen suchst, kann ich Dir
>> "yEd" empfehlen.
>>
> Ah, das sieht gut aus.

yEd ist in der Tat freie Software.Da hat der @Stefanus dir einen guten 
Tip gegeben.Verwende es selbst seit Jahren zur Dokumentation meiner 
"tollen ?" Software
Das beste an dem Programm ist,dass man dazu noch nicht einmal ein 
Handbuch benoetigt - innerhalb weniger Minuten ist man damit vetraut.

Mein Tip: Downloaden und loslegen...

[Rainer V. (a_zip)]

Liebe Leute, ich weiß wirklich nicht, was ihr hier macht! Ihr habt da 
ein Programm zwischen, das was macht? Natürlich bin ich zu dumm, um auch 
nur ansatzweise zu verstehen, wovon ihr redet. OK, ich sterbe dumm...
Gruß Rainer

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Rainer V. schrieb:
> Hallo, wie ich schon an anderer Stelle gesagt habe, würde ich
> Code-Optimierung, für welchen Parameter auch immer, eher selten als
> Trick bezeichnen.
>
Ich will mich jetzt nicht über Begrifflichkeiten streiten, aber für mich 
ist das folgende schon ein Trick. Man könnte es natürlich auch als 
Codehack bezeichnen ( In Ableitung von Lifehack => Wikipedia ).

Und zwar geht es im Buch von Schwabl-Schmidt im erwähnten Kapitel, hier 
darum, eine 16-Bit Schleife ( Um Durchläufe >256 zu realisieren ), 
Taktoptimiert zu erstellen. Der Codehack besteht nun darin, nur 
8-Bit-Schleifen zu verwenden.

Klassisch ( 16-Bit ):

    ldi  r30, LOW(2vbP)   ;1   Z <- 2vbP fuer lpm-Befehl
    ldi  r31,HIGH(2*vbP)  ;1
    ldi  r26, LOW(vbD)    ;1   X <- vbD Zieladresse
    ldi  r27,HIGH(vbD)    ;1
    ldi  r24, LOW(n)      ;1   v <- n (Schleifenindex v in U )
    ldi  r27,HIGH(n)      ;1
M:  lpm  r0,Z+            ;3n  r0 <- vbP[n-v]
    st   x+,r0            ;2n  vbD[n-v] <- r0
    sbiw r25:r24,1        ;2n  v <- v-1
    brne M                ;2n-1 Neuer Durchlauf bei v>0
;
;Die Gesamtzahl der für das Kopieren verbrauchten Takte ist
;6+9n-1 ~ 9n, also 9 Takte pro Byte für genügend grosses n.                          ;

Als erstes wunderte mich das einmal (2vbP) steht und dann (2*vbP). 
Wahrscheinlich kann das * gespart werden ( weniger zu tippen ;-) ).

Weiterhin irritierte mich, warum die Kombination r24:r27 für U ?

Bis mir das Licht aufgegangen war, das U praktisch für mich, 
logischerweise W sein müsste ( wegen  W,X,Y,Z ). Also einfach ein 
Druckfehler. Es muss für r27, r25 stehen. Sowas macht einem der sowieso 
sehr schlecht durch die ganzen Abkürzungen und Formeln durchblickt es 
noch einen Tick schwerer. Zudem kommt ja noch hinzu, das es hier um 
Codehacks geht und man natürlich versucht zu erkennen, wo jetzt genau 
der Trick steckt. Oben im Beispiel gibt es natürlich keinen, da dies ja 
die klassische Ausführung ist. Aber als Einsteiger muss man das dann 
erstmal erkennen.

Jetzt kommt eine Möglichkeit des Codehacks. Was seiner Aussage nach, 
aber noch nicht das Optimum ist.

    ldi   r30, LOW(2vbP)   ;1   Z <- 2vbP für lpm-Befehl
    ldi   r31,HIGH(2*vbP)  ;1 
    ldi   r26, LOW(vbD)    ;1   X <- vbD Zieladresse
    ldi   r27,HIGH(vbD)    ;1
    ldi   r17,n >> 8       ;1   Startwert Zähler für äussere Schleife
M1: ldi   r16,0            ;q   Startwert 256 für Zähler innere Schleife
M2: lpm   r0,Z+            ;3c  r0 <- vbP[v]
    st    X+,r0            ;2c  vbD[v] <- r0
    dec   r16              ;c   
    brne  M2               ;2c-1
    dec   r17              ;q
    brne  M1               ;2q-1
    ldi   r16,n & 0xFF     ;1   Startwert für Zähler Restschleife
M3: lpm   r0,Z+            ;3p  r0 <- vbP[v]
    st    X+,r0            ;2p  vbD[v] <- r0
    dec   r16              ;p
    brne  M3               ;2p-1
;
;Als Summe aller verbrauchten Takte erhält man hier 5+q+8c-1+q+2q-1+1+8p-1 ;= 3+4q+8c+8p. Mit c = 256q = n-p ergibt sich daraus 3+4q+8(n-p)+8p = ;3+4q+8n ~ 8n und damit *nur* 8 Takte pro Byte.
;Die Kopierzeit lässt sich "mühelos" noch weiter verringern,...
;

Man beachte, das hiermit ein ganzer Takt pro Byte gegenüber dem ersten 
Listing gespart wurde und man mühelos ... !

Wenn das nicht trickreich oder halt ein Codehack ist, dann weiß ich auch 
nicht. Auf jedenfall ist so was wohl etwas für Leute, mit besonderen 
Gaben, ne geile Sache. Für mich hat das Züge eines Autisten, von dennen 
einige wirklich besondere Leistungen an den Tag bringen können.


Rainer V. schrieb:
> Natürlich bin ich zu dumm, um auch
> nur ansatzweise zu verstehen, wovon ihr redet. OK, ich sterbe dumm...
> Gruß Rainer
>
Tröste dich, da sind wir garantiert nicht die Einzigen.


Bernd_Stein

[Sepp (Gast)]

Mir fällt es auch immer schwer, abgedtruckte Assembler-Programme zu 
verstehen. Scheinbar gibt es da keine Normen.

[Thomas E. (picalic)]

Bernd S. schrieb:
> Wenn das nicht trickreich oder halt ein Codehack ist, dann weiß ich auch
> nicht.

Ist das jetzt ehrlich gemeint oder ironisch? Für mich (als nicht-AVR 
Programmierer) sieht der abgedruckte Code eher nicht wie ein 
Geniestreich, sondern fehlerhaft aus. Wenn n z.B. genau das Vielfache 
von 256 ist, werden 256 Bytes zuviel kopiert. Und wenn n<256 ist, sogar 
64K! Solche Einschränkungen sollten wenigstens als Kommentar im 
Quelltext vermerkt sein. Konsequent Zyklen gespart kat der Autor auch 
nicht (warum springt er in der äußeren Schleife auf M1 zurück, wo doch 
in R16 an dieser Stelle sowieso 0 steht? Ist sowas vielleicht mit "noch 
nicht das Optimum" gemeint?

Ich denke, ich würde diesen "Hack" (wie gesagt, bin kein AVR-Spezialist) 
kürzer und mit weniget Zyklen hinkriegen...

[Thomas E. (picalic)]

So könnt's gehen (kurz, schnell und (hoffentlich:-)) richtig):

     ldi   r30, LOW(2*SOURCE)   ;1   Z <- ROM Source Adresse für lpm-Befehl
     ldi   r31, HIGH(2*SOURCE)  ;1
     ldi   r26, LOW(DEST)       ;1   X <- RAM Zieladresse
     ldi   r27, HIGH(DEST)      ;1
.if (COUNT > 256)
  .if ((COUNT & 0x00FF) == 0)   ;    Vielfaches von 256:
     ldi   r17, HIGH(COUNT)     ;1   Startwert Zähler für äussere Schleife
  .else
     ldi   r17, HIGH(COUNT)+1   ;1   Startwert Zähler für äussere Schleife
  .endif
.endif
     ldi   r16, LOW(COUNT)      ;1   Startwert für Zähler innere Schleife
 M2: lpm   r0,Z+                ;3c  r0 <- vbP[v]
     st    X+,r0                ;2c  vbD[v] <- r0
     dec   r16                  ;c
     brne  M2                   ;2c-1
.if (COUNT > 256)
     dec   r17                  ;q
     brne  M2                   ;2q-1
.endif

(Irgendwelche "Tricks" oder "Hacks" sehe ich darin übrigens nicht - 
scheint mir ganz normale Assembler-Programmierung zu sein)

[Dergute W. (derguteweka)]

Moin,

Wenn man schon so am einzelne clk-cycles geizen ist, ist's doch Humbug, 
so allgemeine Funktionen wie: "Kopiere n Bytes von A nach B, n kann auch 
groesser als 256 sein" herzunehmen.
Da macht man doch eher spezielle Funktionen, die eben genau zu dem 
jeweiligen Fall passen. Wenn ich z.B. weiss, dass ich immer z.B. 17 
Bytes kopieren muss und der Programmspeicher nicht knapp ist, wird 
komplettes loop-unrolling das Mittel der Wahl sein. Wenn ich immer 
vielfache von x Bytes kopieren muss, dann halt irgendein teilweises 
unrolling, etc.
Das ist dann halt immer auch eine Frage, welche Kroete man schlucken 
will - Zyklen sparen, egal wie gross der Code wird; bei Pipelining evtl. 
laenger auf das erste Ergebnis warten, dafuer hoeheren Durchsatz/weniger 
Zyklen pro Verarbeitung erreichen...

Gruss
WK

[Thomas E. (picalic)]

Servus,

Dergute W. schrieb:
> Wenn man schon so am einzelne clk-cycles geizen ist, ist's doch Humbug,
> so allgemeine Funktionen wie: "Kopiere n Bytes von A nach B, n kann auch
> groesser als 256 sein" herzunehmen.

so, wie ich das verstanden habe, geht es hier doch nicht um eine 
konkrete Lösung einer speziellen Aufgabe, sondern um ein Beispiel aus 
einem Lehrbuch(?), um Möglichkeiten für "trickreiches" und/oder 
optimiertes Assembler-Programmieren exemplarisch darzustellen. Ich kenne 
das Buch nicht, aber mein Eindruck davon anhand dieses Beispiels ist 
nicht so, daß ich das Buch zum Erlernen von Assembler-Programmierung 
oder Erweiterung vorhandener Programmierkenntnisse empfehlen würde! Die 
demonstrierte "Verbesserung" der als klassisch dargestellten Lösung 
führt u.U. zu Fehlern (ok, vielleicht wurden die Einschränkungen ja im 
Text genannt), ist m.E. nach nicht besonders kreativ und effektiv, und 
die kryptischen Labels und Druckfehler machen es unübersichtlich und 
geben Rätsel auf. Da kann ich auch verstehen, daß Anfänger damit 
Schwierigkeiten haben, die Beispiele nachzuvollziehen.

[Dergute W. (derguteweka)]

Moin,

Thomas E. schrieb:
> Ich kenne
> das Buch nicht, aber mein Eindruck davon anhand dieses Beispiels ist
> nicht so, daß ich das Buch zum Erlernen von Assembler-Programmierung
> oder Erweiterung vorhandener Programmierkenntnisse empfehlen würde!

Dito. Auch wenn das Beispiel vielleicht aus dem Zusammenhang gerissen 
sein koennte - mit den Fehlern drinnen und den eigenartigen Kommentaren 
ist's schon sehr "speziell".

Gruss
WK

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Thomas E. schrieb:
> so, wie ich das verstanden habe, geht es hier doch nicht um eine
> konkrete Lösung einer speziellen Aufgabe, sondern um ein Beispiel aus
> einem Lehrbuch(?), um Möglichkeiten für "trickreiches" und/oder
> optimiertes Assembler-Programmieren exemplarisch darzustellen.
>
Ja, genau so ist es.
Es ist halt eines der wenigen Bücher in deutscher Sprache, die sich mit 
der AVR8-Assemblerprogrammierung tiefgehender befassen. Leider für mich 
zu hoch.
Falls jemand etwas ähnliches in deutscher Sprache kennt ( kann auch ein 
Link sein ) nur her damit ;-).


Bernd_Stein

[c-hater (Gast)]

Thomas E. schrieb:

> so, wie ich das verstanden habe, geht es hier doch nicht um eine
> konkrete Lösung einer speziellen Aufgabe, sondern um ein Beispiel aus
> einem Lehrbuch(?), um Möglichkeiten für "trickreiches" und/oder
> optimiertes Assembler-Programmieren exemplarisch darzustellen. Ich kenne
> das Buch nicht, aber mein Eindruck davon anhand dieses Beispiels ist
> nicht so, daß ich das Buch zum Erlernen von Assembler-Programmierung
> oder Erweiterung vorhandener Programmierkenntnisse empfehlen würde!

Das sehe ich ganz genauso.

Generell würde ich sagen, dass ein Lehrbuch für Assembler-Optimierung 
(das ist etwas ganz anderes als ein Lehrbuch zur 
Assembler-Programmierung!!!) vor allem Grundkonzepte für mögliche 
Optimierungen vermitteln sollte und wie man rausbekommt, welches Konzept 
für ein konkretes Problem für die konkrete Zielarchitektur zu welchem 
Preis umsetzbar ist. Also eine genauere Beleuchtung des ewigen Spagat 
zwischen Codesize und Performance und das unter Berücksichtigung des 
Zielsystems.

Ein Lehrbuch zur Assembler-Programmierung hingegen sollte vor allem 
darauf absetzen, wie man überhaupt erstmal ein Programm schreibt, was 
funktioniert und auch kompliziertere Sachen tun kann, also Sachen in 
Größenordnungen, von denen diese lächerlichen C-only-Typen immer wieder 
behaupten, dass man das in Assembler garnicht mehr sinnvoll umsetzen 
könnte. Darin sollte es also vor allem um binäre Arithmetik gehen.

Die Beherrschung dieses Stoffs wäre dann ein gute Grundlage dafür, sich 
das Buch zur Assembler-Optimierung reinzuziehen. Man hat dann nämlich 
die Kompetenz der Beherschung der Sprache und der Beherrschung der 
Algorithmen. Das ermöglicht erst, die Knackpunkte des Programms zu 
identifizieren, für die eine Optimierung überhaupt lohnend ist...

[Carl D. (jcw2)]

Die lächerlichen C-Typen kennen etwas, was sich "Duff's Device" nennt 
und natürlich in Assembler genauso gut geht, dagegen sehen die 
Single-Takt-Einsparversuche von weiter oben alt aus.

[c-hater (Gast)]

Carl D. schrieb:

> Die lächerlichen C-Typen kennen etwas, was sich "Duff's Device" nennt

Ich behaupte: die überwiegende Mehrzahl der Leute, die hier um Rat 
bettelt und in C "programmiert" (also de facto: C&P+Glue) hat keine 
Ahnung davon. Nichtmal den Hauch einer Andeutung...

[Carl D. (jcw2)]

c-hater schrieb:
> Carl D. schrieb:
>
>> Die lächerlichen C-Typen kennen etwas, was sich "Duff's Device" nennt
>
> Ich behaupte: die überwiegende Mehrzahl der Leute, die hier um Rat
> bettelt und in C "programmiert" (also de facto: C&P+Glue) hat keine
> Ahnung davon. Nichtmal den Hauch einer Andeutung...

Ob der Anteil bei den Tiny13-Assembler-Programmierern größer ist?

[S. R. (svenska)]

Carl D. schrieb:
> Die lächerlichen C-Typen kennen etwas, was sich "Duff's Device" nennt
> und natürlich in Assembler genauso gut geht, dagegen sehen die
> Single-Takt-Einsparversuche von weiter oben alt aus.

Duff's Device ist auf modernen CPUs langsamer als eine naive Lösung.
Die kann der Compiler nämlich sinnvoll optimieren.

[c-hater (Gast)]

Carl D. schrieb:

> Ob der Anteil bei den Tiny13-Assembler-Programmierern größer ist?

Wahrscheinlich nicht, da gebe ich dir Recht. Die Aufgabe eines guten 
Assemblerbuches (bzw. der zwei Bände, die mir da vorschweben) wäre halt, 
genau das zu ändern...

Das Problem ist nur: Menschen sind weit überwiegend stinkendfaul. Nur 
einer von 10000 (ganz grob geschätzt) der überhaupt an 
Assemblerprogrammierung interessierten würde sich diese zwei Wälzer 
überhaupt kaufen.

Und von den drei Leuten, die sich diese Bücher gekauft haben, würde dann 
wahrscheinlich wieder nur einer von 10000 durchhalten bis zum Ende. 
D.h.: der nächste brauchbare Programmierer ist bei jährlicher Neuauflage 
in ungefähr 3000 Jahren zu erwarten. Ja, wenn man sich die Bemühungen 
unserer Personal-Aquise so anschaut, kommt das wohl gut hin. C&P-ler bis 
zum Abwinken, aber weit und breit niemand, der wirklich noch selber was 
programmieren kann...

Dabei brauchen sie dann in der Praxis weit überwiegend ja nichtmal 
wirklich in Assembler programmieren, sondern nur zeigen, dass sie es 
könnten, wenn es nötig wäre und dass sie in der Lage sind, erkennen zu 
können, wann es nötig wäre...

[Dergute W. (derguteweka)]

Moin,

Ich wusste nicht, was ein Duff's Device ist - ich haett's eher als 
Zapfanlage in Moe's Taverne verortet. Aber der "Trick" dahinter war mir 
schon bekannt.
Man muss es wohl als Nische und loesen von Luxusproblemen sehen; es ist 
meistens ziemlich unsinnig, um jeden Takt zu feilschen. Wenn man nicht 
gerade irgendwelchen saubilligen Shice, der in Massenstueckzahlen auf 
den Markt kommt, designt, ist's wohl billiger, eine groessere CPU zu 
nehmen und in der Hochsprache zu bleiben. Und auch bei 
Massenstueckzahlen wirds simpler sein, den Bauteileverchecker 
entsprechend zu bearbeiten, dass der die groessere CPU zum kleineren 
Preis verscherbelt.
Trotzdem mach' ich das natuerlich auch mal ganz gerne, um zu gucken, was 
man noch in einen kleinen Controller quetschen kann. Aber doch eher als 
Hobby. Wird man dafuer bezahlt, ist mir das Risiko zu gross, dass man 
dann den entscheidenden Takt doch nicht mehr einsparen kann, bzw. die 
Entwicklung viel zu lange dauert.

Als Lektuere, was man so machen kann, wuerd' ich auch mal in die 
Beschreibung der verschiedenen Optimierungen, die der gcc kann, gucken. 
Da gibts ja nicht nur -Os, -O[0..n] sondern einzelne Gimmicks.

Gruss
WK

[Rainer V. (a_zip)]

Thomas E. schrieb:
> So könnt's gehen (kurz, schnell und (hoffentlich:-)) richtig):

Hallo, habe mir jetzt diese Zeile nur beispielhaft für viele andere 
Beiträge kopiert.
Auch wenn ich es gern allgemeiner formuliere, ist "Code-Optimierung" in 
den meisten Fällen natürlich Zeit-Optimierung! Und die zitierten...

Bernd S. schrieb:
> Und zwar geht es im Buch von Schwabl-Schmidt

...Beispiele sind für mich absolut schwachsinnig. Sorry...mußte ich 
jetzt mal sagen.
Und ich bekenne, nach Durchsicht der zitierten Code-Beispiele, dass ich 
froh bin, das nicht vor 10 oder 20 Jahren unter die Finger bekommen zu 
haben. Hätte sonst vielleicht gedacht, da was wahnsinnig geniales 
entdeckt zu haben :-))
Ich will inhaltlich hier jetzt nicht weiter rumstreiten. Um 
ASM-Programmieren zu Lernen ist das mit Sicherheit nix, nix und wieder 
nix. Man muß sich schon gute eigene Gedanken machen und man findet 
manchmal auch einen genialen "Trick" in einer Code-Vorlage, in der man 
rumstöbert...das ist es dann auch. Selbst Denken ist gefragt!!!
Gruß Rainer

[Peter D. (peda)]

Carl D. schrieb:
> Die lächerlichen C-Typen kennen etwas, was sich "Duff's Device" nennt
> und natürlich in Assembler genauso gut geht, dagegen sehen die
> Single-Takt-Einsparversuche von weiter oben alt aus.

Aber in C läßt es sich viel leichter hinschreiben und besser verstehen.
Der obige Code spart dagegen nur wenig ein, das ist den Aufwand nicht 
wert.

[Thomas E. (picalic)]

Peter D. schrieb:
> Der obige Code spart dagegen nur wenig ein, das ist den Aufwand nicht
> wert.

Welchen Aufwand meinst Du? Mein Vorschlag hat nur zwei Instructions 
mehr, als die "Standard"-Lösung, bei COUNT<=256 sogar eine Instruction 
weniger.
Aber eigentlich ging es mir auch eher darum, daß einfache Optimierungen 
keine exotischen Hacks sind und man ASM-Programme auch mit korrekter 
Funktion (so, daß man daraus ggf. auch ein wiederverwendbares Macro 
machen könnte) und verständlichen Label-Namen versehen kann, 
insbesondere, wenn es ein Beispiel zur Demonstration sein soll.

[Peter D. (peda)]

Thomas E. schrieb:
> Welchen Aufwand meinst Du?

Beitrag "Re: Assembler Schleifen Tricks"

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

c-hater schrieb:
> Die Aufgabe eines guten
> Assemblerbuches (bzw. der zwei Bände, die mir da vorschweben) wäre halt,
> genau das zu ändern...
>
Hört sich an, als ob es die erwähnten zwei Bände noch nicht gibt.
Kannst du denn deutschsprachige Bücher nennen, die empfehlenswert wären 
?
Wolfgang Trampert und Günter Schmitt habe ich schon.


Bernd_Stein

[Thomas E. (picalic)]

Dergute W. schrieb:
> Man muss es wohl als Nische und loesen von Luxusproblemen sehen; es ist
> meistens ziemlich unsinnig, um jeden Takt zu feilschen. Wenn man nicht
> gerade irgendwelchen saubilligen Shice, der in Massenstueckzahlen auf
> den Markt kommt, designt, ist's wohl billiger, eine groessere CPU zu
> nehmen und in der Hochsprache zu bleiben.

Das hört sich bei Dir so an, als würde es generell nicht viel Sinn 
machen, sich um Codeoptimierungen Gedanken zu machen. Der Punkt ist auch 
nicht, durch einzelne Zyklenklauberei im ganzen Code verstreut durch 
viel Aufwand den nächst billigeren Controller verwenden zu können, 
sondern mit gesundem Menschenverstand an die Sache heran zu gehen und 
ggf. da zu optimieren, wo sich der Einsatz von etwas Gehirnschmalz zur 
Erhöhung der Gesamtperformance tatsächlich lohnt. Im Allgemeinen sind 
das Programmteile, die sehr häufig durchlaufen werden oder eine 
kritische Reaktionszeit haben. Mit der Holzhammer-Methode, z.B. einfach 
die Taktfrequenz erhöhen, wenn am Ende die Gesamt-Performance oder 
irgend eine Latenz doch nicht ausreicht, handelt man sich auch 
unerwünschte Nebenwirkungen wie eine erhöhte Stromaufnahme ein.
Das gilt natürlich ganz allgemein und hat nichts mit Assembler vs. 
Hochsprache zu tun. So habe ich z.B. neulich erst eine alte 
CRC-Berechnungsfunktion in C durch einfaches Loop-Unrolling deutlich 
schneller machen können. Das würde sich sicher nicht lohnen, wenn die 
Funktion bloß einmal aufgerufen würde, aber da nun mal für jedes Byte 
der Datenübertragung auch diese Funktion einmal aufgerufen wird, lohnt 
sich das.

[Carl D. (jcw2)]

Peter D. schrieb:
> Carl D. schrieb:
>> Die lächerlichen C-Typen kennen etwas, was sich "Duff's Device" nennt
>> und natürlich in Assembler genauso gut geht, dagegen sehen die
>> Single-Takt-Einsparversuche von weiter oben alt aus.
>
> Aber in C läßt es sich viel leichter hinschreiben und besser verstehen.
> Der obige Code spart dagegen nur wenig ein, das ist den Aufwand nicht
> wert.

OK, ich war zu sparsam und hab die Gänsefüßchen um das Zitat meines 
direkten Vorposters weggelassen.
Seit es finanziell schmerzfreie C-Compiler für μC gibt, hab ich wenige 
Zeilen Assembler geschrieben. Ich bin also eher das Komplement des 
Sprachenhassers.

[Peter D. (peda)]

Thomas E. schrieb:
> Mit der Holzhammer-Methode, z.B. einfach
> die Taktfrequenz erhöhen

Der Holzhammer hat noch nie wirklich geholfen.
Die beste Optimierung ergibt sich bei der Projektplanung und sinnvollen 
Zerlegung der Aufgabe in einzelne Module und Tasks. Also lange bevor man 
mit dem eigentlichen Coden beginnt.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Hört sich an, als ob es die erwähnten zwei Bände noch nicht gibt.
> Kannst du denn deutschsprachige Bücher nennen, die empfehlenswert wären
> ?
> Wolfgang Trampert und Günter Schmitt habe ich schon.
>
@c-hater
Ok, keine Antwort bedeutet für mich meine Vermutung ist richtig.

Themawechsel

Kann mir jemand schreiben, ob ich in diesem Thread nach einen 
Programmablaufplan ( PAP ) gefragt hatte ?

Es wurde so viel gelöscht. Eigentlich hätte ich eine Benachrichtigung 
bekommen müssen, falls ein Posting von mir dabei gewesen wäre, aber ich 
finde einfach den Thread nicht, wo über die PAP-Software " diskutiert " 
wurde.


Bernd_Stein

[Thomas E. (picalic)]

Bernd S. schrieb:
> Kann mir jemand schreiben, ob ich in diesem Thread nach einen
> Programmablaufplan ( PAP ) gefragt hatte ?

Hat Dein Browser keine Suchfunktion? Wenn ich im Firefox Strg-F drücke 
und dann "pap" eintippe, ggf. ein paar mal F3, stosse ich auf diesen 
Beitrag:
Beitrag "Re: Assembler Schleifen Tricks"

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Thomas E. schrieb:
> Hat Dein Browser keine Suchfunktion? Wenn ich im Firefox Strg-F drücke
> und dann "pap" eintippe, ggf. ein paar mal F3, stosse ich auf diesen
> Beitrag:
> Beitrag "Re: Assembler Schleifen Tricks"
>
Danke.

Oh, Mann ist das peinlich. Bitte die 3Postings löschen.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Wenn du eine Software zum Erstellen von Diagrammen suchst, kann ich Dir
> "yEd" empfehlen.
>
@Stefanus F. & alle Anderen die sich mit yEd-Flowchart bzw. dem 
PAP-Programm auskennen.

Ich arbeite im Browser-Modus. Wie kann ich alles einfach schön in eine 
Reihe kriegen und gleichmäßige Abstände zwischen den " Symbolen " 
hinbekommen ?

Bernd_Stein

[Stefan F. (Gast)]

Ich weiss nicht, was der Browser Modus ist.

Ich habe bisher immer jedes Kästchen einzeln ausgerichtet. Die Rasterung 
und Hilfslinien helfen dabei.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Ich weiss nicht, was der Browser Modus ist.
>
> Ich habe bisher immer jedes Kästchen einzeln ausgerichtet. Die Rasterung
> und Hilfslinien helfen dabei.
>
Im Browser-Modus muss man das Programm nicht downloaden, sondern man 
arbeitet damit in einem Browsertab.

Ist ja blöd, fast jedes Grafikprogramm kann so etwas ( Einrahmen & 
ausrichten ).

Tja, dann muss ich wohl mehr Zeit investieren, wenn ich es noch "schön" 
haben will.

Bernd_Stein

[Stefan F. (Gast)]

Menü: Bearbeiten/Knoten ausrichten

Ich habe gerade mal den Browser Modus ausprobiert. Gefällt mir nicht, 
das installierte Programm ist viel besser zu handhaben.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Menü: Bearbeiten/Knoten ausrichten
>
> Ich habe gerade mal den Browser Modus ausprobiert. Gefällt mir nicht,
> das installierte Programm ist viel besser zu handhaben.
>
Mir auch nicht, denn das Menü schein ich nicht zu haben.
Langsam geht es mir auf den Keks, ist doch relativ mühselig.

Kann man beim installierten Programm die Pfeilbezeichner drehen?
Ich will sie waagerecht und nicht senkrecht.

Bernd_Stein

[Stefan F. (Gast)]

> Kann man beim installierten Programm die Pfeilbezeichner drehen?

Selbstverständlich. Wenn du die nur Browser Version gesehen hast, hast 
du yEd noch nicht kennengelernt.

[Markus F. (mfro)]

wie wär's damit?

digraph G {
    graph [nodesep=0.1];
    MCURESTART -> init;
    init [label="Stackpointer initialisieren &\n globale Interruptfreigabe"; shape=box];
    init -> Init_TWI;
    Init_TWI [shape=record; label=" |Init_TWI| "];
    Read_Temp2 [shape=record; label=" |Read_Temp2| "];
    Init_TWI -> Read_Temp2
    TWI_Ready [shape=diamond; label="TWI_Ready?"];
    Read_Temp2 -> TWI_Ready;
    Get_TWI_Temp [shape=record; label=" |Get_TWI_Temp| "];
    TWI_Ready -> Get_TWI_Temp;
    Get_TWI_Temp -> TWI_error [portPos=n];
    TWI_error [label="TWI_error?"; shape=diamond];
    TWI_error -> Process_TWI_Error;
    Process_TWI_Error [shape=record; label=" |Process_TWI_Error| "];
    Process_TWI_Error -> main_loop;
    main_loop -> TWI_error [portPos=e];
}

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Markus F. schrieb:
> wie wär's damit?
>
Wie meinst du das?
Soll ich etwa alles eintippen - wohl kaum. Naja, so was gebogenes, nur 
wenn es nicht anders geht.
Arbeitest du auch mit yED oder was ist das wieder für ein Programm?
Will mich nicht wieder irgendwo einarbeiten und meine Festplatte hat 
nicht mehr so viel Platz um sämtliche Software herunter zu laden. Habe 
nur noch 5GB frei und ich habe gelesen, das man da irgendein JAVA-Zeug 
braucht, was meine freie Kapazität evtl. sprengt.

Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Soll ich etwa alles eintippen - wohl kaum.

Ich kenne ein ähnliches Online-Tool mit einem etwas anderen Textformat 
(https://www.websequencediagrams.com/). Ob du es glaubst, oder nicht: 
Dieses Tippen geht oft schneller, als mit der Maus zu hantieren.

Bei www.websequencediagrams.com kommt man allerdings recht schnell an 
Grenzen wo man seine Ansprüche an das Programm anpassen muss.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Dieses Tippen geht oft schneller, als mit der Maus zu hantieren.
>
Du weißt - am liebsten hätte ich dieses Programm :

https://www.youtube.com/watch?v=024f0NX2FLs&list=PLRuRKN7_FVgvhdj6JmelCihl6jmKHc_Xt&index=4


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Du weißt - am liebsten hätte ich dieses Programm :
>
Beim gucken seiner Video's gabs ein Moment, wo ich sehen konnte was er 
benutzt. Es ist *Smooth Draw.*

http://www.smoothdraw.com/sd


Bernd_Stein

[Markus F. (mfro)]

Bernd S. schrieb:
> Markus F. schrieb:
>> wie wär's damit?
>>
> Wie meinst du das?
> Soll ich etwa alles eintippen - wohl kaum. Naja, so was gebogenes, nur
> wenn es nicht anders geht.
> Arbeitest du auch mit yED oder was ist das wieder für ein Programm?

das ist dot aus dem GraphViz Paket (https://www.graphviz.org/).
Wer einigermassen flott tippen kann, hat das deutlich schneller getippt 
als mit der Maus hingezupft (mich hat's ungefähr fünf Minuten gekostet, 
aus deinem Bild den dot-Code zu schreiben). Die Pfeile gibt's auch in 
"eckig", bin jetzt nur auf die Schnelle nicht drauf gekommen, wie.

[Markus F. (mfro)]

jetzt hab' ich's auch eckig hingekriegt.

[S. R. (svenska)]

Markus F. schrieb:
> jetzt hab' ich's auch eckig hingekriegt.

Und wie? Nur der Neugierde halber...

[Markus F. (mfro)]

S. R. schrieb:
> Markus F. schrieb:
>> jetzt hab' ich's auch eckig hingekriegt.
>
> Und wie? Nur der Neugierde halber...

digraph G {
        graph [nodesep=0, splines=ortho];
        MCURESTART -> init;
        init [label="Stackpointer initialisieren &\n globale Interruptfreigabe"; shape=box];
        init -> Init_TWI;
        Init_TWI [shape=record; label=" |Init_TWI| "];
        Read_Temp2 [shape=record; label=" |Read_Temp2| "];
        Init_TWI -> Read_Temp2
        TWI_Ready [shape=diamond; label="TWI_Ready?"];
        Read_Temp2:s -> TWI_Ready:n;
        Get_TWI_Temp [shape=record; label=" |Get_TWI_Temp| "];
        TWI_Ready -> Get_TWI_Temp;
        Get_TWI_Temp -> TWI_error [portPos=n];
        TWI_error [label="TWI_error?"; shape=diamond];
        TWI_error:s -> Process_TWI_Error;
        Process_TWI_Error [shape=record; label=" |Process_TWI_Error| "];
        Process_TWI_Error -> main_loop;
        main_loop -> TWI_error:e
}

[S. R. (svenska)]

Danke!

[Rainer V. (a_zip)]

Hallo, Freue mich zu sehen, dass die Tricks, also die Assembler-Tricks, 
doch über das Beschreiben eines Registers hinaus gekommen sind :-)
Gruß Rainer

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Jetzt wo ich mich entschieden habe den yEd Graph Editor zu 
installieren und evtl. dafür Platz auf meiner FP zu schaffen, sehe ich 
das es nur für Win64-Bit zu gebrauchen ist :-(

Hab was besseres gefunden. Braucht nicht viel FP-Platz und flupt.

PapDesigner

https://www.youtube.com/watch?v=ApgIq_2e5Xc

http://friedrich-folkmann.de/papdesigner/Download.html


Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> das es nur für Win64-Bit zu gebrauchen ist :-(

Du bist echt voreilig. yEd ist ein Java Programm und läuft daher auch 
unter Windows 32bit.

https://www.yworks.com/downloads#yEd (Klappe den Absatz "yEd Graph 
Editor" auf, um alle Versionen zu sehen). Es ist der unterste Eintrag 
"Zipped yEd Jar file for 32-bit and 64-bit operating systems".

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Du bist echt voreilig. yEd ist ein Java Programm und läuft daher auch
> unter Windows 32bit.
>
Da sind die selber Schuld, wenn die das so unübersichtlich gestalten.
Das Programm PapDesigner ist mir eh lieber.


Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Das Programm PapDesigner ist mir eh lieber.

Aber du hast Dir yEd doch noch gar nicht angeschaut. Wie kannst du dann 
den PapDesigner besser finden?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Aber du hast Dir yEd doch noch gar nicht angeschaut. Wie kannst du dann
> den PapDesigner besser finden?
>
Ich hab zwar nur Online damit gearbeitet, aber das reichte mir schon, um 
die Schnauze voll davon zu haben. In dem einen Screen-Shot ist ein 
organges Feld, das ich irgendwie dort hinbekommen habe, aber nicht mehr 
weg.

Beitrag "Re: Assembler Schleifen Tricks"

PapDesigner flupt. Es macht was ich brauch und ist sehr einfach zu 
bedienen.


Bernd_Stein

[Stefan F. (Gast)]

Wie gesagt, das Online Tool ist Kacke. Das installierbare Programm sieht 
ganz anders aus. Aber wenn du mit PapDesigner zufrieden bist ist ja auch 
Ok.