Hallo, ich möchte einen 16 Bit Registerpaar zu einem anderen 16 Bit Registerpaar addieren und danach prüfen, ob das Ergebnis 0 ist. Mit breq geht das ja leider nicht. Was wäre ein eleganter Weg? add r16,r20 adc r17,r21 breq fehler ;geht nicht!
Da es sich hier um eine 8 Bit CPU handelt, musst du beide Register einzeln auf Null testen.
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.
adiw geht nur mit immediates, nicht mit registern. sub $ sbc wäre eine idee... leider isses hier eine subtraktion. wenn ich die formel umstelle, brauche ich mehr befehle. da kann ich auch genausogut mit adiw x,0 $ breq prüfen. ich dachte, es gäbe irgend einen brXX Trick dafür.
Beitrag #5557391 wurde vom Autor gelöscht.
Na dann bleibts wohl dabei. add $ adc $ brXX unmöglich. Schade.
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
:
Bearbeitet durch User
Nagut, damit kann man auf Parität prüfen. Aber es geht mir ja darum, auf 0x0000 zu prüfen. Mit brmi kann man z.B. ohne Probleme auf <0x0000 prüfen. Die allgemeingültige Lösung, um auf <= 0 zu prüfen wäre somit: add adc brmi cp cpc breq 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. PS: adiw breq benötigt übrigens auch 3 Takte. Spart also nur 2 Bytes Flash. Allerdings ist Flash für Assemblerprogrammierer seltenst das Problem.
Beitrag #5557735 wurde vom Autor gelöscht.
Beitrag #5557738 wurde vom Autor gelöscht.
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: |
Ein Step weniger:
add r16,r20
adc r17,r21
brne weiter
tst r16
breq fehler
Ist euch schon aufgefallen, dass der TST Befehl eine Mogelpackung ist? Sein Opcode ist mit AND identisch.
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.
:
Bearbeitet durch User
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.
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
:
Bearbeitet durch User
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 ?
Chris H. schrieb: > add r16,r20 > adc r17,r21 > add r16,r17 > tst r16 > breq fehler Der TST befehl ist nicht nötig.
Chris H. schrieb: > add r16,r17 Schon mal nachgerechnet mit R17 = 1 und R16 = 255? OR passt da schon besser.
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.
Thomas E. schrieb: > 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? Jemand, der das AVR Instruction Set Manual liest. Übrigends git es SBR und BSET. Solltest mal genau schreiben, was du meinst.
Thomas E. schrieb: > Wer (außer eingefleischten AVR-Kennern) Falls man die Asm Statements nicht kennt, sollte man ins Handbuch schauen! Wer das nicht macht, fällt mit Fug und Recht auf die Nase. Denn Fantasie und Tagträume, können kein Wissen ersetzen.
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.
:
Bearbeitet durch User
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.
S. R. schrieb: > Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte > Bit in einem Register gelöscht habe. Ich verstehe, was du sagen willst, aber die Ausdrucksweise gefällt mir nicht wirklich. 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. Schön (und sinnvoll) wäre es gewesen, wenn sich die Addition beim AVR8 genauso verhielte, tut sie aber leider nicht. Der Nachteil ist aber in der Praxis i.d.R. minimal, weil es fast nie eine Rolle spielt, ob die Addition zweier NULL-Werte erfolgt ist. Das kann man nämlich normalerweise leicht vorher abfangen. Und den anderen denkbaren Fall, dass die Addition zweier Nicht-NULL Werte NULL ergibt, kann man leicht über das Carry- und Zeroflag ermitteln. Spielt bloß normalerweise ebenfalls keine Rolle, weil das Entscheidende für die Mathematik allein im Carry-Flag steckt. Ob die LSBs dann NULL sind oder nicht: who cares?
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. TEST r16 (bei r16=0) setzt auch das Z Flag obwohl kein Bit verändert wurde.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 ?
:
Bearbeitet durch User
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...
Marc V. 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. 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. Wenn dich ein Polizist anhält und sagt "Verkehrskontrolle: Haben sie gerade an einem Joint gezogen?" antwortest du doch auch nicht: "Ja irgendwann habe ich das wohl mal." Das Wort "Gerade" bezieht sich schließlich auf "unmittelbar zuvor". Bei Assembler würde ich sagen, es bezieht sich auf den Befehl unmittelbar vor dem aktuellen oder zumindest auf die Befehle, die seit dem letzten Löschen des Flags ausgeführt wurden.
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.
:
Bearbeitet durch User
Marc V. schrieb: > Und wie willst du dann irgendein bit löschen ? Mit irgendeiner Operation, zum Beispiel AND.
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: > Ich bezog mich auf "Bit Clear"-Befehle, nicht auf allgemeine > ALU-Befehle. Blöderweise war allerdings genau dies Thema dieses Threads: die Inkonsistenz bezüglich der Flag-Behandlung zwischen Addition und Subtraktion im Befehlssatz der AVR8...
Marc V. schrieb: > Was willst du löschen wenn alle Bits schon immer gelöscht waren ? Nichts. Das ist ja der springende Punkt bezüglich der Wortwahl in >> Das Z-Flag sagt mir nämlich, dass ich gerade das letzte gesetzte >> Bit in einem Register gelöscht habe. 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).
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 Nachtrag: Oh, das hat sich jetzt Zeitlich mit Rolfs Antwort überlappt. > 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. Glaube ich jedenfalls, mir fällt gerade keine Ausnahme ein. Ich programmiere nicht mehr oft in Assembler.
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."
:
Bearbeitet durch User
A. K. 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.
Überseh ich was, oder geht nicht auch einfach:
1 | add r16, r20 |
2 | brne NichtNull |
3 | adc r17, r21 |
4 | brne NichtNull |
5 | Null: |
6 | ... |
7 | |
8 | NichtNull: |
9 | ... |
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.
:
Bearbeitet durch User
Beitrag #5558625 wurde vom Autor gelöscht.
Dr. Sommer schrieb: > Überseh ich was, oder geht nicht auch einfach: Wenn du das Ergebnis der Addition nicht benötigst...
A. K. schrieb: > Wenn du das Ergebnis der Addition nicht benötigst... Achso, ja... Dann so?
1 | add r16, r20 |
2 | brne NichtNull1 |
3 | adc r17, r21 |
4 | brne NichtNull |
5 | Null: |
6 | ... |
7 | |
8 | NichtNull1: |
9 | adc r17, r21 |
10 | NichtNull: |
11 | ... |
Ok, ist dann auch nicht mehr kürzer als die Alternativen.
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: > Da steht doch "the register will remain UNCHANGED" - die Register, die > zur Operation verwendet werden. Das Register wird einfach mit dem vorherigen Wert erneut beschrieben. Wenn man "R := R and R" rechnet, kommt das gleiche wie vorher raus. Somit braucht man in Hardware nur die Logik für einen einzelnen Befehl (and). Sowas ist übrigens absolut gängig und auch auf anderen Plattformen wie ARM und x86 zu finden.
Bernd B. schrieb: > Stefanus F. schrieb: >> Ist euch schon aufgefallen, dass der TST Befehl eine Mogelpackung ist? >> Sein Opcode ist mit AND identisch. > Das kann ich gar nicht glauben und habe im benannten Manual nachgesehen: > Da steht doch "the register will remain UNCHANGED" - die Register, die > zur Operation verwendet werden. Demnach sind doch AND und TEST > unterschiedlich. Schau genau hin. Beide Befehle haben den Opcode 0010 00xx xxxx xxxx Beim TST Befehl gibt man (im Opcode) zweimal das gleiche Register an, damit ist TST r1 identisch mit AND r1,r1. Dass AND r1,r1 im Register r1 nichts verändert, ist klar, oder nicht?
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.
:
Bearbeitet durch User
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: > Eigentlich sollte jeder in der Lage sein, sich auf das Wesentliche > zu konzentrieren und Unnötiges im Geiste auszublenden. Das ist für einen Großteil der Menschen richtig schwierig. Andere wiederum haben das Talent ohne sich dessen bewusst zu sein. Konzentriert und strukturiert arbeiten ist für viele Jobs (z.B. Entwickler) die halbe Miete. Aber es gibt auch Jobs, wo das weniger gefragt ist. So findet jeder seinen Platz im leben.
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
:
Bearbeitet durch User
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
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: > Das ist ja echt eine Einschränkung beim AVR!!! Es kann nicht jeder Prozessor alles können... Aber ARM kann's ;-) Test (immediate) performs a bitwise AND operation on a register value and an immediate value. It updates the condition flags based on the result, and discards the result. Test (register) performs a bitwise AND operation on a register value and an optionally-shifted register value. It updates the condition flags based on the result, and discards the result. Test (register-shifted register) performs a bitwise AND operation on a register value and a register-shifted register value. It updates the condition flags based on the result, and discards the result.
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
:
Bearbeitet durch User
Bernd B. schrieb: > Das ist ja echt eine Einschränkung beim AVR!!! Was soll das bedeuten? Deine CPU hat auch eine echte Einschränkung: Sie kann sich nicht fortpflanzen :-) Mir genügt, dass AVR nach Turing vollständig sind und meine C Programme ausführen können. Ich brauche keine CPU, die alles kann.
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. ;-)
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.
Ich bin mir gar nicht so sicher, ob die DNA wirklich den gesamten Bauplan eines Lebewesens enthält. Ich glaube eher, dass sie nur Konfigurationsparameter enthält. Ich meine das so: 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. Die Frage wäre dann, wo sind denn nun die kompletten Baupläne? Ich schätze, dass bleibt uns Menschen für immer verborgen.
Stefanus F. schrieb: > Die Frage wäre dann, wo sind denn nun die kompletten Baupläne? Na in den Stammzellen. Bernd
Bernd B. schrieb: >> Die Frage wäre dann, wo sind denn nun die kompletten Baupläne? > Na in den Stammzellen. Dazu werde ich mich mal einlesen. Ich habe gar keine Ahnung, was an Stammzellen besonders ist.
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 ?
Beitrag #5561006 wurde vom Autor gelöscht.
Bernd B. schrieb: > Stefanus F. schrieb: >> Die Frage wäre dann, wo sind denn nun die kompletten Baupläne? > > Na in den Stammzellen. > > Bernd Nope in den Genen liegt der Bauplan eines Lebewesen (kleinste Informationseinheit des BUPLANES ähnlich dem BIT) und in der Anzahl der Chromosomen liegt die Art des Lebewesen der aus dem Bauplan entstehen kann während jede Zelle des Körpers der Träger des Bauplanes ist. So wäre ein Genanalyse nicht möglich wenn nicht alle Zellen den KOMPLETT identischen Bauplan eines Lebewesen enthalten würden... So könnte man die Aussage auffassen, das es nur eine Art von Stammzellen gäbe. (embryonale Stammzellen) in jegliches Gewebe wandelbar (a-d-u-l-t-e- Stammzellen) in bestimmte festgelegte Gewebetypen wandelbar (Vorläuferzellen von Ei- und Samenzellen) Urkeimzellen der Keimdrüsenleiste Besonderheit hierbei ist das die fertige Zelle nur die hälfte an Chromosomen besitzt somit nicht den gesamten Bauplan eines Lebewesen.... Stefanus F. schrieb: > Ich bin mir gar nicht so sicher, ob die DNA wirklich den gesamten > Bauplan eines Lebewesens enthält. Doch doch auch die Junk-DNA ist notwendig für evolutionäre Mutationen, würde man jetzt sagen, denn wenn die nicht da wäre könnte dein zweiter Satz nicht passen: > Ich glaube eher, dass sie nur > Konfigurationsparameter enthält. der es aber recht gut und einfach beschreibt. Wo und Wie sollte die Information gespeichert werden wenn sich die Umwelt ändert ? Nahrungsaufnahme ist nichts weiter als Informationsweitergabe von der Umwelt in einen Organismus um sich anzupassen. Stefanus F. schrieb: > 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. Nope wann jetzt deine Hautzelle stirbt hängt von der Menge der Zellteilungen ab, aufgrund dieser Teilungen verringert sich geringfügig der neue DNA(Gen)-Strang. Ist dieser "aufgebraucht", da der Anfang nicht weiter gegeben werden kann, ist eine Teilung nicht mehr möglich. 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/
Marc V. schrieb: > Setzen die Dinger nun Carry Flag oder nicht ? bei einer neuen Zellteilung setzen auch diese ein Carry Flag im Sinne das die DNA in einer Zelle plötzlich doppelt vorhanden ist... absolut logisch kopfkratz
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
Bernd B. schrieb: > Hallo Chris, > > schnell einmal gegoogled und etwas in die Runde geworfen? In die Runde geworfen ? Eben nicht, diese Meldung wurde 2004/2005 schon in einer öffentlich Rechtlichen Sendung mit dem Namen "NANO" recht gut erklärt. Nur leider fällt der Podcast mit dieser 1 Jahres-Klausel aus den öffentlich rechtlichen Mediatheken schon raus. Aber Hier mal ein Update vom letzten Jahr mit neueren Erkenntnissen auch wieder im NANO-Magazin https://www.youtube.com/watch?v=Yy1_Mj2XmEU Bernd B. schrieb: > Genauso verhält > es sich mit den 4 Basenpaaren, die als genetischer Code bezeichnet > werden. Grundsätzlich geb ich dir recht nur soweit sollte es nicht gehen dann müsste man das Bit als Ladung bei einer bestimmten Spannung (Vergleich zu den Basenpaaren) betrachtet werden, da die Information in der Ladungsmenge gespeichert ist und nur einfach ein/ausgeschaltet werden kann ebenso als Vergleich herhalten. Das gleiche wird mit den Genen, so die bisherige Lehrmeinung, verstanden das Umwelteinflüsse Gene de/aktivieren... = Mutationen.... Bernd B. schrieb: > Ich glaube der Interviewte ist mit seinem abgedruckten Text auch nicht > zufrieden. Hier gibt es mindestens EINEN Widerspruch: Grundtenor ist das die Telomerasen für das Sterben von Zellen vorrangig verantwortlich gemacht werden. Aber wer weis was die Wissenschaft in Zukunft an Wissen erfährt... Damit würde ich es erst einmal belassen bevor der Thread unnötig zugespamt wird...
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? ;-)
A. K. schrieb: > 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. Der problematische(re) Teil hier bleibt weiterhin der Begriff "Information". Zu Hilfe(?) nehmen kann man sich noch den Spruch: "Das Ganze ist mehr als die Summe seiner Teile". (auch Synergien mit in die Überlegung nehmen) Man kann sich aber bei der Unterscheidung zwischen Genotyp und Phänotyp und der dazugehörigen Zwillingsforschung schon gewisse Gedanken machen, z.B. warum sich Zwillinge hier und da unterscheiden. Hinsichtlich gewisser "Sternenkoordinaten" unterscheiden sich die Zwillinge, Drillinge usw. sowieso.
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... S. R. schrieb: > Schrieb ich doch? ;-) Stefanus F. schrieb es auch schon und ich kann mich eurer Meinung anschließen.
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
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.