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
...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
hallo, habs jetzt so gemacht: cmp r10, #128 // n-flag? orrge r9, r9, #128 ist das OK, oder gehts kürzer?
>ist das OK, oder gehts kürzer?
Ja, in C hätte ich da 2s für gebraucht.
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
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.