mikrocontroller.net

Forum: Compiler & IDEs Auswirkung unterschiedlicher Architektur


Autor: Array D. (array94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebes Forum,

Erstmal danke, dass ich hier meinen ersten Beitrag(Frage) verfassen 
darf.

Nehmen wir mal die ARM-Reihe. Was verändert sich für mich als C-Anfänger 
wenn ich eine andere Architektur verwende? Schließlich programmiere ich 
ja nicht in Assembler. Den Code den ich eingebe ist der Selbe, egal ob 
load/store Architektur oder nicht?
Ist in diesem Fall eigentlich nur der Compiler betroffen?

Mein Dozent meinte letztens,dass der neue Cortex R4 Atomare Befehle 
unterstützt. Deswegen die Anregung.


LG

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ändert sich nichts.
Solange nicht auf Hardware zugegriffen wird.
Zu beachten ist, dass ints unterschiedluch groß sein können. Deshalb 
sollte man im Vorfeld schon Typen wie uint32_t oder size_t benutzen.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Array D. schrieb:

> Mein Dozent meinte letztens,dass der neue Cortex R4 Atomare Befehle
> unterstützt. Deswegen die Anregung.

Wenn Du auf das Level gehst, wo diese Eigenarten wichtig sind, dann mußt 
Du sowieso in Assembler programmieren, weil Du ansonsten keine Gewißheit 
hast, welche Befehle der Compiler am Ende überhaupt nimmt.

Gibt aus C-Sicht noch ein paar Feinheiten; neben den ints ist das auch 
die signedness des Datentyps char. x86 und ARM sind da per default genau 
umgedreht. Das ist aber egal, solange Du mit char nicht rechnest, 
sondern nur Zeichen speicherst. Zum Rechnen nimmt man einfach uint8_t 
bzw. int8_t.

Was man auch oft als Fehler sieht in C-Code, ist die implizite Annahme, 
ein Pointer müsse 4 Byte groß sein. Das geht bei 64bit-Code dann schief. 
Will man mal wirklich bitweise auf Pointern herumfummeln, dann gibt's 
dafür den Datentyp uintptr_t. Der gibt einem immer einen Integer, der 
einen Pointer fassen kann.

Dann hat man bei manchen, aber nicht allen ARMs das Alignment. Manche 
können keinen int auf einer ungeraden Adresse verarbeiten (gibt nen 
Absturz); andere können es, brauchen dafür aber zwei Zugriffe, zwischen 
denen auch noch ein Interrupt passieren kann. Eine weitere Folge ist, 
daß Structs sich auf manchen ARMs packen lassen, auf anderen nicht.

Endianess ist natürlich auch immer ein Thema, sobald man Daten zwischen 
verschiedenen Architekturen tauscht (man normiert das Format dann an den 
externen Schnittstellen).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Dann hat man bei manchen, aber nicht allen ARMs das Alignment. Manche
> können keinen int auf einer ungeraden Adresse verarbeiten (gibt nen
> Absturz); andere können es, brauchen dafür aber zwei Zugriffe,

Bis einschliesslich ARMv5 (z.B. ARM7,ARM9) gibts weder einen Trap noch 
das, was man dabei haben will, sondern Datenmüll.

Beim Load wird das Wort an der Adresse gelesen und anhand der unteren 
beiden Adressbits rotiert. Byte-Load unterscheidet sich vom Word-Load 
nur in der Maskierung.

: Bearbeitet durch User
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> ibt aus C-Sicht noch ein paar Feinheiten; neben den ints ist das auch
> die signedness des Datentyps char. x86 und ARM sind da per default genau
> umgedreht.

Das sind zwar Unterschiede, aber keine, die der jeweiligen 
Prozessorarchitektur anzulasten sind. Das liegt ausschließlich im 
verwendeten Compiler.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Nop schrieb:
>> Dann hat man bei manchen, aber nicht allen ARMs das Alignment. Manche
>> können keinen int auf einer ungeraden Adresse verarbeiten (gibt nen
>> Absturz); andere können es, brauchen dafür aber zwei Zugriffe,
>
> Bis einschliesslich ARMv5 (z.B. ARM7,ARM9) gibts weder einen Trap noch
> das, was man dabei haben will, sondern Datenmüll.

Also auf dem ARM7TDMI (ARMv4), den ich mal programmiert habe, wurde in 
so einem Fall eine Hardware-Exception ausgelöst.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Also auf dem ARM7TDMI (ARMv4), den ich mal programmiert habe, wurde in
> so einem Fall eine Hardware-Exception ausgelöst.

War Fehlinformation aus
https://www.heyrick.co.uk/armwiki/Unaligned_data_access

Das AARMv5 sagt, dass man bei implementiertem System Control Coprocessor 
einen Alignment-Trap einschalten kann. Die ersten ARM Versionen hatten 
das definitiv nicht.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Das liegt ausschließlich im  verwendeten Compiler.

Richtig, und man kann das auf Wunsch auch mit einem Compiler-Switch 
ändern. Aber es ist definitiv ein potentieller Stolperstein für einen 
C-Anfänger, und wenn man da nicht drauf kommt, kann man ziemlich lange 
suchen.

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.