AVR Inline-Optimierung

Christian
Beiträge: 6079
Registriert: Do 21. Sep 2006, 07:51
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z)
CPU-Target: AVR,ARM,x86(-64)
Wohnort: Dessau
Kontaktdaten:

Re: AVR Inline-Optimierung

Beitrag von Christian »

Natürlich nützt einem das was, weils oft pinkompatible Controller von anderen Herstellern gibt. Daher entsteht ja erst der günstige Preis der Cortex-M, weil es Wettbewerb gibt.
W.m.k.A.h.e.m.F.h. -> http://www.gidf.de/

FPK
Beiträge: 65
Registriert: Mi 21. Mai 2008, 19:38
Wohnort: Erlangen

Re: AVR Inline-Optimierung

Beitrag von FPK »

Christian hat geschrieben:@Florian, schön zu sehn das dich der avr immernoch "juckt"


AVR ist eben doch ein schöner "Kompromiss" zwischen für dem Compilerbau interessanter und relevanter Architektur, der Z80-Port juckt mich eigentlich noch mehr, aber da dürfte das Interesse relativ gering sein im Vergleich zu AVR :) Wobei ich ja irgendwann noch einen 6502-Port schreiben möchte :roll:

Mathias hat geschrieben:Aber ich hoffe trotzdem, das Lazarus für AVR weiter entwickelt wird. Es wird sogar für 8088er entwickelt, obwohl man diese nicht mal mehr kaufen kann.


Da hat das eine nichts mit dem anderen zu tun: wenn sich jemand für einen Port interessiert und daran arbeitet, dann gibt es ihn wenn nicht, dann nicht. Es gibt keinen großen Masterplan.

Timm Thaler hat geschrieben:Bisher war ich mir eher unsicher, wie intensiv Avr embedded überhaupt vorangetrieben wird. Das vor Monaten angefragte direkte Lesen von Konstanten oder Strings aus dem Flash ohne Umweg über den Sram ist meines Wissens nach nicht umgesetzt. Dazu hatte ich auch Assemblercode reingestellt.


Das hängt einfach von vielen Dingen ab (wie schwierig, wie einfach, wie relevant, wie interessant, wie viel Lust, natürlich alles objektiv)

Timm Thaler hat geschrieben:b) nix kaputtmachen.


Wie willst du was kaputt machen solange du keinen Schreibzugriff auf das Subversion-Repository hast :)?

kupferstecher hat geschrieben:
FPK hat geschrieben:Was sich während/durch eines Funktionsaufrufs ändern darf und was nicht ist normalerweise klar im ABI definiert und relativ beschränkt.

Das gilt ja bereits für eine Assemblerfunktion. Wie gesagt, ich sehe nicht, welche zusätzlichen Anforderungen an eine Inlineassemblerfunktion zu stellen wären. Deshalb die Nachfrage.


Naja, nur dann bringt es halt auch relativ wenig. Inlining bringt dann was, wenn der Compiler sich den Stackframe sparen kann, Variablen und Konstanten direkt einsetzen, usw.


Naja, ein Bugreport dauert max. 10 min, das sollte einem ein OSS-Compiler schon wert sein. Dass nicht jeder einen entsprechenden Compiler-Patch erstellen kann, ist klar, wobei das bei FPC für Pascal-Programmierer noch am einfachsten sein sollte.

Wie Tim Thaler schon geschrieben hat, wo fängt ein Bug an und wo hört ein fehlendes Feature auf?


Wenn ein Feature gut durchdacht ist, dann kann es auch in den "Issue" tracker. Gibt genügend Beispiele.

Hier ein Bug/Feature Request welchen ich initiiert habe. Es geht darum ob der Compiler momentan Variablenzugriffe überhaupt optimieren darf, da es an einem Volatile-Konzept fehlt.
https://bugs.freepascal.org/view.php?id=32721

Das aber nur als Beispiel, es fehlt halt noch an mehreren Ecken.


Ja, u.a. an meiner Zeit :) Wenn sich andere um Sachen wie optimiertes Shiften implementieren und testen kümmern (was wie gesagt recht einfach ist, wenn man sich den genannten Commit als Vorbild nimmt), dann kann ich mich um die komplexeren Sachen kümmern :)

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: AVR Inline-Optimierung

Beitrag von Timm Thaler »

FPK hat geschrieben:Wenn sich andere um Sachen wie optimiertes Shiften implementieren und testen kümmern...


Bin wieder zurück und kann nur wiederholen: Ich bringe meine Erfahrung in Asm auf AVR gern da ein, weil ich da a) Potenzial sehe (auch wegen Arduino) und b) eine durchaus brauchbare Alternative zu C. Ich bräuchte halt eine Einführung, wie man sowas implementiert, ohne allzuviel kaputtzumachen.

Ich hätte da diverse optimiere Mul und Div-Funktionen zu bieten. Eine Sqrt für 32-bit. Inc kann man übrigens auch noch optimieren. ;-)

Mathias
Beiträge: 6165
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: AVR Inline-Optimierung

Beitrag von Mathias »

Ich habe mal kurz gegoogelt, aber nichts gescheites gefunden.

Gibt es die PIC32 und Cortex M3 auch in einem handlichen DIP-Gehäuse, so wie es der Atmega328 ist ?
Und ist die Programmierung und das Flashen auch so einfach ?
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Socke
Lazarusforum e. V.
Beiträge: 3158
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: AVR Inline-Optimierung

Beitrag von Socke »

Mathias hat geschrieben:Gibt es die PIC32 und Cortex M3 auch in einem handlichen DIP-Gehäuse, so wie es der Atmega328 ist ?
Und ist die Programmierung und das Flashen auch so einfach ?

Du bekommst den Cortex M0 als 28er-DIP von NXP: LPC1114

In der Theorie kann man den per UART programmieren, wobei ich mir bei meinem einzigen Versuch einen Spannungswandler zerschossen habe. Das laste ich aber eher mir selbst an.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

FPK
Beiträge: 65
Registriert: Mi 21. Mai 2008, 19:38
Wohnort: Erlangen

Re: AVR Inline-Optimierung

Beitrag von FPK »

Socke hat geschrieben:Du bekommst den Cortex M0 als 28er-DIP von NXP: LPC1114


... und wird auch von FPC unterstützt.

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: AVR Inline-Optimierung

Beitrag von Timm Thaler »

Also mal Back to Topic.

Warum macht der Compiler sowas:

Code: Alles auswählen

# [105] delay_us(50);  // Write Delay
   ldi   r26,50
   mov   r24,r26
   call   INIT_ss_DELAY_USsBYTE
 

Warum wird die Konstante nicht gleich in r24 geladen? Nicht dass es mich an dieser Stelle stören würde, danach rödelt der Compiler 500 Takte in einer Schleife, weil er auf das blöde Display wartet. Ich würde es nur gern verstehen.

FPK
Beiträge: 65
Registriert: Mi 21. Mai 2008, 19:38
Wohnort: Erlangen

Re: AVR Inline-Optimierung

Beitrag von FPK »

Timm Thaler hat geschrieben:Also mal Back to Topic.

Warum macht der Compiler sowas:

Code: Alles auswählen

# [105] delay_us(50);  // Write Delay
   ldi   r26,50
   mov   r24,r26
   call   INIT_ss_DELAY_USsBYTE
 

Warum wird die Konstante nicht gleich in r24 geladen? Nicht dass es mich an dieser Stelle stören würde, danach rödelt der Compiler 500 Takte in einer Schleife, weil er auf das blöde Display wartet. Ich würde es nur gern verstehen.


-O3 vergessen?

Timm Thaler
Beiträge: 1224
Registriert: So 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded
CPU-Target: Raspberry Pi 3

Re: AVR Inline-Optimierung

Beitrag von Timm Thaler »

FPK hat geschrieben:-O3 vergessen?

Nö. Ich kompiliere für AVR immer mit O3. Mit O2 macht er auch einfache for-Schleifen mit 16bit, und O4 wird ja nicht empfohlen.

Gerade mal O4 versucht. Uiii, das ist ja wirklich "aggressiv". Da ruft er die Delay-Routine mit einem jmp statt call auf, und springt dann direkt aus der Delay-Routine zurück.

Allerdings bleibt das ldi - mov dennoch stehen. Taucht so noch an verschiedenen Stellen im Programm auf, wenn eine (uint8) Konstante an eine Prozedur übergeben wird.
Zuletzt geändert von Timm Thaler am Sa 3. Mär 2018, 14:53, insgesamt 1-mal geändert.

FPK
Beiträge: 65
Registriert: Mi 21. Mai 2008, 19:38
Wohnort: Erlangen

Re: AVR Inline-Optimierung

Beitrag von FPK »

Timm Thaler hat geschrieben:
FPK hat geschrieben:-O3 vergessen?


Nö. Ich kompiliere für AVR immer mit O3. Mit O2 macht er auch einfache for-Schleifen mit 16bit, und O4 wird ja nicht empfohlen.


Dann bitte komplettes Beispiel :)

Mit einem einfachen Test kriege ich nämlich:

Code: Alles auswählen

 
# [6] p(50);
   ldi   r24,50
   call   PsPROGRAM_ss_PsBYTE
 

Mathias
Beiträge: 6165
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: AVR Inline-Optimierung

Beitrag von Mathias »

Gerade mal O4 versucht. Uiii, das ist ja wirklich "aggressiv". Da ruft er die Delay-Routine mit einem jmp statt call auf, und springt dann direkt aus der Delay-Routine zurück.

Wie viel mal hast du Delay aufgerufen ?
Wen es mehrmals wie nur einmal ist, würde dies mit jmp nicht mehr funktionieren.
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Mathias
Beiträge: 6165
Registriert: Do 2. Jan 2014, 17:21
OS, Lazarus, FPC: Linux (die neusten Trunk)
CPU-Target: 64Bit
Wohnort: Schweiz

Re: AVR Inline-Optimierung

Beitrag von Mathias »

FPK hat geschrieben:
Socke hat geschrieben:Du bekommst den Cortex M0 als 28er-DIP von NXP: LPC1114


... und wird auch von FPC unterstützt.

Der Thread ist mir untergegangen.

Den LPC1114 muss ich mal genauer angucken, wie wird der von FPC unterstützt, über embedded arm ?
Was aber noch ein grösseres Problem ist, der Chip ist nicht mal bei Reichelt erhältlich.

Aber zuerst werde ich mich mehr mit den AVR beschäftigen.

Ist auf dem Arduino due ein ähnlicher Chip verbaut ?
Mit Lazarus sehe ich grün
Mit Java und C/C++ sehe ich rot

Antworten