Konstante Zeiger (Memory mapped Peripherie)

volkard

Adressen könntest Du in den Code lesbarmachen.

extern "C" reg_detail::syst_csr p0xE000E010;
	static auto& syst_csr = p0xE000E010;

__p0xE000E010 = 0xE000E010;

camper

Wozu eigentlich die Referenzen?

Und das mit den Adressen ist nicht wirklich verständlich. Der Sinn von Symbolen ist doch gerade, (u.a.) magische Zahlen wie etwa Adressen loszuwerden. Und im Zweifel kann man ja immer noch - wie volkard angemerkt hat, den Bezeichner entsprechend der Adresse benennen.

volkard, auch danke an Dich, ja, so könnte man wohl drumrumwuseln. Aber irgendwie hat das alles einen extrem faden Beigeschmack. C++ zog los als hardwarenahe Highlevel-Programmiersprache und dann wird einem aktiv ein Klotz vor die Füße gesetzt. Ich bin jetzt erstmal enttäuscht, habe eine Frage an die Entwickler des Arm-GCC-Ports gewendet, ob die einen Workaround haben und falle derweilen ersteinmal vom Glauben ab. Solche Dinge haben echt einen extremen Einfluss auf meine Stimmung...

@camper: Das habe ich nur direkt so hingeschrieben, damit ich keine Kollisionen bei den Symbolen bekomme, falls mal Register gleiche Namen besitzen oder so.

Nathan

ArmDran schrieb:

volkard, auch danke an Dich, ja, so könnte man wohl drumrumwuseln. Aber irgendwie hat das alles einen extrem faden Beigeschmack. C++ zog los als hardwarenahe Highlevel-Programmiersprache und dann wird einem aktiv ein Klotz vor die Füße gesetzt. Ich bin jetzt erstmal enttäuscht, habe eine Frage an die Entwickler des Arm-GCC-Ports gewendet, ob die einen Workaround haben und falle derweilen ersteinmal vom Glauben ab. Solche Dinge haben echt einen extremen Einfluss auf meine Stimmung...

Ähm, wo es ist jetzt das Problem? Das, was du wolltest, war noch nie erlaubt, also ist es nicht schlechter geworden...

volkard

camper schrieb:

Der Sinn von Symbolen ist doch gerade, (u.a.) magische Zahlen wie etwa Adressen loszuwerden.

Ja, schon. Aber man mag sie auf C++-Ebene auch definieren können.

Ich erinnere mal ans Einstellen der zu linkenden Bibliotheken unter MSVC und bei 3000 Quellcodedateien und zig Fremdlibs war das zum Kotzen. Aber mit

#pragma comment lib

war alles ok. Das kommt in den Header, der die Funktionalität der lib bereitstellt und alles geht von allein. Insbesondere kann man mit den Dateien oder Teilen davon neue Projekte starten, ohne strundenlang Linkersachen anzupassen.

Also ArmDrans Wunsch kommt mir nicht seltsam vor. Ich finde, daß ins makefile so wenig Anwendungscode wie möglich gehört. Daher auch so flach

__p0xE000E010 = 0xE000E010;

camper

volkard schrieb:

camper schrieb:

Der Sinn von Symbolen ist doch gerade, (u.a.) magische Zahlen wie etwa Adressen loszuwerden.

Ja, schon. Aber man mag sie auf C++-Ebene auch definieren können.

Ich erinnere mal ans Einstellen der zu linkenden Bibliotheken unter MSVC und bei 3000 Quellcodedateien und zig Fremdlibs war das zum Kotzen. Aber mit
#pragma comment lib
war alles ok. Das kommt in den Header, der die Funktionalität der lib bereitstellt und alles geht von allein. Insbesondere kann man mit den Dateien oder Teilen davon neue Projekte starten, ohne strundenlang Linkersachen anzupassen.

Also ArmDrans Wunsch kommt mir nicht seltsam vor. Ich finde, daß ins makefile so wenig Anwendungscode wie möglich gehört. Daher auch so flach
__p0xE000E010 = 0xE000E010;

Wenns ein zusammenhängender Speicherbereich ist, reicht es ja auch, einfach ein Array auf diese Weise zu deklarieren, und die Zuordnung zu einzelnen Registern dann nur im C++ Code vorzunehmen.
Im Extremfall einfach ein Array für den gesamten verfügbaren Speicher Kann man evtl. mit union verfeinern, um mit verschiedenen Datentypen umgehen zu können.

Alternativ könnte man auch einfach zulassen, was offenbar so natürlich ist, dass es GCC bis Version 4.8 unterstützt hat, bis dessen Entwickler dann mal im Standard nachgeblättert haben. Vor allem, dass ausgerechnet bei reinterpret_cast Sicherheit als ein Argument hergenommen wird, erschließt sich mir nicht so ganz (http://wg21.cmeerw.net/cwg/issue1384)...

camper

ArmDran schrieb:

Alternativ könnte man auch einfach zulassen, was offenbar so natürlich ist, dass es GCC bis Version 4.8 unterstützt hat, bis dessen Entwickler dann mal im Standard nachgeblättert haben. Vor allem, dass ausgerechnet bei reinterpret_cast Sicherheit als ein Argument hergenommen wird, erschließt sich mir nicht so ganz (http://wg21.cmeerw.net/cwg/issue1384)...

Ich glaube nicht, dass sich das Ganze so ohne weiteres bugfrei implementieren lässt.

mit

template <typename T, T*p> struct foo { ... };
extern int bar1, bar2;

wissen wir sicher, dass foo<int,&bar1> und foo<int,&bar2> verschiedene Instantiierungen sind (sogar dann, wenn die Symbole beim Linker den gleichen Wert haben...). Aber was ist, wenn eine Adresse explizit angegeben werden kann?
foo<int,reinterpret_cast<int*>(100)> ? ist das nun eine andere Instantiierung auch dann, wenn die Adresse von bar1 am Ende auch 100 ist?
Wenn nicht, dann muss der Compiler ja bereits die Adresse kennen, um z.B. is_same<...> korrekt zu instantiieren. Dabei ist die Festlegung von Adressen ja gerade typischerweise Aufgabe des Linkers oder sogar erst des Loaders.

In jedem Fall ist das Forum nicht der richtige Ort für solche Beschwerden. Dafür gibt es bugzilla bei gcc.

Ja Du hast Recht, ich musste nur irgendwie meinem Frust freien Lauf lassen... Ich bleib erstmal bei 4.8 und wenn die Entwickler keinen Workaround parat haben, schreib ich mir nen Skript der den Quelltext nach "__placed_0xfoofoo" absucht und ne Symboldatei schreibt... Wobei ich dann auch verifizieren muss, dass da derselbe Code rauskommt als hätte der Compiler schon die letztendliche Adresse parat.