Hallo NG, so wie es aussieht, nervt es mich eher, zwischen den Modes "herumzuspringen". Deshalb hier ein paar Fragen: 1. Gibt es irgendwelche Perepherie im ARM, die man im Thumbmode nicht ansprechen könnte (PIO, PMC, SPI etc...) 2. Welche Möglichkeit gibt es, z.B. ein Byte von 0xFFFFF400 zu lesen. Muss ich da immer so vorgehen, dass ich die Adresse irgendwo im Speicher habe, oder gibts da eine elegantere Lösung als z.B.: Next label is a Thumb label Into_THUMB: 00008008 4800 LDR R0, [PC,#0x000] ; [_?0 (0x800C)] =0xFFFFF400 0000800A 7800 LDRB R0, [R0, #0] _?0: 0000800C FFFF BL 0xFFC0900C 0000800E F400 ; pre BL/BLX Anm.: Das würde doch bedeuten, dass ich 2 Takte brauche, um im Register das Byte von 0xFFFFF400 zu laden, oder? Wie weit darf die "Speicherstellen-Deklaration" (im Bsp: 0800C) vom LDR enfernt sein? +/- 128 Byte? 3. Ich dachte immer, dass man bei RISC grob sagen kann, 1 Befehl / Takt. Ist das nicht so? Oder wieso sagten die Apple-User früher immer: no RISC no fun :-) ? 4. Ist es OK zu sagen, ich mache mein Projekt komplett im Thumb-Mode?
> 1. Gibt es irgendwelche Perepherie im ARM, die man im Thumbmode nicht > ansprechen könnte (PIO, PMC, SPI etc...) Komische Frage. Was hat das eine mit dem anderen zu tun? > 2. Welche Möglichkeit gibt es, z.B. ein Byte von 0xFFFFF400 zu lesen. > Muss ich da immer so vorgehen, dass ich die Adresse irgendwo im Speicher > habe, oder gibts da eine elegantere Lösung als z.B.: Man kann die Basisadresse eines Peripheriebausteins anfangs in ein Register laden und relativ dazu adressieren. > Anm.: Das würde doch bedeuten, dass ich 2 Takte brauche Tatsächlich sind es noch ein paar mehr Takte, weil ein Ladebefehl auf ARM7 eher auf mindestens 3 Takte rausläuft. Auch hier kann ein Blick in die Doku des verwendeten ARM Cores nicht schaden (ich weiss, ich klinge wie eine gesprungene Platte). > 3. Ich dachte immer, dass man bei RISC grob sagen kann, 1 Befehl / Takt. Nein. > 4. Ist es OK zu sagen, ich mache mein Projekt komplett im Thumb-Mode? Nein. Es sei denn du kommst ohne Interrupts aus. Komplett ARM geht, komplett Thumb nicht. Mindestens Startup-Code und Interrupt-Wrapper sind garantiert ARM.
>> Anm.: Das würde doch bedeuten, dass ich 2 Takte brauche > Tatsächlich sind es noch ein paar mehr Takte, weil ein Ladebefehl auf > ARM7 eher auf mindestens 3 Takte rausläuft. Auch hier kann ein Blick in > die Doku des verwendeten ARM Cores nicht schaden (ich weiss, ich klinge > wie eine gesprungene Platte). Aha, das ist ja interessant. Wo finde ich denn zu jedem Befehl (THUMB + ARM) die jeweils benötigten Taktzyklen? Habe eben in der Simulation das Beispiel von oben ablaufen lassen. Da hat er mir sowohl im Thumb-Mode als auch im Arm-Mode jeweils 2 Takte für LDR und LDRB im Cyclecounter berechnet. Ist das realisisch?
>> 2. Welche Möglichkeit gibt es, z.B. ein Byte von 0xFFFFF400 zu lesen. >> Muss ich da immer so vorgehen, dass ich die Adresse irgendwo im Speicher >> habe, oder gibts da eine elegantere Lösung als z.B.: > Man kann die Basisadresse eines Peripheriebausteins anfangs in ein > Register laden und relativ dazu adressieren. ja, aber wie bekomme ich dazu im Thumb-Mode einen 32Bit-Wert (z.B. FFFFF400) ins Register, wenn doch die Befehle schon nur 16Bit lang sind? Deshalb auch meine Frage nach einer "intelligenten" Lösung, die möglichst wenig Takte benötigt. Eine Möglichkeit, wäre es so, wie im Beispiel zu machen. Gibts noch andere (Beispiele wären nett)?
Peter Pippinger wrote: >>> 2. Welche Möglichkeit gibt es, z.B. ein Byte von 0xFFFFF400 zu lesen. >>> Muss ich da immer so vorgehen, dass ich die Adresse irgendwo im Speicher >>> habe, oder gibts da eine elegantere Lösung als z.B.: > >> Man kann die Basisadresse eines Peripheriebausteins anfangs in ein >> Register laden und relativ dazu adressieren. > > ja, aber wie bekomme ich dazu im Thumb-Mode einen 32Bit-Wert (z.B. > FFFFF400) ins Register, wenn doch die Befehle schon nur 16Bit lang sind? > Deshalb auch meine Frage nach einer "intelligenten" Lösung, die > möglichst wenig Takte benötigt. Eine Möglichkeit, wäre es so, wie im > Beispiel zu machen. Gibts noch andere (Beispiele wären nett)? Dafür gibts doch die Pseudo-Befehle ldr r0,=0xfffff400 Gibts den im Thumbmodus nicht? Der wird den 32Bit Wert irgendwo im Programmspeicher ablegen und den dann dort rauslesen. Mfg Thomas Pototschnig
> Aha, das ist ja interessant. Wo finde ich denn zu jedem Befehl (THUMB + > ARM) die jeweils benötigten Taktzyklen? Rausfinden welchen Core der Controller benutzt. Atmel: ARM7TDMI, NXP: ARM7TDMI-S. Mit dieser Erkenntnis bewaffnet bei www.arm.com nach dessen Doku suchen. Steht da drin. > Da hat er mir sowohl im Thumb-Mode als auch im Arm-Mode jeweils 2 Takte > für LDR und LDRB im Cyclecounter berechnet. Ist das realisisch? Doku sagt glaube ich 3, aber ich will mich da drauf festlegen. Ausprobieren. Simuliert der exakt den ARM7TDMI Core oder peilt der bloss grob die Richtung an?
> ja, aber wie bekomme ich dazu im Thumb-Mode einen 32Bit-Wert (z.B. > FFFFF400) ins Register, wenn doch die Befehle schon nur 16Bit lang sind? Auf die gleicher Art wie du im ARM Modus 0xAAAAAAAA ins Register kriegst.
So, ist nun auch schon wieder ein paar Tage her, aber ich denke, die Frage passt trotzdem ganz gut: kann ich den Thumbcode und den ARM-Code beliebig mischen? Und macht das Sinn? Also ich sag mal richtig "Hardcore-mischen": code16 1 beliebiger Befehl code32 auch 1 belibiger Befehl code16 etc... code32 etc... braucht der ARM Takte für den Wechsel zwischen den beiden "Modes" oder sind das einfach gesagt nur unterschiedliche Opcodes? Bin nun mit dem 6502-Emulator fast durch und versuche in Richtung Optimierung ein paar Anregungen zu finden. Viele Grüße, Peter
Wechseln ist i.d.R. nur per Unterprogramaufruf sinnvoll und generell nur per Sprungbefehl (BX) möglich, was schon die Takte vorgibt. Denkst du nicht es wäre nach 3,5 Jahren langsam mal Zeit, die passende Doku zu lesen?
A. K. schrieb: > Denkst du nicht es wäre langsam mal Zeit, die passende Doku zu lesen? ja, ich versuche ja schon meine Favoritenliste entsprechend zu füllen :-) Allerdings ist das Gesammte relativ viel. Und da den kompletten Überblick zu bekommen ist - so finde ich - relativ schwer. Ich weiß auch, dass die Ausrede Zeit nicht viel zählt weil wahrscheinlich niemand hier Zeit im Überfluss hat. Bei mit ist es auf jeden Fall so, dass ich sehr wenig Zeit habe und sich das Projekt schon eine gefühlte Ewigkeit hinzieht. Deswegen bin ich froh um jeden Tipp von jemanden, der mir Dinge in verständlicher Art erklären kann. Wie dem auch sei. Wenn die erste Version jetzt dann bald lauffähig ist und ein Song gespielt wird, werde ich das mal veröffentlichen und auf Leute hoffen, die evtl. Spaß daran haben Dinge aus einem anderen Blickwinkel zu sehen und vielleicht nütliche Beträge in Sachen Optimieriung beitragen. Das Ding wird sehr wahrscheinlich von der Gewschwindigkeit allemal reichen, um SID-Files abzuspielen (das klappte ja in C schon). Aber dennoch würde es mir gefallen, wenn der Code soweit optimiert wäre, so dass da nahezu nichts mehr schneller geht. Ist einfach so ne Einstellung. Man muss stellenweise so viele Dinge einfache so runterro*zen. Das möchte ich bei diesem Hobby-Projekt nicht machen. So werden wahrscheinlich auch viele nicht verstehen, dass es mir in diesem Quelltext enorm wichtig ist, dass die Formatierung des Quelltextes ABSOLUT durchgänig ist. Viele Grüße, Peter
Thread beobachten
Seitenaufteilung abschaltenBitte 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.