www.mikrocontroller.net

Forum: Compiler & IDEs Optimierungvorgabe einer einzelnen Funktion


Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Gemeinde,

ich habe eine Frage. Und zwar: Ist es möglich beim GCC innerhalb eines 
quellfiles mit mehreren darin enthaltenen funktionen eine einzelne mit 
einer anderen optimierungsstufe compilieren zu lassen?

ein function attribute sozusagen?

danke für hilfreiche antworten

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
5.52.12 Function Specific Option Pragmas:

http://gcc.gnu.org/onlinedocs/gcc/Function-Specifi...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GCC >= 4.4, d. h. noch nicht in freigegebenen Versionen enthalten.

Meist deutet eine derartige Frage aber eher darauf hin, dass der
Fragesteller einfach nur keine Lust hat, die Ursache für eine
unerwünschte Funktion zu beseitigen und seinen Code zu korrigieren,
sondern stattdessen lieber die Wirkung modifizieren will, indem
man ,,einfach mal'' die Optimierung ausschaltet.

Falls es um AVR und Verzögerungsschleifen geht (Kandidat #1 für eine
derartige Fragestellung): Timer benutzen oder die Funktionen aus
<util/delay.h>.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
weit gefehl jörg:

ich habe es schlichtweg in der doku des gcc überlesen...

es geht um folgendes, um mich mit dem cortex m3 vertrat zu machen habe 
ich begonnen einen seiner vorteile umzusetzen, dank der NVIC ist es hier 
möglich auch den startup code komplett in c zu schreiben, und sich die 
entsprechenden adressen der sections vom linker übergeben zu lassen.

an sich eine schöne übung.
mit stolperfallen:

1) lokale variablen des reset_handler werden auf dem stack abgelegt, 
unschön, da man manchmal nicht darauf verzichten will die stack mit 
einem wert vorzuinitialisieren...
2) globale hilfsvariablen um die schaufelarbeiten zu erledigen scheiden 
ebenfalls aus, da man sich diese evtl. beim überladen der .data section 
oder der .bss section mittendrin plättet...

...erste lösung, man bittet den compiler register zu nutzen...

schaut man sich nun das compilat an stellt man bei keiner optimierung 
zunächst einen lästigen epilog von pushs unsd pops... und ein reges 
nutzen des stacks.

einen grossteil des epilogs nimmt einem das attribut interrupt ab (zu 
einem solchen handlertyp gehört der reset handler schliesslich auch)
die restlichen epilog bestandteile eliminiert das attribut naked...

aber: der funktionsrumpf hat nach wie vor stacknutzung, volle ignoranz 
gegenüber der bitte um register (3 an der zahl wurden angefordert..

erst mit der optimierungsstufe 1 produzierte er einen startupcode als 
wäre er handgeschrieben...

deswegen dediziert diese funktion mit dieser stufe...



ausserdem ist nur das pragma erst ab 4.4 da das attribute schon je 
her...

...und "so einfachmal" tu ich mal keinen finger krumm :D

UND blockierende verzögerungsschleifen gehören auch schon jahre nicht 
mehr in mein konzept :D

viel interessanter wäre, in wie weit sich dieser output mit einer 
anderen (evtl. zukünftigen) gcc version verändert. ob er dann immernoch 
brav bei reigstern bleibt, ohne sich des stacks/ram zu bedienen?

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D A N K E vergessen :)

dankedankedankedankedankedankedankedankedankedanke

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wrote:

> ...erste lösung, man bittet den compiler register zu nutzen...

"register" und "auto" sind heutzutage überflüssige Schlüsselworte.
Ohne Optimierung (hast du ja gerade gesehen) kommt alles auf den
Stack, da ja die Codegenerierung sehr geradlinig erfolgt.  Mit
Optimierung wird auf jeder vernünftigen Maschine (also alles außer
i386 & Co. :) so viel, wie's nur geht, in Register gepackt --
egal, ob du da "register" hinschreibst oder nicht.  Der Compiler
weiß an Hand seiner Codeanalyse besser, welche Variablen an welchen
Stellen tatsächlich notwendig sind und (sollte wissen) wie man die
Register möglichst effektiv dafür nimmt.

> deswegen dediziert diese funktion mit dieser stufe...

Und warum nicht alles optimiert?

> viel interessanter wäre, in wie weit sich dieser output mit einer
> anderen (evtl. zukünftigen) gcc version verändert. ob er dann immernoch
> brav bei reigstern bleibt, ohne sich des stacks/ram zu bedienen?

Nun, wenn das nicht mehr in Register passt, muss er so oder so auf
den Stack ausweichen.

__attribute__((naked)) gibt's beim GCC für einige Architekturen um
den Compiler anzuweisen, dass er keinerlei Prolog/Epilog generieren
soll.  Use at your own risk. ;-)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> es geht um folgendes, um mich mit dem cortex m3 vertrat zu machen habe
> ich begonnen einen seiner vorteile umzusetzen, dank der NVIC ist es hier
> möglich auch den startup code komplett in c zu schreiben, und sich die
> entsprechenden adressen der sections vom linker übergeben zu lassen.
>
> an sich eine schöne übung.
> mit stolperfallen:
>
> 1) lokale variablen des reset_handler werden auf dem stack abgelegt,
> unschön, da man manchmal nicht darauf verzichten will die stack mit
> einem wert vorzuinitialisieren...
> 2) globale hilfsvariablen um die schaufelarbeiten zu erledigen scheiden
> ebenfalls aus, da man sich diese evtl. beim überladen der .data section
> oder der .bss section mittendrin plättet...

Genau deshalb wird StartUp-Code in Assembler geschrieben. Ob es sich 
dabei formal um einen IRQ-Vektor kandelt oder nicht spielt dabei 
eigentlich keine Rolle.

> ...erste lösung, man bittet den compiler register zu nutzen...
>
> schaut man sich nun das compilat an stellt man bei keiner optimierung
> zunächst einen lästigen epilog von pushs unsd pops... und ein reges
> nutzen des stacks.

Klar. Ohne Optimierung leben autos in Frame der Funktion.

> einen grossteil des epilogs nimmt einem das attribut interrupt ab (zu
> einem solchen handlertyp gehört der reset handler schliesslich auch)
> die restlichen epilog bestandteile eliminiert das attribut naked...
>
> aber: der funktionsrumpf hat nach wie vor stacknutzung, volle ignoranz
> gegenüber der bitte um register (3 an der zahl wurden angefordert..
>
> erst mit der optimierungsstufe 1 produzierte er einen startupcode als
> wäre er handgeschrieben...
>
> deswegen dediziert diese funktion mit dieser stufe...

StartUp code in ein eigenes Objekt? Wird man eh in unterschiedlichen 
Applikationen hinzulinken wollen. .data et al. liefert wie gesagt der 
Linker (bzw. ld-Script).

> viel interessanter wäre, in wie weit sich dieser output mit einer
> anderen (evtl. zukünftigen) gcc version verändert. ob er dann immernoch
> brav bei reigstern bleibt, ohne sich des stacks/ram zu bedienen?

Nimm Assembler. GCC ist Herr der Register. Es ist nicht garantiert, ob 
er ein Register verwendet oder nicht oder in Zukunft das gleiche 
Verhalten zeigt oder nicht. In einem eigenen o-Modul hast du nach 
Inspektion des Codes zumindest sicher, daß er korrekt ist. Wenn du ihn 
hingegen immer mit deiner Applikation übersetzt und irgendwann mal .data 
nicht komplett kopiert wird oder .bss nicht komplett genullt wird, 
suchst du dir in deiner Anwendung den Wolf.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jörg:
>"register" und "auto" sind heutzutage überflüssige Schlüsselworte.

ok, das war neu für mich

>Und warum nicht alles optimiert?

meistens unterscheidet sich bei mir eine version"debug" und eine version 
"release" nur in der verwendung allgemeiner optimierungseinstellungen...

>Nun, wenn das nicht mehr in Register passt, muss er so oder so auf
den Stack ausweichen.

klar, aber bei dieser funktion bleibt es bei 3 registern (sofern das der 
compiler dann auch noch erkennen kann :D)

>Use at your own risk. ;-)

klar, aber es handelt sich ja um startupcode, da würde nur der 
resetzustand verloren gehen :D

johann:
>Genau deshalb wird StartUp-Code in Assembler geschrieben. Ob es sich
dabei formal um einen IRQ-Vektor kandelt oder nicht spielt dabei
eigentlich keine Rolle.

ich werde auch weiterhin asm-startups nutzen, aber mit deiner aussage 
bin ich nicht ganz einverstanden. der cortex bietet eigentlich im 
gegensatz zu den anderen eine ECHTE vektortabelle un der KEIN 
funktionaler code steht, sondern eine nackte adresse...

>StartUp code in ein eigenes Objekt?

sicher, aber damit nehme ich mir die möglichkeit die NVIC-API, die evtl 
wieder der globalen optimierung unterliegen soll, in das gleiche objekt 
zu packen... (ob sinnvoll oder nicht, wie gesagt, es war mir nur ne 
übung mit hypothetischen betrachtungen, aber jetzt gerade kann ich ja 
von euch lernen)

>Nimm Assembler. GCC ist Herr der Register. Es ist nicht garantiert, ob
er ein Register verwendet oder nicht oder in Zukunft das gleiche
Verhalten zeigt oder nicht. In einem eigenen o-Modul hast du nach
Inspektion des Codes zumindest sicher, daß er korrekt ist. Wenn du ihn
hingegen immer mit deiner Applikation übersetzt und irgendwann mal .data
nicht komplett kopiert wird oder .bss nicht komplett genullt wird,
suchst du dir in deiner Anwendung den Wolf.

dh.: schreiben, verifizieren, und als bibliothek nutzen,ok. mit dem 
nachteil, das ich mir die möglichkeit nehme iwann mal eine individuelle 
setion, die geladen werden müsste, zu erstellen...
verstehe...



Ich danke für eure anregungen, hinweise und die aufklärung
das hat den wert meiner übung bei weitem gesteigert

vielen dank an dieser stelle

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> johann:
>> Genau deshalb wird StartUp-Code in Assembler geschrieben. Ob es sich
>> dabei formal um einen IRQ-Vektor kandelt oder nicht spielt dabei
>> eigentlich keine Rolle.
>
> ich werde auch weiterhin asm-startups nutzen, aber mit deiner aussage
> bin ich nicht ganz einverstanden. der cortex bietet eigentlich im
> gegensatz zu den anderen eine ECHTE vektortabelle un der KEIN
> funktionaler code steht, sondern eine nackte adresse...

Und? Knackpunkt ist doch, daß zur Verwendung von C bestimmte Dinge 
initialisiert sein müssen: Stck(pointer), .data, .bss, oder was auch 
immer. Das stellt dir doch NVIC oder was auch immer zur Verfügung.

>> Nimm Assembler. GCC ist Herr der Register. Es ist nicht garantiert, ob
>> er ein Register verwendet oder nicht oder in Zukunft das gleiche
>> Verhalten zeigt oder nicht. In einem eigenen o-Modul hast du nach
>> Inspektion des Codes zumindest sicher, daß er korrekt ist. Wenn du ihn
>> hingegen immer mit deiner Applikation übersetzt und irgendwann mal .data
>> nicht komplett kopiert wird oder .bss nicht komplett genullt wird,
>> suchst du dir in deiner Anwendung den Wolf.
>
> dh.: schreiben, verifizieren, und als bibliothek nutzen,ok. mit dem
> nachteil, das ich mir die möglichkeit nehme iwann mal eine individuelle
> setion, die geladen werden müsste, zu erstellen...
> verstehe...

Wenn, dann kannst du die entsprechende Input-Section per ld-Script auf 
Output-Section .data abbilden. Falls die .foo-Section hingegen ein 
eigenes Handling braucht, muss eben Code dazu, d.h. ein o-File 
referenziert den init-Code aus _init_foo und der Linker linkt das 
entsprechende Object dazu. Dazu braucht's nur einen kleinen Patch in gcc 
;-) der, wenn Code nach .foo geht, ein Object _init_foo referenziert. 
Wenn _init_foo nicht gebraucht wird, dann wird eben nicht dagegen 
gelinkt (bzw. der Linker braucht das Symbol nicht aufzulösen) und es 
gibt keinen überflüssigen Code.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und? Knackpunkt ist doch, daß zur Verwendung von C bestimmte Dinge
>initialisiert sein müssen: Stck(pointer), .data, .bss, oder was auch
>immer. Das stellt dir doch NVIC oder was auch immer zur Verfügung.

ich glaube wir reden an einander vorbei... oder ich habe noch immer 
nicht geschnallt was du da sagst:

knackpunkt ist, das ich die funktionalität, die meine umgebung für die 
verwendung von c schafft, bereits in c schreibe, den stackpointer kann 
man hier nicht ohne weiteres mit reinem c ohne inline asm referenzieren. 
das macht der nvic. sonst kenne ich keinen controller der dies vermag. 
UND er verlangt lediglich die vektoren mit referenzen zu belegen, was 
einer abbildung in reinem c ebenfalls entgegenkommt( andere haben in den 
vektoren  einen branch stehen, dem man sich in c "ohne inline asm" 
erstmal ausgeliefert sieht...

deswegen machen die cortex jungs ja die werbung, komplett auf asm 
verzichten zu können. (zumindest müsste der comiler zumindest einige 
intrinsics unterstützen zB für den msr befehl...)

ich werde asembler weiterhin nutzen, wie gesagt, war nur ne übung :)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. wrote:

> Knackpunkt ist doch, daß zur Verwendung von C bestimmte Dinge
> initialisiert sein müssen: Stck(pointer), .data, .bss, oder was auch
> immer. Das stellt dir doch NVIC oder was auch immer zur Verfügung.

Soll natürlich heissen: ...stellt dir NVIC nicht zur Verfügung.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wrote:
> 2) globale hilfsvariablen um die schaufelarbeiten zu erledigen scheiden
> ebenfalls aus, da man sich diese evtl. beim überladen der .data section
> oder der .bss section mittendrin plättet...

Was ist dagegen zu sagen, wenn Du sicherstellst (static), dass niemand
die Variablen später verwendet?

> schaut man sich nun das compilat an stellt man bei keiner optimierung
> zunächst einen lästigen epilog von pushs unsd pops... und ein reges
> nutzen des stacks.

Der GCC generiert hier noch einen frame pointer. Mit
-fomit-frame-pointer sieht das schon anders aus, der Stack wird
allerdings immernoch genutzt. Schadet aber eigentlich auch nicht, wir
haben ja einen Stack. Für Spezialfälle musst Du eben mal auf Assembler
ausweichen. Wird ja nicht so schwer sein, eine Schleife zu
implementieren, die den Stack mit einem Pattern füllt und danach den
in C geschriebenen Rest des Reset Handlers auszuführen.

Ich teile nicht die Meinung, dass man Reset Handler grundsätzlich in
Assembler programmieren muss.

> einen grossteil des epilogs nimmt einem das attribut interrupt ab (zu
> einem solchen handlertyp gehört der reset handler schliesslich auch)

Seit wann ist denn Reset ein Interrupt Handler? Im Übrigen gibt es
beim ist beim Cortex-M3 eben keinen Unterschied zwischen Interrupt
(bzw. Exception Handler) und normaler Funktion. Zumindest, wenn das
automatische Stack Alignment aktiviert wurde.

> aber: der funktionsrumpf hat nach wie vor stacknutzung, volle ignoranz
> gegenüber der bitte um register (3 an der zahl wurden angefordert..
> erst mit der optimierungsstufe 1 produzierte er einen startupcode als
> wäre er handgeschrieben...

Wenn Du das möchtest/musst, dann kannst Du diesen Teil des startup
codes doch gleich per Hand schreiben (s.o.).

> deswegen dediziert diese funktion mit dieser stufe...

Aber auch hier kannst Du Dich nicht darauf verlassen, was für
Optimierungen der Compiler im einzelnen durchführt. Das Festnageln der
Optimierungsstufe ist daher keine sichere Lösung.


Gruß
Marcus
http://www.doulos.com/arm/

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uiuiui, markus, was soll ich sagen..

...wer lesen kann ist klar im vorteil?

...aber das ist ja nicht alles, neben dem gefühl das du nicht verstanden 
hast, worum es mir ging postest du zum teil sogar dinge, die schlichtweg 
falsch sind...

lies der den ganzen thread nochmal in ruhe durch... um dir die chance zu 
geben es selbst zu erkennen...

kleine beispiele:
>Was ist dagegen zu sagen, wenn Du sicherstellst (static), dass niemand
>die Variablen später verwendet?

1) dagegen gesagt wurde hier grundsätzlich nichts (richtig lesen worum 
es ging)
2)gerade eine static, A U T S C H, das ist die erste, die ich mir 
während der ausführung, die .data bzw. .bss section zu initialisieren 
mitten im kontext versemmeln würde...
3) sicherstellen, das diese nur im startup zum einsatzkommt ist unschön, 
ausserdem nicht weit genug gedacht, denn nach der startupprozedur dürfen 
deren temporären daten durchaus föllig frei überschrieben werden... (wir 
sind hier in einem bereich, in dem man die für c benötigte umgebung erst 
aufbaut, allerdings das auch schon mit c...)

>die den Stack mit einem Pattern füllt und danach den

geht ohne 10x schöner, das pattern brauchen wir hier noch nicht...

>Ich teile nicht die Meinung, dass man Reset Handler grundsätzlich in
>Assembler programmieren muss.

ich habe nirgends eine meinungsäusserung vernommen

>Seit wann ist denn Reset ein Interrupt Handler?

er ist ein event, der passiert, hat auf jeder maschine die ich kenne 
einen festen vector, und einige komplexere controller haben für ihn 
sogar ein statusregister, indem widergespiegelt wird, was denn den reset 
auslöste (power-up, brown-out, watchdog...). -->eindeutige 
verwandschaft... eigentlich grade in deiner firma dürfte es doch 
auffällig sein, das manche hersteller teilweiseinteressante 
beschreibungen dazu veröffentlichen... meist übergeht man diese nur, 
weil klar ist " haja, den schaltet man an, un dann rennt er da un da 
los.."... steckt meist mehr dahinter

>Im Übrigen gibt es
>beim ist beim Cortex-M3 eben keinen Unterschied zwischen Interrupt
>(bzw. Exception Handler) und normaler Funktion.

das ist der absolute knüller :D
...lass ich mal so stehn, er wird es fressen, aber ohne auf die in der 
hardware gelöste kontextbehandlung einzugehen, die pragmatisch 8(!) 
register wegsichert, verspielst du je nach funktion die 
geschwindigkeitsvorzüge der NVIC... speziell beim gcc und cortex macht 
__atribute__((interrupt)) sinn.. teste es!

>Wenn Du das möchtest/musst, dann kannst Du diesen Teil des startup
>codes doch gleich per Hand schreiben (s.o.).

...es war nachwie vor die übung es in c zu schreiben...

bist du der, der die schulungen/trainings hält bei euch??? gräul

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hoppla! Schlechten Tag gehabt?

... wrote:
> 2)gerade eine static, A U T S C H, das ist die erste, die ich mir
> während der ausführung, die .data bzw. .bss section zu initialisieren
> mitten im kontext versemmeln würde...

Klar. Aber die brauchst Du ja hinterher auch nicht mehr. Wie Du sagst:
eine Hilfsvariable. Damit nicht versehentlich jemand anderes von
außerhalb drauf zugreift, wird sie eben static deklariert. Die
Variable kann durchaus auf eine bestimmte Adresse festgenagelt werden,
die hinterher für den Stack verwendet wird. Dann verschwendest Du
nicht mal was. Du könntest sogar direkt eine beliebige RAM Adresse als
Hilfsvariable verwenden. Sieht natürlich beschissen aus, funktioniert
aber.

Aber wie gesagt, derartige Anwendungen sind oft einfacher in ASM.

> 3) sicherstellen, das diese nur im startup zum einsatzkommt ist unschön,
> ausserdem nicht weit genug gedacht, denn nach der startupprozedur dürfen
> deren temporären daten durchaus föllig frei überschrieben werden... (wir
> sind hier in einem bereich, in dem man die für c benötigte umgebung erst
> aufbaut, allerdings das auch schon mit c...)
>
>>die den Stack mit einem Pattern füllt und danach den
>
> geht ohne 10x schöner, das pattern brauchen wir hier noch nicht...

Ich dachte, "da man manchmal nicht darauf verzichten will die stack
mit einem wert vorzuinitialisieren". Aber wenn Du das nicht brauchst,
warum dann die Sorge um den Stack? Er ist da, verwende ihn.

>>Ich teile nicht die Meinung, dass man Reset Handler grundsätzlich in
>>Assembler programmieren muss.
>
> ich habe nirgends eine meinungsäusserung vernommen

Ich sagte ja auch nicht "Deine Meinung", sondern "die Meinung". Es
wurde auch in diesem Thread die Meinung vertreten, dass man Startup
Code/Reset Handler "genau deshalb" in Assembler schreibt. Für mich ist
das keine alles-oder-nichts Geschichte.

>>Seit wann ist denn Reset ein Interrupt Handler?
>
> er ist ein event, der passiert, hat auf jeder maschine die ich kenne
> einen festen vector, und einige komplexere controller haben für ihn
> sogar ein statusregister, indem widergespiegelt wird, was denn den reset
> auslöste (power-up, brown-out, watchdog...). -->eindeutige
> verwandschaft...

In der Tat. Allerdings braucht sich ein Reset Handler nicht um den
Kontext zu kümmern. Im Gegensatz zum Interrupt Handler interessiert
beim Reset das Stack Alignment nicht. Wenn man den Reset Handler als
Interrupt deklariert, dann ist GCC offensichtlich geneigt, diesen
zusätzlichen Code zu generieren. Bevor die Datensegmente angelegt
werden kann man im Reset Handler zudem beliebigen Speicher verwenden,
da man sich (in den meisten Fällen) keinen Kopf um irgendwelche Daten
machen muss.

> eigentlich grade in deiner firma dürfte es doch auffällig sein, das
> manche hersteller teilweiseinteressante beschreibungen dazu
> veröffentlichen...

Klar. Die meisten dieser Hersteller sind unsere Kunden.

>>Im Übrigen gibt es beim ist beim Cortex-M3 eben keinen Unterschied
>>zwischen Interrupt (bzw. Exception Handler) und normaler Funktion.

Interrupt Handler und normaler Funktion. Falsche Klammerung -- mein
Fehler.

> ...lass ich mal so stehn, er wird es fressen, aber ohne auf die in der
> hardware gelöste kontextbehandlung einzugehen, die pragmatisch 8(!)
> register wegsichert,

Der NVIC muss diese Register sichern, um dem Exception Handler einen
Kontext zu geben, der sich nicht von dem eines normalen
Funktionsaufrufs unterscheidet (siehe AAPCS).

> verspielst du je nach funktion die geschwindigkeitsvorzüge der
> NVIC... speziell beim gcc und cortex macht __atribute__((interrupt))
> sinn.. teste es!

Der Unterschied ist lediglich, dass GCC (Sourcery G++ Lite 2008q3-66)
(unnötigerweise) für das Stack Alignment sorgt. Andere Compiler können
das besser. Beim RealView Compiler wird beispielsweise das "__irq"
ignoriert, wenn man für Cortex-M3 übersetzt (es sei denn, man möchte
code für einen Cortex-M3-r0 Kern erzeugen).

> bist du der, der die schulungen/trainings hält bei euch??? *gräul*

Ich hoffe Du kannst heute Nacht trotzdem gut schlafen.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
war ein fehlgriff, ja, wollte nicht angreifend werden... sorry

ich denke ich habe begriffen was du sagst..

hast du einen link zu der aapcs? da scheine ich offensichtlich was nicht 
richtig verstanden zu haben...

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wrote:
> hast du einen link zu der aapcs? da scheine ich offensichtlich was nicht
> richtig verstanden zu haben...

Ja. Hier als PDF Datei

http://infocenter.arm.com/help/topic/com.arm.doc.i...

Viel Spaß beim Lesen.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ahhhhh

das suchte ich schon lange, aber offensichtlich an falscher stelle....
das ist sehr hilfreich, wenn man manche funktionen lieber von hand 
schreibt...

vielen dank

kann ich denn aber getrost davon ausgehen, das jeder compiler, der arm 
unterstützt sich auch an diese vorgaben hält?

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wrote:
> kann ich denn aber getrost davon ausgehen, das jeder compiler, der arm
> unterstützt sich auch an diese vorgaben hält?

Ja. Versteckt sich meist hinter der Bezeichnung "ABI compliant", oder 
"EABI compliant". AAPCS ist ein Teil des Application Binary Interface.

Das ist wichtig, damit Funktionen in fremden Objektdateien von Deinem 
Code aufgerufen werden können und umgekehrt. Gilt natürlich auch 
innerhalb des eigenen Codes. GCC ist schon seit langer Zeit ABI 
compliant.

Wenn Du GCC verwendest, würde ich Dir auf jeden Fall den von 
CodeSourcery empfehlen. Deren Erweiterungen in Richtung ARM finden erst 
später Eingang in den "normalen" GCC.

Gruß
Marcus
http://www.doulos.com/arm/

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab mir rowley angeschafft...
evtl. kann ich in den die bins und libs von codesourcery überladen...

stimmt es, das die codesourcery jungs direkt von arm unterstützt werden?
wenn ja, währe man ja doof codesourcery nicht zu nutzen...

andererseits bin ich mit dem, was rowley umgesetzt hat für meine 
bedürfnisse überaus zufrieden...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Objektformat sollte passen. Ich weiss nicht was Rowley verwendet, aber 
Codesourcery und WinARM/GNUARM sind da jedenfalls verschiedener Ansicht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.