Deutsches Lazarusforum

Macht eigentlich nicht viel Sinn, aber ich will den STM32 Kennenlernen. FPC für arm-embedded bauen: make clean all OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7m Je nach persönlichem Setup installieren.   begin PortC.BSRR:=%10000000000000; end.   mit <neu gebauter fpc> -Tembedded -Cparm...

Grade mal für GCC-C für linux x64 getestet: #include<stdio.h>   int main(int argc, char**argv) { printf("Hello World"); return 0; } 12 KB. Auch nicht sonderlich klein, aber um einiges kleiner als FPC. Und was sagt ldd ./hello? Evtl. noch ein paar MB Libraries not...

wp_xyz hat geschrieben:Du solltest jetzt einen Bug-Report darüber schreiben und auf den von m.fuchs genannten Report verweisen.

Ist schon behoben, es wird nun der richtige Unterprogramm-Name ausgegeben.

-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:   # [6] p(50); ldi r24,50 call PsPROGRAM_ss_PsBYTE  

Also mal Back to Topic. Warum macht der Compiler sowas: # [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 ei...

Mathias hat geschrieben:Danke, jetzt geht es. Dann kommt das @ von Intel-Assembler und nicht von FPC-Inline-Assembler ?

FPC folgt eigentlich immer den Assembler-Syntax der jeweiligen CPU-Plattform.

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

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

AVR kennt logischerweise kein Intel-Assembler. Inline-Assembler ist hier immer GNU, d.h. Labels lokal zum Assemblerblock muss man mit . einleiten:

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

Registernutzung ist eine Sache, die man vielleicht in den Griff kriegt. Aber man kann eben in Assembler unendlich Gemeinheiten schreiben, die den Compiler bzw. den Optimierer aus dem Tritt bringen, angefangen bei Aliasing oder unerwarteten Stackmanipulationen. Das gleiche gilt doch bei allem Inline...

Kurzform: Der Typ des Ergebnisses einer Operation hängt immer von den Typen der Operanden ab, bei arithmetischen Operationen gilt eigentlich immer, dass der Typ gewählt wird, in den beiden Operanden passen, bei word*word ist das eben word, bei word*integer ist das longint. Damit ist klar, dass word...

Ich bin deswegen auch der Meinung: der Nutzer einer Entwicklungssystem darf kein Assembler benötigen, falls doch, ist was am Compiler/der Sprache falsch. Und der Pascal-Compiler macht mitunter absolut komische Sachen. Einmal den Datentyp von Unsigned auf Signed gewechselt, und Du bekommst statt ein...

Ist auch extrem schwierig bis gar nicht zu implementieren, denn das würde heissen, dass der Compiler "verstehen" muss, was in der Assembler-Routine passiert. Kannst du genauer was dazu schreiben, warum muss der Compiler die Assembler-Routine verstehen? Ich würde ja keine Optimierungen vom...

Wahrscheinlich noch nirgends, ist noch zu neu, ist sicher noch nicht im wiki. Ansonsten eben in der Unit intrinsics. So neu ist die Unit auch wieder nicht, im Kopf steht 2016. Im Kopf kann viel stehen Relevant ist das svn log: ------------------------------------------------------------------------...

Nach meiner Beobachtung funktioniert "inline" nur bei normalen Routinen und nicht bei Assembler-Routinen. Ist vermutlich einfach nicht implementiert. Ist auch extrem schwierig bis gar nicht zu implementieren, denn das würde heissen, dass der Compiler "verstehen" muss, was in der...