AVR Inline-Optimierung

[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.

[FPK]

@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

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.

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)

b) nix kaputtmachen.

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

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]

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]

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 ?

[Socke]

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.

[FPK]

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

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

[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]

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]

-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.

[FPK]

-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]

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.

[Mathias]

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 ?