AVR Inline-Optimierung

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.

Re: AVR Inline-Optimierung

Beitragvon Christian » 24. Feb 2018, 00:12 Re: AVR Inline-Optimierung

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/
Christian
 
Beiträge: 6101
Registriert: 21. Sep 2006, 06:51
Wohnort: Dessau
OS, Lazarus, FPC: iWinux (L 1.x.xy FPC 2.y.z) | 
CPU-Target: AVR,ARM,x86(-64)
Nach oben

Beitragvon FPK » 25. Feb 2018, 11:12 Re: AVR Inline-Optimierung

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 :)
FPK
 
Beiträge: 50
Registriert: 21. Mai 2008, 18:38
Wohnort: Erlangen

Beitragvon Timm Thaler » 25. Feb 2018, 14:08 Re: AVR Inline-Optimierung

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. ;-)
Timm Thaler
 
Beiträge: 575
Registriert: 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.64 FPC3.0.4, Raspbian Stretch Laz1.62 FPC3.0.2 | 
CPU-Target: Raspberry Pi 3
Nach oben

Beitragvon Mathias » 25. Feb 2018, 17:49 Re: AVR Inline-Optimierung

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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3855
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Socke » 26. Feb 2018, 20:39 Re: AVR Inline-Optimierung

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
Socke
 
Beiträge: 2497
Registriert: 22. Jul 2008, 18:27
Wohnort: Köln
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 8.1/Debian GNU/Linux/Raspbian/openSUSE | 
CPU-Target: 32bit x86 armhf
Nach oben

Beitragvon FPK » 26. Feb 2018, 21:44 Re: AVR Inline-Optimierung

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


... und wird auch von FPC unterstützt.
FPK
 
Beiträge: 50
Registriert: 21. Mai 2008, 18:38
Wohnort: Erlangen

Beitragvon Timm Thaler » 3. Mär 2018, 12:21 Re: AVR Inline-Optimierung

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.
Timm Thaler
 
Beiträge: 575
Registriert: 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.64 FPC3.0.4, Raspbian Stretch Laz1.62 FPC3.0.2 | 
CPU-Target: Raspberry Pi 3
Nach oben

Beitragvon FPK » 3. Mär 2018, 14:12 Re: AVR Inline-Optimierung

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?
FPK
 
Beiträge: 50
Registriert: 21. Mai 2008, 18:38
Wohnort: Erlangen

Beitragvon Timm Thaler » 3. Mär 2018, 14:43 Re: AVR Inline-Optimierung

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 3. Mär 2018, 14:53, insgesamt 1-mal geändert.
Timm Thaler
 
Beiträge: 575
Registriert: 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.64 FPC3.0.4, Raspbian Stretch Laz1.62 FPC3.0.2 | 
CPU-Target: Raspberry Pi 3
Nach oben

Beitragvon FPK » 3. Mär 2018, 14:45 Re: AVR Inline-Optimierung

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
 
FPK
 
Beiträge: 50
Registriert: 21. Mai 2008, 18:38
Wohnort: Erlangen

Beitragvon Mathias » 3. Mär 2018, 17:37 Re: AVR Inline-Optimierung

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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3855
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Mathias » 3. Mär 2018, 17:44 Re: AVR Inline-Optimierung

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 gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3855
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

• Themenende •
Vorherige

Zurück zu Sonstiges



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron
porpoises-institution
accuracy-worried