Assembler - 1 bit in einem Register "kippen"

https://www.mikrocontroller.net/articles/Bitmanipulation#Bits_invertieren

Da gibts die Befehle CBR, SBR für r(16)

und die Befehle cbi bzw sbi für DDR(B)

cbi ddrb,5 macht mit einem Befehl genau das, was Du möchtest.

Peter R. schrieb:
> Da gibts die Befehle CBR, SBR für r(16)
>
> und die Befehle cbi bzw sbi für DDR(B)
>
> cbi ddrb,5 macht mit einem Befehl genau das, was Du möchtest.

Wenn mit 'kippen' das Toggeln eines Bits gemeint war (und genau danach 
sieht der Originalcode aus), dann nicht.

Ok, das "kippen" hab ich nicht als toggeln verstanden.

Da muss man halt mit sbic/sbis arbeiten:

   sbis ddrb,5
   rjmp label2
label1:
   cbi ddrb,5
   rjmp ende
label2:
   sbi ddrb,5
ende:

Wenn das T-flag anderweitig benötigt wird, ist dies eine Möglichkeit.

Das sieht nach vielen Befehlen aus, aber wenn man den Weg nach sbic 
verfolgt, sinds 3 Befehle, die abgearbeitet werden.

Selbstverständlich ist es am kürzesten, ein Bit im portb zu toggeln, 
wenn der Kontroller sbi pinb,5 im Befehlsvorrat hat.

c-hater schrieb:
> Trotzdem gehört "eori" definitiv zu den top three der von mir
> meistvermissten AVR-Instruktionen.

Jeder dieser 8-Bit Immediate-Befehle frisst 1/16 des Coderaumes weg. Das 
ist auch der Grund, weshalb die unteren Register dran glauben mussten. 
Für jeden neuen Befehl dieser Art müsstest du also klarstellen, welcher 
andere Befehl dieser Art wegfallen darf.

> locker die doch ziemlich überflüssigen adiw/sbiw-Opcodes opfern können

Dadurch wird jeweils nur 1/256 des Opcode-Spaces frei. Wenn du noch 14 
weitere solche Befehle findest tät es für EORI reichen.

ADIW/SBIW werden zudem ziemlich oft gebraucht, zumindest in C. Nämlich 
bei Pointern. Sehr viel häufiger als EORI.

> Übrigens: die anderen beiden meiner top three der meistvermissten
> AVR-Instruktionen sind "cpsne" und "cpci".

Für CPCI ginge ebenfalls 1/16 des Coderaumes drauf.

Was du eigentlich suchst ist eine AVR-Variante mit 17-Bit Befehlsbreite.

PS: Übersichtliche Darstellung des Coderaums:
https://en.wikipedia.org/wiki/Atmel_AVR_instruction_set#Instruction_encoding

c-hater schrieb:
> Mir tränen nur die Augen, wenn ich sehe, was
> darüber hinaus alles möglich wäre, wenn man nicht schon beim Design der
> Opcodes Rücksicht auf so einen unnützen Schwachsinn wie "C" genommen und
> damit die vielversprechende Hardware bereits sozusagen pränatal
> kastriert hätte...

Nicht weinen. Nimm einfach einen anderen Controller oder leb damit.
Auch ich denke mir beim Befehlssatz des AVR: "Man, hätte man das nicht 
besser machen können!?" Also: Nimm einen 68k oder 8051. Aber rumjammern 
hilft nicht.

---

Hier nicht anwendbar, aber vielleicht dennoch nützlich zu wissen:
Portpins kann man bei den neueren AVRs ganz einfach toggeln, indem man 
das PIN-Register mit 1 beschreibt.


Gruß

Jobst

A. K. schrieb:
> Was du eigentlich suchst ist eine AVR-Variante mit 17-Bit Befehlsbreite.

Es gibt ja schon einige 32Bit breite Befehle (CALL, JMP, LDS), da hätte 
man haufenweise weitere Befehle unterbringen können.
Es ist ja nicht der Codeverbrauch, sondern die fehlende Atomizität, die 
stört.

Jobst M. schrieb:
> Aber rumjammern hilft nicht.

Was einmal publiziert wurde, läßt sich kaum korrigieren.
Intel und Philips hatten ja auch mal versucht, den 8051 auf 16Bit 
aufzubohren und sind damit kläglich gescheitert. Niemand wollte die 
Dinger haben.
Ich hab noch ein 80C251-Evalboard mit Keil C251 Lizenz rumliegen.

c-hater schrieb:
> Eben. Wer braucht schon C bei diesen kleinen Dingern?

Und leise rattert im Keller die Bartwickelmaschine.
Gähn.

Peter D. schrieb:
> Es gibt ja schon einige 32Bit breite Befehle (CALL, JMP, LDS), da hätte
> man haufenweise weitere Befehle unterbringen können.

LDS in der heutigen 2-Wort Form entstand m.W. erst, als IAR(?) Atmel im 
Rahmen der frühen Zusammenarbeit dran erinnerte, dass Banking keine gute 
Idee ist.

Haufenweise Befehle unterzubringen war erkennbar nicht das Ziel.