Assembler statt C code in start up routinen

hansi schrieb:
> Ich Frage mich nun, wieso solche Dateien, oft als Assembler code
> geschrieben werden und nicht in c.

Die Antwort hast du doch oben schon selbst gegeben, daher meine Frage an 
dich: Macht es Sinn etwas in C zu implementieren bevor die C-Runtime, 
respektive der Stack initialisiert sind?

hansi schrieb:
> wann muss ich explizit auf Assembler zurückgreifen und wann nicht?

in dem o.g. Fall auf jeden Fall nicht.

Assembler nur wenn die Anwendung auf den Takt genau zeitkritisch ist, 
oder wenn der Controller bis zu letzt ausnutzt werden soll.

Für alle Anwendungen mit einer Stückzahl kleiner 10 nimmt man einfach 
den nächst größeren Controller und kann dann wieder normal in C 
programmieren.


Axel

Düsendieb schrieb:
> Assembler nur wenn die Anwendung auf den Takt genau zeitkritisch ist,
> oder wenn der Controller bis zu letzt ausnutzt werden soll.

Antwort passt leider nicht zur Frage (nochmal genau lesen).

Es gibt verschiedene Gründe:

1. Assembler ist einfach gängiger und schafft optimierten Code.
2. Du erwähnst ja schon, dass beispielsweise der Stack initialisiert 
wird. Wenn noch kein Stack vorhanden ist, kannst du keine C-Funktionen 
verwenden, da die Parameterübergabe als auch die Rücksprungadresse im 
Stack abgelegt werden bzw. auf den Stack zugreifen.
3. Oft benötigst du spezielle (Assembler)Befehle des Prozessors um z.B. 
Mode-Switches durchzuführen. Das wäre dann inline-Assembler, also warum 
nicht gleich in Assembler.

Es gibt auch Controller bzw. Compilerfamilien, die einen zweistufigen 
Startup-Code nutzen. Das heißt ganz grundlegende Initialisierungen 
werden mit einem Assembler-Modul realisiert und etwas aufwendigere mit 
einem C-Startup-Code Beispielsweise für Variableninitialisierung. IAR 
EWARM ist ein Beispiel.

m.E. nach legt die tool chain, also die linker settings (?), den bereich 
im memory fest, wo der stack liegen soll oder? mit initialisieren meinte 
ich eher pattern reinschreiben. ok war ein dummes beispiel. also im 
konkreten fall wird folgendes gemacht:
-clk settings werden gesetzt
-clk stabilisierungs zeit wird gesetzt
-boot table erstellt

etc..

ich mein im endeffekt werden hier nur system register beschrieben. das 
geht doch auch in c odeR?

Loonix schrieb:
> Antwort passt leider nicht zur Frage (nochmal genau lesen).

Die Antwort stand darüber: >in dem o.g. Fall auf jeden Fall nicht

Der Rest war als Zusatzinfo gedacht.


Axel

hansi schrieb:
> ich mein im endeffekt werden hier nur system register beschrieben. das
> geht doch auch in c odeR?

Das musste in der Regel bei C Programmierung gar nicht selber machen, da 
hat schon der Conpiler dran gedacht.

ne eben nicht, das steht ja in meinen start configuration file. gerade 
was die clock settings angeht. denke mal low level hat mit punkt 1 und 3 
schon recht. es ginge in c wäre aber unpassend?!

punkt 2, verstehe ich noch nicht ganz, da ich dachte das der linker 
weiss wo stack liegt und wie groß er ist und eben diesen auch 
verwaltet....

ah ok, also prinzipiell wäre es aber möglich (kein optimierung, etc..)?

hansi schrieb:
> ah ok, also prinzipiell wäre es aber möglich (kein optimierung, etc..)?

Jein. Solange das C-Environment nicht steht, kannst du C nicht oder nur 
eingeschränkt verwenden. Und alles, was man vor der Erstellung des 
C-Environments ausführen MUSS, geht halt nur in Assembler.

Ob dazu jetzt auch die Einstellung des Taktes oder andere Einstellungen 
am Prozessor selber gehört, hängt von dessen Architektur ab. Bei vielen 
kann man solche Dinge auch am Anfang von main in C machen.

Oliver

Oliver schrieb:
> Jein. Solange das C-Environment nicht steht, kannst du C nicht oder nur
> eingeschränkt verwenden. Und alles, was man vor der Erstellung des
> C-Environments ausführen MUSS, geht halt nur in Assembler.

was genau meinst du mit c environment? was gehört alles dazu?

hansi schrieb:
> was genau meinst du mit c environment? was gehört alles dazu?

es düfte schon an Variablen scheitern. Denn die Variabeln liegen 
normlerweise auf dem Stack und der ist ja noch nicht da.

Also du kannst C verwenden nur ohne Funktionen und Variablen.

Peter schrieb:
> Also du kannst C verwenden nur ohne Funktionen und Variablen.

So ist es.

Die Ausgangsfrage klingt allerdings nach ARM7. Da kannst du im Prinzip 
sofort nach der Stack-Initilisierung eingeschränkt in C loslegen, eben 
mit der Einschränkung, daß noch keinerlei Variablen initilaisiert sind. 
So etwas wie

REGISTER_XY = 0x42;

geht allerdings schon. Takteinstellungen und ähnliches kann man machen, 
wann man will, auch am Anfang von main in C, oder noch viele später.

Oliver

Ich würde mal sagen 100% aller Anfängerprogramme und 80% oder mehr der 
Profianwendungen lassen sich locker in C Programmieren.

Assembler wird hier oft nur wegen des (zweifelhaften) Lerneffekts 
empfohlen

hansi schrieb:
> was genau meinst du mit c environment? was gehört alles dazu?

Initialisierung des Stack
Initialisierung des Heap (falls das Programm malloc/free verwendet)
Initialisierung globaler Variablen

Diese Reihenfolge ist sinnvoll, wenn außer C- auch C++-Programme zur 
Ausführung kommen können, dann braucht man nämlich einen 
funktionstüchtigen Stack (und ggfs. Heap), um globale Objekte zu 
konstruieren.

Werden nur C-Programme unterstützt, dann kann man auch die Variablen 
zuerst erledigen.

Die Einstellung von Hardware-Registern hat hiermit in der Regel (*) 
nichts zu tun und kann prinzipiell gleichermaßen vor oder nach der 
C-Initialisierung geschehen.

(*) Ausnahmen gibt es natürlich, z.B. Setzen des Stackpointers. Oder 
wenn man externen Speicher hat (Heap für größere Datenmengen im externen 
RAM), muss man natürlich, bevor man die C-Runtime den Heap 
initialisieren lässt, den XMem-Controller an den Start bringen. Aber 
selbst das könnte man als primitive C-Routine formulieren und vom 
Assembler-Startupcode aufrufen lassen.

Düsendieb schrieb:
> Ich würde mal sagen 100% aller Anfängerprogramme und 80% oder mehr der
> Profianwendungen lassen sich locker in C Programmieren.

Thema verfehlt...

Oiver

> ah ok, also prinzipiell wäre es aber möglich (kein optimierung, etc..)?

Sowas ist moeglich und wird auch durchaus so gemacht.
Allerdings bedarf es unter Umstaenden eines erfahreren C-Programmierer
der mit dem Compiler und Linker gut umgehen kann.

Denn wie schon angedeutet wurde, es sind ein paar Dinge zu beachten:

1. Der Stack muss gesetzt werden.

2. Andere Register muessen eventuell gesetzt werden.
   Ein Beispiel dafuer waeren bei M16C das einstellen der 
Gehaeusegroesse.

3. Die Reihenfolge kann wichtig sein. Auch optimierungslevel des 
Compilers.

4. Die Position im Speicher der Prozessors kann wichtig sein.

5. Es muessen Variable vom Linkerscript oder der Programmierumgebung
   an das C-File uebergeben werden. (z.B Position und groesse des 
Stacks)

6. Man verschenkt beim Aufruf von main() eine Stackposition oder muss
   sich halt einen Sprung einfallen lassen.

> In C wird eines dieser Register als Zähl-Index, ein anderes zur
> Adressierung benutzt. Sowie du das erste dieser beiden Register in
> deiner Schleife überschreibst, beisst sich die Katze in den Schwanz.
>
> Deswegen geht das nur in Assembler.

Nein. Setze einfach als erstes den Stack und verwende dann Variable die 
nur auf dem Stack liegen. Es geht also durchaus in C, allerdings muss 
man trotzdem wie ein Assemblerprogrammierer denken, sich also darueber 
im klaren sein was der Compiler jetzt daraus macht.

Es geht aber noch perverser. :-) So sieht das ganze z.B bei
Renesas aus:

void start(void)
{
  set_cpu();  // initialize mcu

  ram_init();
}

Also ein C-funktion die ihrerseits wieder andere Funktionen aufruft
und zwar ohne das es bis jetzt schon einen Stack gibt.

Und so sieht dann set_cpu aus:

#pragma inline set_cpu()
void set_cpu(void)
{
   isp  = &_istack_top;      // set interrupt stack pointer
  flg  = 0x0080UL;        // set flag register
  sp  = &_stack_top;      // set user stack pointer
  sb  = (_UDWORD *)0x400UL;  // 400H fixation (Do not change)
  _asm("  fset  b");
  sb  = (_UDWORD *)0x400UL;
  _asm("  fclr  b");
  intb = (_UDWORD *)VECTOR_ADR;  // set variable vector's address
}

Das sieht man wieso man erst ohne Stack auskommt. Ausserdem wird 
lustigerweise erstmal doch wieder Assembler benutzt auch wenn es im 
C-Code steht. Ein Problem koennte vielleicht sein das ein anderer 
Compiler
soetwas...

   isp  = &_istack_top;      // set interrupt stack pointer

...uebersetzt indem er einen Zwischenwert auf den Stack speichert.


Olaf

hansi schrieb:
> wann muss ich explizit auf Assembler zurückgreifen und wann nicht?

Das war die Ausgangsfrage.
und ich meine immer noch, wenn man sauber in C programmiert braucht man 
nur aller seltenst auf Assembler zurückgreifen.


Axel

Düsendieb schrieb:
> Das war die Ausgangsfrage.

nein war sie nicht. Es ging im C in start up routinen. Also dem teil vor 
Main. Und mit diesen haben 100% aller Anfängerprogramme überhaupt nicht 
zu tun.

Peter schrieb:
> Und mit diesen haben 100% aller Anfängerprogramme überhaupt nicht
> zu tun.

genau, weil das der Compiler von alleine erledigt

Düsendieb schrieb:
> genau, weil das der Compiler von alleine erledigt

Eben nicht. Der Compiler erledigt von den Dingen, um die es hier geht, 
überhaupt nichts. Der weiß noch nicht einmal was davon. Für einen 
C-Compiler gibt überhaupt kein Leben vor main(), wohl aber für die 
Hardware.

Alles davor macht der Startupcode, der entweder (für den Anfänger 
versteckt) in der toolchain mitgeliefert und in den ebenfalls 
mitgelieferten linkerscripts berücksichtigt wird, oder eben vom Benutzer 
unabhängig vom Compiler erstellt werden muß.

Oliver

Oliver schrieb:
> (für den Anfänger versteckt)

sag ich doch

Assembler ist halt besser als jeder compiler, weil er direct auf 
hardware zugreift.Compiler übersetzt nur in den assembler, und das tut 
er nicht so gut.Eigentlich hängt das von dem compiler ab, was für den 
code er dann erschaft.Auf jeden Fal ist das nicht so effizient wie 
assembler, das is so als ob du durch einen übersetzer mit jemandem 
sprichst.

Programist schrieb:
> Assembler ist halt besser als jeder compiler, weil er direct auf
> hardware zugreift.Compiler übersetzt nur in den assembler, und das tut
> er nicht so gut.Eigentlich hängt das von dem compiler ab, was für den
> code er dann erschaft.Auf jeden Fal ist das nicht so effizient wie
> assembler, das is so als ob du durch einen übersetzer mit jemandem
> sprichst.

Alter, bist du ein spacko...

Hallo,

mal eine Frage zu dem Thema... ich habe in ARM7 startup-Routinen schon 
handgeschriebene memcopy Funktionen gesehen, die nur einen 
Speicherbereich mit 0x00, oder sonstigen "Mustern" beschrieben haben zur 
Initialisierung oder Stackverbrauchbestimmung.

Wäre das nicht auch in C vor Runtime-Init programmierbar, solange ich 
keinen Stack verwende und alle Variablen vollständig in den 
Prozessorregistern halten kann?

Gruß

Benni

Benni schrieb:
> solange ich
> keinen Stack verwende und alle Variablen vollständig in den
> Prozessorregistern halten kann?

und wie willst du das machen? (aber bitte ohne irgendwelche C 
erweiterungen)

Naja klar, ohne C pragma oder sonstwas wird da nix laufen, aber im 
Embedded Bereich gehts doch sowieso fast nicht ohne ;)

Ich mein viel hardwarespezifischer kanns ja nichtmehr werden. Ich finde 
nur es wäre leichter zu lesen und überblicken, als eigentlich simple 
Speicherzuweisungen nach Assembler zu packen.

Benni

Benni schrieb:
> ch finde
> nur es wäre leichter zu lesen und überblicken, als eigentlich simple
> Speicherzuweisungen nach Assembler zu packen.

was ist an ASM nicht einfach zu lesen, immer schöne kurze zeilen. Es mir 
lieber als der C code den man hier manchmal sieht.

>> genau, weil das der Compiler von alleine erledigt...

So ist es.

Komische Diskussion, jeder brauchbare C Compiler generiert den 
entsprechenden Startup Code und biete darüber hinaus auch eine 
Möglichkeit diesen zu beeinflußen. Alles andere wäre eine Krücke.

Düsendieb schrieb:
> Oliver schrieb:
>> (für den Anfänger versteckt)
>
> sag ich doch

Hier geht es anscheinend um einen ARM, und in dessen toolschains ist das 
schon nicht mehr versteckt, auch nicht für Anfänger. Da kannst (und 
musst) du als Anwender sowohl im startupcode, als auch in den 
linkerscripts selber rumbasteln. Es gibt dazu zwar Beispiele, aber mehr 
nicht.

Und was z.B. auf deinem PC alles passiert, bevor da mal ein main() eines 
von dir geschriebenen Programms loslaufen kann, kannst du ja mal 
versuchen, rauszufinden. Angefangen vom ersten Start des Bios. Viel 
Spaß...

Die Welt besteht nicht nur aus AVR's.

Oliver

ok, ARM kann ich nicht mitreden und ob Compiler oder IDE, Toolchain, 
aknn man natürlich drüber streiten.

Jedenfalls können es die Toolchains mit denen ich arbeite und jede 
bietet die Möglichkeit:
- den StartupCode zu generieren
- den StartupCode zu modifizieren
- den StartupCode zu unterdrücken, respektive selbst zu schreiben

Gibts nen link zu dem Armen ? :-)

900ss D. schrieb:
> Einen Cortex-M3 kann man in reinem(!) C starten.

Das stimmt. Der CM3-Kern beginnt bei Adresse 0x00000000 und lädt das 
32-Bit-Wort, das er dort findet, in den Stack-Pointer. Damit ist der 
Stack initialisiert.

900ss D. schrieb:
> Und die erste Funktion die dort
> anläuft ist main(), kein Assemblerbefehl vorher! Dort kann man auf den
> Startupcode in Assembler vollständig verzichten.

Das zweite Wort (ab Adresse 0x00000004) wird in den Instruction-Pointer 
geladen. Das kann theoretisch die Adresse von main () sein. In der 
Regel wirds aber ein paar Variablen zu initialisieren geben, und das 
muss laut C-Standard vor dem Eintritt in main erledigt sein. Es wird 
also wahrscheinlich etwas Startup-Code zwischen Reset und main geben 
müssen.

Du hast aber Recht damit, dass dieser STartupcode nicht in Assembler 
geschrieben sein muss.

OK danke für die zahlreichen antworten. ich denke da sind ein paar gute 
dabei und es ist auch etwas klarer geworden.

was ich aber nicht ganz verstehe ist, wieso der stack explizit in 
assembler initialisiert werden muss.

Stack ist ein bereich im RAM. der linker erstellt doch eine memory map. 
vorher habe ich zB in den settings festgelegt, das addresse 0xabc - 
0xaff im RAM liegen und als stack benutzt werden können. die MCU selbst 
braucht doch nur die start address für den stack pointer 0xaff. nun kann 
die mcu fröhlich pushen und poppen. was genau muss ich da in einer start 
up festlegen? immerhin künmmert sich doch der linker um solche sachen?? 
er legt ja auch das ROM fest für meinen programm code.

danke

p.s. es war kein ARM gemeint :) nehmen wir es eher als allgemein gültige 
frage. wobei der M3 ja zB dann rausfällt wie oben beschrieben.

hansi schrieb:
> was ich aber nicht ganz verstehe ist, wieso der stack explizit in
> assembler initialisiert werden muss.
> ...
> die MCU selbst
> braucht doch nur die start address für den stack pointer 0xaff.

Und wie kommt die Adresse in das Stackpointer-Register hinein? Genau: 
Durch irgendwas wie

        load sp, 0xaff

Normalerweise hast du in C keinen direkten Zugriff auf den Stackpointer. 
Du müsstest Inline-Assembler verwenden, und du müsstest die Funktion so 
kompilieren, dass Vor- und Nachspann den Stackpointer nicht verbiegen 
("attribute naked" oder was es da bei deinem Compiler so für 
Spezialitäten gibt). Auf jeden Fall ist das ein viel größerer Aufriss 
als eine simple Anweisung direkt im Startupcode.

also besteht das "einrichten" des stacks eingentlich nur aus dem setzten 
des stack pointers?

hansi schrieb:
> also besteht das "einrichten" des stacks eingentlich nur aus dem setzten
> des stack pointers?

Ja. Manchmal wird noch der ganze Stack mit einem Bitmuster vorbelegt, 
was es zur Laufzeit ermöglicht, den "Hochwasserpegel" zu bestimmen oder 
Überläufe zu erkennen.

Aber für die Funktion des Stacks an sich reicht das Setzen des Pointers. 
Und wie Jörg Wunsch schrieb: Manche CPUs brauchen nicht mal das.