Forum: Mikrocontroller und Digitale Elektronik ARM7 effektive Bitoperationen


von Peter P. (uncle-sam7)


Lesenswert?

Hallo NG,

nehmen wir mal an, ich habe in Register 10 folgenden Wert:
r10 = 00000000 00000000 00000000 10000000

das achte Bit (128) soll nun dafür verantwortlich sein, dass ein achtes 
Bit in einem anderen Register r9 gesetzt wird. Bereits gesetzte Bits 
sollen nicht beeinflusst werden
r9  = 00000000 00000000 00000000 10001010

ich habe mir sowas wie
CMP r10, r10, lsl #24
vorgestellt, aber das passt ja nicht, da es ja dann immer negativ wird, 
oder?

Es wäre sehr nett, wenn ich dazu ein Beispiel bekommen könnte.

Danke,
Peter

von Peter P. (uncle-sam7)


Lesenswert?

...habe eben

movs r5, r10, lsl #24 probiert. (r5 wäre dann ein "temporärer-wert").
Das N-Flag des ARM7 scheint dadurch schon mal richtig gesetz zu werden.

r10 = 0x7f --> N-flag 0
r10 = 0x80 --> N-flag 1

Wie bekomme ich dieses Flag nun am geschicktesten in r9 an das achte Bit 
(128) ?

Gruß
Peter

von Peter P. (uncle-sam7)


Lesenswert?

hallo,

habs jetzt so gemacht:

cmp r10, #128          // n-flag?
orrge r9, r9, #128

ist das OK, oder gehts kürzer?

von holger (Gast)


Lesenswert?

>ist das OK, oder gehts kürzer?

Ja, in C hätte ich da 2s für gebraucht.

von Peter P. (uncle-sam7)


Lesenswert?

holger schrieb:
>>ist das OK, oder gehts kürzer?
<zitat sarkasmus="off">
Ja, in C hätte ich da 2s für gebraucht.
</zitat>

??? versteh´ ich nicht :-(
2 Sekunden, um herauszufinden, was zu tun ist, oder?

Naja, C hatte ich ja auch schon für den SID-Player. Allerdings glaube 
ich nicht, dass man das mit C hinbekommt, ohne SRAM (Stack, Variablen 
etc.)

In Assebler siehts momentan so aus, als würde ich den Stack gar nicht 
benötigen. Und ehrlich gesagt find ich es ziemlich spaßig, das in ASM zu 
machen. Desweiteren wird das Finetuning bzgl. Zyklengenauigkeit in ASM 
wahrscheinlich auch mehr Sinn machen. Was ich auch noch sehr überzeugend 
finde: die 6502 Register bekommen bei mir einfach ARM7-Register, die ich 
nicht brauche. Nicht irgendwelche Bytes im SRAM.

Warum ich die nervigen Fragen stelle?
Wenig Erfahrung => nervige Fragen :-)

Es würde mir halt nicht gefallen, mehr Befehle als nötig zu verwenden. 
Irgendwo brauch ich vielleicht mal die Takte, die ich mir an anderen 
Stellen einsparen hätte können. Zum Anderen gibts durchaus auch Dinge, 
die ich noch lernen möchte. Früher z.B. fand ich in anderen Sprachen 
Trinitätsoperatoren etwas total komischen. Heute verwende ich Sie gerne, 
wo es Sinn macht... Genau so denke ich halt bei Arm ASM. Ich würde gerne 
so ziemlich alle Konstrukte kennen, die Sinn machen, um was zu 
erreichen. Nachdem es ein privates nichtkommerzielles Spaßprojekte ist, 
habe ich auch nicht die Anforderung, das alles mit einem bestimmten 
Aufwand abzuschließen. Man muss m.E. nach schon an so vielen Stellen, 
wenn man seine Brötchen verdient Kompromisse, Workarounds etc. eingehen, 
was ich sehr schade finde. Für mich finde ich es sogar cool, wenn der 
Code am Ende durchgänig extrem strikt Formatiert ist. Ich sehe durchaus 
Parallelen zwischen Programmieren und klassischer Handwerkskunst. Für 
mich sollte im besten Fall ein Programm nicht einfach nur 
"runtergerotzt" werden. Aber das führt jetzt zu weit.

Gruß Peter

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Hi

der GCC macht aus
1
#include <stdint.h>
2
3
uint32_t foo(uint32_t a, uint32_t b)
4
{
5
  if(a & (1<<7))
6
    return b | (1<<7);
7
  else
8
    return b;
9
}
10
11
uint32_t bar(uint32_t a, uint32_t b)
12
{
13
  return b | (a & (1<<7));
14
}
1
Disassembly of section .text:
2
3
00000000 <foo>:
4
   0:  e3100080   tst  r0, #128  ; 0x80
5
   4:  13811080   orrne  r1, r1, #128  ; 0x80
6
   8:  e1a00001   mov  r0, r1
7
   c:  e1a0f00e   mov  pc, lr
8
9
00000010 <bar>:
10
  10:  e2000080   and  r0, r0, #128  ; 0x80
11
  14:  e1810000   orr  r0, r1, r0
12
  18:  e1a0f00e   mov  pc, lr

Ich schließe daraus mal das, wenn diese Operation mitten im Code steht 
deine, bereits ideale, Lösung dabei rauskommt. Du siehst also da ist 
keinerlei Stackoperation nötig selbst wenn man die Operation in eine 
Funktion auslagert.

Es lohnt sich also auch mal den Compiler auf ein Problem loszulassen und 
dessen Ergebnis zu untersuchen selbst wenn man später in ASM 
programmiert.

Matthias

von Peter Pippinger (Gast)


Lesenswert?

Hallo Matthias,

Das ist ein echt guter Tip! Gefält mir :-)

Ich habe mir den Code vom Emulator angesehen, den ich bisher hatte. 
Dabei habe ich halt gesehen, dass viele Variablen im Speicher abgelegt 
wurden. Die Version, die Du hier aufzeigst, gefällt mir sehr gut. Das 
werde ich für die nächsten Abfragen berücksichtigen. Ich denke mal, dass 
die IAR Workbench da bestimmt ähnlich ist wie der GCC... Werde mir auf 
jeden Fall mal ein Le(e)(h)rprojekt anlegen, um solche Tests zu machen.

Gruß
Peter

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
Noch kein Account? Hier anmelden.