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
5.52.12 Function Specific Option Pragmas: http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html#Function-Specific-Option-Pragmas
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>.
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?
D A N K E vergessen :) dankedankedankedankedankedankedankedankedankedanke
... 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. ;-)
> 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.
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
> 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.
>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 :)
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.
... 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/
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
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/
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...
... 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.ihi0042c/index.html Viel Spaß beim Lesen. Gruß Marcus http://www.doulos.com/arm/
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?
... 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/
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...
Objektformat sollte passen. Ich weiss nicht was Rowley verwendet, aber Codesourcery und WinARM/GNUARM sind da jedenfalls verschiedener Ansicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.