AVR Assembler: add adc auf 0 prüfen

Wäre Subtraktion auch ok? Da stimmt das Z-Flag hinterher nämlich.

Je nach Registerpaar geht
   adiw rh:rl,0
   breq ...

Stefanus F. schrieb:
> Da es sich hier um eine 8 Bit CPU handelt, musst du beide Register
> einzeln auf Null testen.

Nö. t=rh|rl.

Hi, @AVR
über das Statusregister "Speicher"-Bit und den entsprechenden 
Sprungbefehl müsste es gehen bei 8 Bit:
clr r21
clr r22
....
adc  r22, r21    ; Eins-Bit addieren
bst  r22, 0    ; war das Ergebnis geradzahlig?
brtc  marke    ; ja -> weiter
inc  r19      ; sonst Fehlerzaehler erhöhen

ciao
gustav

AVR schrieb im Beitrag #5557494:
> Und die Frage war so gemeint, dass ich mir die 3 Takte gern sparen
> würde, wenn es nur eine Frage der Unwissenheit ist. Intuitiv schreibt
> man nämlich sofort
>
> add
> adc
> brmi
> breq
>
> Und das geht eben nicht.

 Vielleicht so ?

1

        add  r16,r20

2

        adc  r17,r21

3

        tst   r16

4

        brne weiter

5

        tst  r17

6

        breq fehler

7

weiter:

Gähn. Von der Sorte gibt's noch viel mehr.

Mogelpackung ist ohnehin ein starkes Wort. Mehrere Mnemonics für den 
gleichen Opcode illustrieren die Verwendung des Befehls.

Stefanus F. schrieb:
> A. K. schrieb:
>> Mehrere Mnemonics für den
>> gleichen Opcode illustrieren die Verwendung des Befehls.
>
> Ja das mach Sinn. Weniger sinnvoll kommt es mit vor, in Marketing
> Broschüren damit zu werben, dass die CPU soundso viele Befehle hat, wenn
> diese Duplikate dabei mitgezählt werden.

Der jetzige AVR-Eigner hat auch schon mit "nur so wenige" geworben, um 
den RISC-Character seiner (alten) PICs hervorzuheben.

AVR schrieb im Beitrag #5557364:
> add r16,r20
> adc r17,r21
> breq fehler ;geht nicht!

Warum nicht ?

du brauchst doch nur nach der Addition es wie folgt zu ergänzen

add r16,r20
adc r17,r21
add r16,r17
tst r16
breq fehler

Chris H. schrieb:
> du brauchst doch nur nach der Addition es wie folgt zu ergänzen
>
> add r16,r20
> adc r17,r21
> add r16,r17
> tst r16
> breq fehler

 Genial.
 Der Inhalt von r16 ist zwar geändert, aber das macht nichts.
 Oder doch ?

A. K. schrieb:
> Mogelpackung ist ohnehin ein starkes Wort. Mehrere Mnemonics für den
> gleichen Opcode illustrieren die Verwendung des Befehls.

Kann aber auch Fehler provozieren! Wer (außer eingefleischten 
AVR-Kennern) würde denn z.B. erwarten, daß ein Bit-Set oder -Clear 
Befehl das Z-Flag verändert?
Wenn man keinen expliziten Befehl dafür hat, weiß man wenigstens, daß 
man es mit einer OR- bzw. AND-Operation machen muss und da rechnet man 
logischerweise auch damit, daß das Statusregister beeinflusst wird. 
Sonst geht man davon aus, daß ein expliziter Bit-Set bzw. Clear-Befehl 
nur das Setzen oder Löschen von Bits bewirkt und eben nicht nur ein 
anderer Name für einen "echten" AND oder OR-Befehl ist.

nenene schrieb:
> Übrigends git es SBR
> und BSET. Solltest mal genau schreiben, was du meinst.

Ich meine natürlich SBR und CBR. Der Sinn von BSET und BCLR als extra 
Mnemonic erschließt sich mir auch nicht. Z.B. ein "CLC" ist doch viel 
prägnanter, als der entsprechende Befehl mit BCLR. Wenn man den 
Befehlssatz nicht gut kennt und auf der Suche nach einer Möglichkeit 
ist, ohne Nebeneffekte ein Bit in einem Core-Register zu setzen, findet 
man verschiedene Mnemonics, die zunächst so aussehen, als ob sie dafür 
geeignet seien. Bei genauerer Betrachtung der Befehle stellt man dann 
aber fest, daß das bloß Pseudo-Befehle für andere Grundbefehle sind und 
es einen Befehl für das, was man eigentlich haben möchte, gar nicht 
gibt. Wenn es keine BSET/BCLR/SBR/CBR Mnemonics gäbe, hätte man 
schneller einen Überblick, was der Prozessor kann und was nicht und 
müsste sich gar nicht erst näher mit den überflüssigen Mnemonics 
auseinandersetzen.

Thomas E. schrieb:
> Wer (außer eingefleischten AVR-Kennern) würde denn z.B. erwarten,
> daß ein Bit-Set oder -Clear Befehl das Z-Flag verändert?

Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte 
Bit in einem Register gelöscht habe. Das ist relevant.

A. K. schrieb:
> Wäre Subtraktion auch ok? Da stimmt das Z-Flag hinterher nämlich.

Ja, da haben die AVR-Entwickler zu kurz gedacht. Es gibt keinen Grund, 
das Z-Flag bei der Addition nicht richtig zu berechnen.

S. R. schrieb:
> Thomas E. schrieb:
>> Wer (außer eingefleischten AVR-Kennern) würde denn z.B. erwarten,
>> daß ein Bit-Set oder -Clear Befehl das Z-Flag verändert?
>
> Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
> Bit in einem Register gelöscht habe. Das ist relevant.

 Ich nicht.
 Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.

Stefanus F. schrieb:
> S. R. schrieb:
>> Ich. Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte
>> Bit in einem Register gelöscht habe. Das ist relevant.
>
> Ich dachte, es sagt aus, dass die letzte Operation 0 ergeben hat.

 Sagt S.R. doch auch.
 Wenn ich z.B. Aktoren nacheinander ausschalte, sind bei gesetztem
 Zero-Flag alle Aktoren aus, da brauche ich kein TST oder so etwas.

Marc V. schrieb:
>  Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.

Indem du in einem Register mit Inhalt 0 auch nur 0 Bits setzt.

SBR ist identisch mit ORI, mit Maske als Operand. Der einzig wirklich 
sinnvolle Einsatz von SBR wäre mit Bitnummer statt Maske gewesen, 
umgerechnet vom Assembler. Verwendung analog zu SBI. Aber so ist es eine 
böse Falle.

A. K. schrieb:
> Marc V. schrieb:
>>  Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.
>
> Indem du in einem Register mit Inhalt 0 auch nur 0 Bits setzt.

 Und der Sinn dieser Handlung wäre welches ?

> SBR ist identisch mit ORI, mit Maske als Operand. Der einzig wirklich
> sinnvolle Einsatz von SBR wäre mit Bitnummer statt Maske gewesen. Analog
> zu SBI. Aber so ist es eine böse Falle.

 Deswegen sind alle Pins und noch etliche andere Sachen als Maske
 in *.inc definiert.

 Aber eine böse Falle ist es und ausserdem ziemlich unlogisch - wer
 weiss auf Anhieb welche bits mit:

1

 SBR r16, 0xAD

 gesetzt sind ?

Marc V. schrieb:
>>> Wie ein SBR Befehl Z-Flag setzen kann, ist mir schleierhaft.
>>
>> Indem du in einem Register mit Inhalt 0 auch nur 0 Bits setzt.
>
> Und der Sinn dieser Handlung wäre welches ?

Keines. Aber du hattest nicht nach dem Sinn gefragt,
sondern wie es geht. ;-)

A. K. schrieb:
>> Und der Sinn dieser Handlung wäre welches ?
>
> Keines. Aber du hattest nicht nach dem Sinn gefragt,
> sondern wie es geht. ;-)

 Tja, da hast du auch wieder Recht...

Stefanus F. schrieb:
> Nö. "dass ich gerade das letzte gesetzte Bit in einem Register gelöscht
> habe" ist was anderes, als "das alle Bits gelöscht sind".
>
> "dass ich gerade das letzte gesetzte Bit in einem Register gelöscht
> habe" bedeutet, dass irgend ein Bit vorher 1 war. Nur dann kann man
> sagen, dass das letzte Bit gerade gelöscht wurde.
>
> "das alle Bits gelöscht sind" würde auch zutreffen, wenn alle Bits schon
> immer gelöscht waren.

 Und wie willst du dann irgendein bit löschen ?

 Du kannst zwar unendlich lange keinen bit in einem Register mit
 Wert Null löschen, aber der Sinn ist, dass du nach dem letzten bit
 damit aufhörst, zumindest normale Programmierer machen das so.

Stefanus F. schrieb:
> Marc V. schrieb:
>>  Und wie willst du dann irgendein bit löschen ?
>
> Mit irgendeiner Operation, zum Beispiel AND.

 Aha.

Stefanus F. schrieb:
> "das alle Bits gelöscht sind" würde auch zutreffen, wenn alle Bits schon
> immer gelöscht waren.

 Was willst du löschen wenn alle Bits schon immer gelöscht waren ?

Stefanus F. schrieb:
> Nö. "dass ich gerade das letzte gesetzte Bit in einem Register gelöscht
> habe" ist was anderes, als "das alle Bits gelöscht sind".

Wenn
- ich einen Befehl habe, der ein Bit löscht
- und dieser Befehl das Z-Flag beeinflusst
- und ich davon ausgehe, dass ich ein gesetztes Bit lösche
dann
- sagt mir das Z-Flag, dass ich das letzte gesetzte Bit gelöscht habe.

Ich kann natürlich auch ein nicht gesetztes Bit löschen, und du darfst 
mich auch gerne missverstehen. :-(

So ein Verhalten kann für Statusregister relevant sein, wenn z.B. ein 
Ereignis verarbeitet wurde, das nächste Ereignis aber schon ansteht und 
daher das Bit von außerhalb wieder gesetzt wurde.

Demgegenüber erwarte ich nicht, dass z.B. ein MOV am Z-Flag spielt - 
unabhängig davon, ob das Quellregister null war oder nicht.

Aber spaltet nur eure Haare.
Die richtige Bibel nennt sich "Dokumentation".

c-hater schrieb:
> Außerdem ist sie sachlich falsch, denn bei allen Subtraktions- und
> Vergleichsoperationen mit Übertrag ist es beim AVR8 (und auch anderen
> Architekturen) eben NICHT so.

Ich bezog mich auf "Bit Clear"-Befehle, nicht auf allgemeine 
ALU-Befehle. Ob das BITCLR nun als AND implementiert ist oder nicht, ist 
mir ebenfalls egal.

S. R. schrieb:
> Demgegenüber erwarte ich nicht, dass z.B. ein MOV am Z-Flag spielt -
> unabhängig davon, ob das Quellregister null war oder nicht.

Es gibt allerdings reichlich viele Prozessoren, die es deinen Erwarten 
zuwider trotzdem so halten. ;-)

Stefanus F. schrieb:
> Wenn es nichts zu löschen gab, und ich dann frage "hast du gerade ein
> Bit gelöscht?", dann lautet die richtige Antwort: "Nein" (die waren
> schon alle gelöscht)
>
> Wenn ich hingegen frage: "Sind jetzt alle Bits gelöscht?", dann lautet
> die richtige Antwort: "Ja" (ist schon länger der Fall).

Bei Einzelbitbefehlen einiger Architekturen bezieht sich das Z-Flag 
nicht auf das ganze Register vorher oder nachher, sondern auf den 
vorherigen Status des betreffenden Bits. Etwa BCLR auf 68000.

Erwartungshaltungen bei Maschinenbefehlen sind problematisch. Das 
Handbuch ist hilfreicher. Auch beim C-Flag nach einer Subtraktion ist 
das mit Erwartungshaltungen so eine Sache, und manche Flags setzen 
voraus, dass der Vergleichsbefehl zwischen mit und ohne Vorzeichen 
unterscheidet, nicht der Sprungbefehl.

Peter D. schrieb:
> A. K. schrieb:
>> Wäre Subtraktion auch ok? Da stimmt das Z-Flag hinterher nämlich.
>
> Ja, da haben die AVR-Entwickler zu kurz gedacht. Es gibt keinen Grund,
> das Z-Flag bei der Addition nicht richtig zu berechnen.

Was ist denn daran nicht richtig? Laut Doku des AVR instruction set:
https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_ADD.html 
und
https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_ADC.html 
wird das Z-Flag … "Set if the result is $00; cleared otherwise."
Das wäre genau das, was ich erwarten würde und entspricht dem Verhalten 
bei Subtraktion.

c-hater schrieb:
> Blöderweise war allerdings genau dies Thema dieses Threads: die
> Inkonsistenz bezüglich der Flag-Behandlung zwischen Addition und
> Subtraktion im Befehlssatz der AVR8...

Wobei die älteste CPU, bei der ich dieser sinnvollen Fortschreibung des 
Z-Flags begegnete, es wieder anders hält. Bei Zilogs Z8 findet sie nur 
bei CPC statt, nicht aber bei SBC.

Stefanus F. schrieb:
>> wird das Z-Flag … "Set if the result is $00; cleared otherwise."
>> Das wäre genau das, was ich erwarten würde und entspricht dem Verhalten
>> bei Subtraktion.
>
> So erwarte ich das auch, denn so verhält sich das Z-Flag bei allen
> Befehlen im AVR, wo es eine Funktion hat.

Schau mal bei SBC(I) und CPC nach: "Previous value remains unchanged 
when the result is zero; cleared otherwise."

Stefanus F. schrieb:
>> Schau mal bei SBC(I) und CPC nach: "Previous value remains unchanged
>> when the result is zero; cleared otherwise."
>
> Ich hab's befürchtet, Ausnahmen gibt es immer irgendwo.

Es geht auch noch schöner. In der Reihenfolge der Schreibweise der 
Operanden gibt es 2 Traditionen:
von rechts nach links
    add dst, src  - zB Atmel, Intel
und von links nach rechts
    add src, dst  - zB DEC, 68000, GNU x86

Die zweite Version ist bei Subtraktion und Vergleich 
gewöhnungsbedürftig, weil dann bei einer Subtraktion
    sub A, B
die Flags verdreht sind, d.h. sie zeigen "grösser" an, wenn B grösser 
ist als A. Weil DEC allerdings annahm, dass die Programmierer davon 
etwas verwirrt sein könnten, verwirrte man sie noch mehr, indem der 
PDP-11 Assembler das bei der hinsichtlich Flags wesensgleichen 
Vergleichsoperation nochmal rumdreht und deshalb
    CMP B, A
    SUB A, B
die gleichen Flags hinterlassen.

--

In Assembler sollte man sich also seine Erwartungshaltung dort
hin stecken, so die Sonne nicht scheint, und das Handbuch lesen.
Gründlich.

Dr. Sommer schrieb:
> Überseh ich was, oder geht nicht auch einfach:

Wenn du das Ergebnis der Addition nicht benötigst...

A. K. schrieb:
> Schau mal bei SBC(I) und CPC nach: "Previous value remains unchanged
> when the result is zero; cleared otherwise."

Das kann man für die Addition ausnutzen:

1

        add  r16,r20

2

        adc  r17,r21      ; r17 == 0: Z = 1

3

        cpc  r16, r17     ; r16 == r17: Z bleibt 1

4

        brne nicht_null

Stefanus F. schrieb:
> Ist euch schon aufgefallen, dass der TST Befehl eine Mogelpackung ist?
> Sein Opcode ist mit AND identisch.

Hallo AVR-Spezialisten!

Als eingefleischter MSP430-Fan und Z8-Old-Man dachte ich hier könnte ich 
über die besten Prozessoren der Welt lernen, wenn ich nur lesen würde. 
Aber über eines bin ich gestolpert. Hier wollen OP-Codes gleich sein? 
Das kann ich gar nicht glauben und habe im benannten Manual nachgesehen:

1

126. TST – Test for Zero or Minus

2

126.1. Description

3

Tests if a register is zero or negative. Performs a logical AND between a register and itself. The registerwill remain unchanged.

Da steht doch "the register will remain UNCHANGED" - die Register, die 
zur Operation verwendet werden. Demnach sind doch AND und TEST 
unterschiedlich.

Dann habe ich mir die "Aufgabenstellung" des TO angesehen und finde es 
sollte doch mit

1

Example:

2

 ; Add R1:R0 to R3:R2

3

add r2,r0 ; Add low byte

4

adc r3,r1 ; Add with carry high byte

 und

1

Example:

2

cpi r20,5 ; Compare r20 to the value 5

3

brbc 1,noteq ; Branch if Zero Flag cleared

4

...

5

noteq: nop ; Branch destination (do nothing)

 funktionieren - oder? Das wären drei Zeilen Assembler.

... oder, wo denke ich da falsch?

Gruß an die Experten

Bernd

Bernd B. schrieb:
> 126. TST – Test for Zero or Minus
> 126.1. Description
> Tests if a register is zero or negative. Performs a logical AND between
> a register and itself. The register will remain unchanged.
>
> Da steht doch "the register will remain UNCHANGED" - die Register, die
> zur Operation verwendet werden. Demnach sind doch AND und TEST
> unterschiedlich.

Was ist denn das Ergebnis von "a logical AND between a register and 
itself"?
Es gibt noch andere Opcodes, die dupliziert sind, z.B. ist CLR rX 
(clear) das selbe wie EOR rX, rX. Und es gibt keinen eigenen Befehl für 
einen links-Shift. Aus LSL rX wird ADD rX, rX.

> Dann habe ich mir die "Aufgabenstellung" des TO angesehen und finde es
> sollte doch mit
> Example:
>  ; Add R1:R0 to R3:R2
> add r2,r0 ; Add low byte
> adc r3,r1 ; Add with carry high byte
> und
> Example:
> cpi r20,5 ; Compare r20 to the value 5
> brbc 1,noteq ; Branch if Zero Flag cleared
> ...
> noteq: nop ; Branch destination (do nothing)
>  funktionieren - oder? Das wären drei Zeilen Assembler.

Und was haben die mit der Frage zu tun? Du machst hier eine Addition 
zweier Registerpaare und danach vollkommen unabhängig davon den 
Vergleich eines anderen Registers mit dem Wert 5. Was aber gefragt war, 
ist, wie man testet, ob das Ergebnis der Addition 0 ist.

Rolf M. schrieb:
> Es gibt noch andere Opcodes, die dupliziert sind, z.B. ist CLR rX
> (clear) das selbe wie EOR rX, rX. Und es gibt keinen eigenen Befehl für
> einen links-Shift. Aus LSL rX wird ADD rX, rX.

Bei vielen Befehlen ist es ja auch sinnvoll, weil es die Funktion der 
Befehle ggf. tatsächlich besser beschreibt und redundante Angaben von 
Operanden im Quelltext vermeidet.
Bei Bit Set und -Clear als Umbenennung von ANDI bzw. ORI halte ich es 
eher für Marketing, um mehr Befehle vorzugaukeln. Es bläht hier nur die 
Doku auf und hat keinen positiven Nutzen.

Rolf M. schrieb:
> Und was haben die mit der Frage zu tun? Du machst hier eine Addition
> zweier Registerpaare und danach vollkommen unabhängig davon den
> Vergleich eines anderen Registers mit dem Wert 5. Was aber gefragt war,
> ist, wie man testet, ob das Ergebnis der Addition 0 ist.

---> Einen zitierten Text verändere ich nicht! Eigentlich sollte jeder 
in der Lage sein, sich auf das Wesentliche zu konzentrieren und 
Unnötiges im Geiste auszublenden. Alles andere mündet schnell in 
Aggressionen...

Gruß

Bernd

Bernd B. schrieb:
> ---> Einen zitierten Text verändere ich nicht!

Was für einen zitierten Text? Du hast …

> die "Aufgabenstellung" des TO

… nirgendes zitiert, sondern dich nur darauf bezogen. Hier ist sie 
nochmal:

AVR schrieb im Beitrag #5557364:
> ich möchte einen 16 Bit Registerpaar zu einem anderen 16 Bit
> Registerpaar addieren und danach prüfen, ob das Ergebnis 0 ist.

Was dein Vergleich eines davon unabhängigen Registers mit dem Wert 5 
damit zu tun haben soll, bleibt schleierhaft.

> Eigentlich sollte jeder in der Lage sein, sich auf das Wesentliche zu
> konzentrieren und Unnötiges im Geiste auszublenden.

Es ist mir ein Rätsel, was du damit meinst. Wolltest du dich damit dafür 
entschuldigen, dass du das hier versäumt hast?

Peter D. schrieb:
> Das kann man für die Addition ausnutzen:

Nope.

r17:r16 = 0xFFFF
r21:r20 = 0x0001

>         add  r16,r20

0xFF + 0x01 => 0x00, C=1

>         adc  r17,r21

0xFF + 0x00 + 1 => 0x00, C=1

>         cpc  r16,r17

0x00 - 0x00 - 1 => Z=0 obwohl r17:r16 = 0

A. K. schrieb:
> Nope.

Eine Lösung mit anderen Registern:

1

        add  r24, r20

2

        adc  r25, r21

3

        adiw r24, 0

4

        brne nicht_null

Rolf M. schrieb:
> Was für einen zitierten Text? Du hast …

Hallo Rolf,

hier noch einmal ein Hinweis zu meinem Kommentar oder Beitrag:

Bernd B. schrieb:
> und habe im benannten Manual nachgesehen

gemeint war dieses hier:

Stefanus F. schrieb:
> Da es hier in diesem Thread um AVR geht sollte für alle Beteiligten klar
> sein, welches Handbuch maßgeblich ist.
> 
http://ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf

Gut, die von mir benannten Textstellen mögen schwer aufzufinden sein:

Bernd B. schrieb:
> 126. TST – Test for Zero or Minus
> 126.1. Description
> Tests if a register is zero or negative. Performs a logical AND between
> a register and itself. The registerwill remain unchanged.

findet sich auf Seite 186.

Bernd B. schrieb:
> Example:
>  ; Add R1:R0 to R3:R2
> add r2,r0 ; Add low byte
> adc r3,r1 ; Add with carry high byte

findet sich auf Seite 30.

Bernd B. schrieb:
> Example:
> cpi r20,5 ; Compare r20 to the value 5
> brbc 1,noteq ; Branch if Zero Flag cleared
> ...
> noteq: nop ; Branch destination (do nothing)

findet sich auf Seite 40.

Wie beschrieben, alles aus dem oben benannten Dokument zitiert.

Lieber Rolf, ich mag mich nicht dafür entschuldigen, dass die Autoren 
des oben benannten Dokuments zum Zeitpunkt des Erstellens noch nichts 
über die Fragestellung des TO wussten und somit vielleicht unpassende 
Register benannt und unpassende Registerinhalte verwendet haben. Ich 
hoffe jedoch, dass ein bisschen Transferleistung ausreicht das Ziel zu 
erreichen.

Gruß

Bernd

Peter D. schrieb:
> Eine Lösung mit anderen Registern:

Yep, aber die war schon da.

Stefanus F. schrieb:
> Beim TST Befehl gibt man (im Opcode) zweimal das gleiche Register an,
> damit ist TST r1 identisch mit AND r1,r1.

Hallo Stefanus,

das ist aber schade! Ich dachte, es gibt so etwas wie "test under mask / 
TM" oder "test complementary under mask / TCM", wie beim Z8 oder

einfach "bit test / BIT", wie beim MSP430:
[Zitat "MSP430 ... User's Guide"]

1

Description The source and destination operands are logically ANDed. The result affects only the status bits. The source and destination operands are not affected.

2

3

Status Bits N: Set if MSB of result is set, reset otherwise

4

5

Z: Set if result is zero, reset otherwise

6

C: Set if result is not zero, reset otherwise (.NOT. Zero)

7

V: Reset

[/Zitat]

Das ist ja echt eine Einschränkung beim AVR!!!

Dass manche OP-codes mit unterschiedlichen Bezeichnungen auftreten und 
dann "emuliert" werden, nun ja das ist Geschmackssache. Aber das ist aus 
meiner Sicht normal. Ich war nur irritiert, wegen "test under mask".

Happy coding!

Bernd

Bernd B. schrieb:
> einfach "bit test / BIT", wie beim MSP430:
> [Zitat "MSP430 ... User's Guide"]Description The source and destination
> operands are logically ANDed. The result affects only the status bits.
> The source and destination operands are not affected.
>
> Status Bits N: Set if MSB of result is set, reset otherwise
>
> Z: Set if result is zero, reset otherwise
> C: Set if result is not zero, reset otherwise (.NOT. Zero)
> V: Reset
> [/Zitat]
>
> Das ist ja echt eine Einschränkung beim AVR!!!

 Wieso ?

 Wozu hast du CP Rd,Rr und CPI Rd,K ?
 Wobei Carry Flag bei AVR viel logischer ist - was bedeutet es und
 wozu soll (.NOT. Zero) gut sein ?

Bernd B. schrieb:
> Das ist ja echt eine Einschränkung beim AVR!!!

Der Opcode-Space ist begrenzt. Ein Reg-Immediate Befehl enthält einen 
8-Bit Wert und eine 4-Bit Registernummer. Arg viele Befehle dieser 
Bauart kann es in einem 16-Bit Befehlswort folglich nicht geben.

http://lyons42.com/AVR/Opcodes/AVRAllOpcodes.html

A. K. schrieb:
>> Demgegenüber erwarte ich nicht, dass z.B. ein MOV am Z-Flag spielt -
>> unabhängig davon, ob das Quellregister null war oder nicht.
>
> Es gibt allerdings reichlich viele Prozessoren, die es deinen Erwarten
> zuwider trotzdem so halten. ;-)

Ich weiß, aber ich hantiere nur äußerst selten mit Assembler.
Ein i8080 tut es jedenfalls nicht. Und dessen Flaghandling ist auch 
nicht gerade intuitiv. ;-)

S. R. schrieb:
> Und dessen Flaghandling ist auch nicht gerade intuitiv. ;-)

Nimm PIC32. Die MIPS Architektur kennt überhaupt keine Flags. ;-)

RISC-V auch nicht. Ist ein Vorteil. ;-)

Stefanus F. schrieb:
> Was soll das bedeuten? Deine CPU hat auch eine echte Einschränkung: Sie
> kann sich nicht fortpflanzen :-)

Ich freue mich, dass die gute Laune noch nicht verloren ist!

In der Tat, ich erwarte vielleicht in den nächsten Dekaden, dass sich 
die Mikroprozessoren selbst fortpflanzen können und werden. Es ist schon 
beeindruckend, wie "Prozessoren" oder "Computer" (beachte die 
Popularpresse) sich durch biologisches oder chemisches Material bilden 
oder konstruieren lassen. Wenn wir jetzt philosophisch werden, könnte 
man darüber nachdenken, ob die DNA (DNS) bereits selbst solch ein 
kleiner (Bio-)Prozessor ist. Abschnitte der DNA stehen für die Bildung 
von Aminosäuren, und kleinste Zellen oder Viren werden daraus gebildet, 
die dann selbst funktionstüchtig sind und sich selbst replizieren. 
Vielleicht erreichen die zukünftigen Prozessoren und Programmcodes oder 
-Datenträger ja die molekulare Einheit, die durch die DNA gebildet wird. 
Vielleicht laufen ja hier alle Fäden zusammen. Wenn es dann so weit ist, 
lacht man darüber, dass man in der Zeit des Übergangs vom 20-ten ins 
21-te Jahrhundert über kleine Prozessorbefehle die Haare gespalten und 
die Worte auf die Goldwaage gelegt hat und das nur um hardware-nah zu 
programmieren.

Das Wäre doch einmal ein Thema für ein spannendes Buch!

Ja, meintswegen weiterdiskutieren...

Gruß in die Runde

Bernd

Bernd B. schrieb:
> Wenn wir jetzt philosophisch werden, könnte man darüber nachdenken,
> ob die DNA (DNS) bereits selbst solch ein kleiner (Bio-)Prozessor ist.

Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine 
Parameterliste) als ein Prozessor ist. Rein pragmatisch gesehen ist das 
Weichmaterial zwischen den Ohren schon ein Computer, und der kann sich 
biologisch nachweislich fortpflanzen. ;-)

S. R. schrieb:
> Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine
> Parameterliste) als ein Prozessor ist.

Da möchte ich widersprechen! Die Sequenz der Basen Guanin, Cytosin, 
Adenin, Thymin sind meines Erachtens der Programmcode.

Die einzelnen Nukleobasen entsprechen meiner Meinung nach den Buchstaben 
im Programm.

Deine nächsten Zeilen kommentiere ich vielleicht später und nach Bedarf.

Gruß

Bernd

Bernd B. schrieb:
> S. R. schrieb:
>> Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine
>> Parameterliste) als ein Prozessor ist.
>
> Da möchte ich widersprechen! Die Sequenz der Basen Guanin, Cytosin,
> Adenin, Thymin sind meines Erachtens der Programmcode.

Für mich ist es eher der Schaltplan, vielleicht noch VHDL-Code. Es 
beschreibt, wie die Hardware aufgebaut ist.

Stefanus F. schrieb:
> Die Frage wäre dann, wo sind denn nun die kompletten Baupläne?

Na in den Stammzellen.

Bernd

Stefanus F. schrieb:
> Dazu werde ich mich mal einlesen.

Hallo Stefanus,

hier ein altes Paper aus 2007 als Einstieg:

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4142926

Du solltest es laden können.

Stefanus F. schrieb:
> Ich habe gar keine Ahnung, was an
> Stammzellen besonders ist.

[Zitat aus dem Artikel]
Stem cells are undifferentiated cells that are the precursors for other 
cell types.
[/Zitat]

Vielleicht sind sie der Heilige Gral in unserer Zeit?

Live Long and Prosper!

Bernd

Bernd B. schrieb:
> [Zitat aus dem Artikel]
> Stem cells are undifferentiated cells that are the precursors for other
> cell types.
> [/Zitat]

 Setzen die Dinger nun Carry Flag oder nicht ?

chris schrieb:
> Nope in den Genen liegt der Bauplan eines Lebewesen (kleinste
> Informationseinheit des BUPLANES ähnlich dem BIT) und

Du meintest sicher BAUplan.

Hallo Chris,

schnell einmal gegoogled und etwas in die Runde geworfen?

Das Bit soll die kleinste Informationseinheit sein. Gut! Genauso verhält 
es sich mit den 4 Basenpaaren, die als genetischer Code bezeichnet 
werden. Mit den 3 aufeinander folgenden Basenpaar-Kombinationen könnten 
64 Aminosäuren kodiert werden. Es werden aber nur 20 kodiert. Aus meiner 
persönlichen Sicht bilden die vier Basen die kleinste 
Informationseinheit auf der DNA. Die Zusammengehörigkeit der drei 
aufeinander folgenden "Zahlen" nennt man Tripel, mit denen die 
Aminosäuren ausgesucht werden.

siehe: 
https://www.google.de/imgres?imgurl=https://vignette.wikia.nocookie.net/genetica/images/2/23/Aminoacids_table.svg.png/revision/latest?cb%3D20110502134057%26path-prefix%3Dde&imgrefurl=http://de.genetica.wikia.com/wiki/Genetischer_Code&h=599&w=583&tbnid=Q40KfoRTqYplKM:&q=dna+basen+code&tbnh=160&tbnw=155&usg=AFrqEzcYNLaLiW-qVtiJJCGJwZ3N0xRJCQ&vet=12ahUKEwiJiomoi8fdAhXOlIsKHXiuDEYQ_B0wH3oECAYQEw..i&docid=v0MwL8-QpwHm_M&itg=1&sa=X&ved=2ahUKEwiJiomoi8fdAhXOlIsKHXiuDEYQ_B0wH3oECAYQEw

Mehrere dieser Tripel, also Aminosäuren bilden den Strang und dieser die 
Gene. ... usw.

Jetzt zu

chris schrieb:
> 
https://www.wissenschaft-im-dialog.de/projekte/wieso/artikel/beitrag/wie-oft-kann-sich-eine-menschliche-zelle-teilen-bevor-die-genetische-erbinformation-zu-kurz-wird/


Ich glaube der Interviewte ist mit seinem abgedruckten Text auch nicht 
zufrieden. Hier gibt es mindestens EINEN Widerspruch:

[Artikelzitat]
Nur die Stelle, an der die DNA-Polymerase am Anfang eines DNA-Stranges 
gebunden war, kann nicht kopiert werden. (etwa Zeile 15)
[/Artikelzitat]

Der Widerspruch findet sich an mehreren Stellen weiter unten:

[Artikelzitat]
Nach etwa 40 Verdopplungen sind die Enden der DNA so verkürzt, dass die 
Chromosomen instabil werden und eine korrekte Zellteilung kaum noch 
möglich ist. (übernächster Satz - auch weiter unten nochmals...)
[/Artikelzitat]

Entweder das Interview wurde in einer anderen Sprache geführt und 
unvorteilhaft übersetzt oder zu stark die Erklärung vereinfacht.

Was ich sagen will ist, die kleinste Informationseinheit ist die 
ausgewählte Base (ein Drittel Tripel) und Dein Text ist nicht ganz klar.

... aber gut, dass man mal darüber spricht.

Gruß

Bernd

Chris, Du hast das letzte Wort!

Bernd

PS: Das ist geschickt, nicht wahr?

Stefanus F. schrieb:
> Ich bin mir gar nicht so sicher, ob die DNA wirklich den gesamten
> Bauplan eines Lebewesens enthält.

Doch, das tut sie. Darauf kommt man ganz einfach, wenn man die 
Entwicklung des Lebewesens rückwärts nachvollzieht. Irgendwann kommt man 
zu Eizelle und Spermium, die jeweils einen halben Chromosomensatz tragen 
und zur ersten genetisch vollständigen Zelle des neuen Lebewesens 
verschmelzen. Danach ändert sich an der DNA nichts (grundlegendes) mehr.

DNA ist allerdings das reine Programm. Ohne "Computer" nützt das 
Programm gar nichts, deswegen braucht man auch eine Eizelle mit der 
kompletten Grundausstattung, um das neue Lebewesen zu "booten". Manche 
Bestandteile wie etwa die Mitochondrien werden unabhängig von der DNA im 
Zellkern vermehrt (sie haben ihre eigene DNA). Aber abgesehen davon 
werden alle neuen "Computer" (Zellen) nach dem Bauplan aufgebaut, der in 
der DNA codiert ist.

Es gibt eine Menge gute populärwissenschaftliche Bücher zum Thema. Sehr 
schön finde ich "Geschichten vom Ursprung des Lebens" von Richard 
Dawkins. Das Grundthema des Buches ist zwar ein anderes, aber 
Genexpression wird mehr als einmal diskutiert.

> Eine Hautzelle hat zum Beispiel die Fähigkeit, sich zu Teilen oder
> abzusterben. Die Gene bestimmen, welche Hautzellen sich wann teilen
> sollen und welche wann absterben sollen. Aber wie das Teilen/Absterben
> funktioniert, das wissen die Gene nicht.

Das ist doch gar nichts. Ich finde viel erstaunlicher, daß aus der 
gleichen Urzelle ganz verschiedene Zelltypen (Hautzellen, Knochenzellen, 
Neuronen, Blutzellen, YOU-NAME-IT) entstehen, die jeweils ganz 
verschieden aufgebaut sind und verschiedene Funktionen haben. Trotzdem 
ist die DNA in ihren Kernen die gleiche.

Das Stichwort dazu ist Genexpression/Genregulation. Nicht alle Gene auf 
der DNA sind immer aktiv. Statt dessen können sie einzeln und in Gruppen 
ein- und ausgeschaltet werden. Tatsächlich kann diese Information zum 
Teil auch vererbt werden. Das Forschungsgebiet dazu ist die Epigenetik.

Bezogen auf die Trennung von Information und Maschine ist recht 
interessant, dass nicht nur Proteine katalytisch als Enzyme wirken 
können, sondern auch DNA- und RNA-Moleküle. Die Frage liegt nahe, ob das 
im Ursprung des Lebens vielleicht eine gewisse Bedeutung hatte.

Auch dazu kann man Dawkins lesen. Die Literaturliste am Ende des Buches 
könnte ebenfalls hilfreich sein.

Bernd B. schrieb:
>> Ich würde eher behaupten, dass die DNA eher Programmcode (bzw. eine
>> Parameterliste) als ein Prozessor ist.
>
> Da möchte ich widersprechen! Die Sequenz der Basen Guanin, Cytosin,
> Adenin, Thymin sind meines Erachtens der Programmcode.

Schrieb ich doch? ;-)

chris schrieb:
> Ebenso bewundernswert ist, dass in der Natur nichts ohne Aufgabe ist,
> sei es augenscheinlich noch so nutzlos. Der Mensch meint immer das
> Manches, was er nicht versteht, erstmal ohne Funktion ist...

... und dann schnippen die Leute ihre Zigarettenkippen in die "Natur" 
oder lassen ihren Dreck einfach fallen.

Wenn wir uns wirklich tief mit dem oben auseinandersetzen, steigt doch 
nur der Respekt vor der Natur - oder?

Ich möchte jetzt nicht über Umweltverschmutzung debattieren, sondern nur 
daran erinnern, dass wir ein wertvolles Gut in den Händen halten und es 
nicht fallen lassen dürfen.

So, jetzt zurück zum Prozessor, der nicht maskiert testen kann und einem 
Entwickler, der zu hohe Erwartungen hatte (it's me). Das wäre mein 
Vorschlag und die Unterstützung zum Beitrag von Chris hier aufzuhören 
und vielleicht einen neuen Thread zu öffnen, in dem wir 
weiterdiskutieren.

Gruß

Bernd