c++ Überladung für Pointer auf Flash

Mit der seit gcc 4.7 veerfügbaren __flash Erweiterung könnte es gehen

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#__flash_und_Embedded-C

Hab aber keine Erfahrung damit, kann daher auch sein, dass ich da jetzt 
Blödsinn rede.

Nein, __flash gibt's nicht für g++.

Johann L. schrieb:
> Nein, __flash gibt's nicht für g++.

Liegt das eigentlich nur daran, dass der C++-Standard sowas bislang
nicht vorsieht, oder gibt es technische Gründe?

Ich glaube mich zu erinnern, dass andere Compiler (wie IAR) durchaus
auch __flash im C++-Modus verstehen.

Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Nein, __flash gibt's nicht für g++.
>
> Liegt das eigentlich nur daran, dass der C++-Standard sowas bislang
> nicht vorsieht, oder gibt es technische Gründe?

Zunächst liegt es daran, daß niemand es machen will oder machen kann.

Embedded-C sagt, daß es als C++ Erweiterung implementiert werden kann, 
aber eine Erweiterung der C++ Spez ist nicht anbei.

Erschwerend kommt hinzu, daß Embedded-C in einigen Punkten nicht fertig 
gedacht ist und selbst in C11 keinen Einzug fand.

So ist es bekanntlich nicht möglich, eine locale, statische Variable im 
non-generic zu haben.  Und Code wie der folgende ist auch nicht möglich, 
was die Portierung hin zu Embedded-C mitunter deutlich erschwert:

1

const __flash char* str[] = { "Kund", "Matze", "Haus" };

Und während es in C immer möglich ist, statische const-Objekte in eine 
readonly Section zu legen — vorausgesetzt man hat ein Target wie ELF, 
das diese unterstützt — ist das in C++ nicht der Fall.

Z.B. ist es nicht möglich, sich in C++ eine Fixedpoint-Implementierung 
zu basteln, und die dadurch modellierten Zahlen in einer Lookup-Tabell 
ins Flash zu legen.

M.M. ist bereits das ein Beleg dafür, daß diese aufgeblähte Sprache 
kläglich versagt: Wenn C++ noch nicht mal schafft, das bisschen 
Embedded-C Zeugs mit all dem Template- und Overload- und Operator- und 
Ableite- und Konstruktor- und User-defined-Literal-Zeugs nachzubilden, 
dann stimmt irgendwas grundlegendes nicht.

> Ich glaube mich zu erinnern, dass andere Compiler (wie IAR) durchaus
> auch __flash im C++-Modus verstehen.

Ja, mag sein.

Wenn man das haben will, dürfe es jedoch um Größenordnungen günstiger 
sein, sich nen IAR anzuschaffen als einen GCC-Entwickler für die 
Implementierung der entsprechende Erweiterung anzuheueren — den 
unwahrscheinlichen Fall gesetzt, daß man überhaupt eines entspechend 
qualifizierten GCC-Entwicklers habhaft wird.

Warum wird Embedded-C immer zu einem Buch verlinkt? Wie kann ich das 
abschalten?  Ich will keine Links zu einem Buch weil es nicht um 
irgendein Buch geht!

Es geht nicht mehr, sobald du ein nicht POD nimmst, wie es für eine 
Fixedpoint-Implementierung in C++ der Fall sein würde.

Johann L. schrieb:
> Warum wird Embedded-C immer zu einem Buch verlinkt?

Das musst du Andreas fragen ...

Johann L. schrieb:
> Wenn man das haben will, dürfe es jedoch um Größenordnungen günstiger
> sein, sich nen IAR anzuschaffen als einen GCC-Entwickler für die
> Implementierung der entsprechende Erweiterung anzuheueren

OK, ich nahm an, dass sich das mehr oder weniger geradezu aus der
C-Implementierung übernehmen ließe.  Wenn dem nicht so ist, dann
ist mir auch klar, dass das nicht so schnell passieren wird.

Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Warum wird Embedded-C immer zu einem Buch verlinkt?
>
> Das musst du Andreas fragen ...

Der wird kaum was ändern daran.  Ich schreib einfach Embedded–C statt 
Embedded-C, scheint zu funktionieren.

> Johann L. schrieb:
>> Wenn man das haben will, dürfe es jedoch um Größenordnungen günstiger
>> sein, sich nen IAR anzuschaffen als einen GCC-Entwickler für die
>> Implementierung der entsprechende Erweiterung anzuheueren
>
> OK, ich nahm an, dass sich das mehr oder weniger geradezu aus der
> C-Implementierung übernehmen ließe.  Wenn dem nicht so ist, dann
> ist mir auch klar, dass das nicht so schnell passieren wird.

Keine Ahnung wie die Fronts aufgebaut sind, auf Platte liegen sie in 
gcc/c, gcc/cp und gcc/c-family.  Wieviel und ob C++ von C verwendet weiß 
ich net, ich würd aber davon ausgehen, daß das C++-Front nicht auf dem 
C-Front basiert.

Da meiner Erfahrung nach nichts in GCC einfach ist, ist das C++-Front 
garantiert nicht einfach.  Aber das ist natürlich eine Sache der 
Vertrautheit damit.

Außer Gaby fällt mir niemand ein, der sowas implementieren könnte. 
Allerdings ist er Mitgied in der WG21 (C++) und was Qualifier angeht, 
steht die definitiv auf "Njet". Zum Thema gab's nen längeren Tratsch:

> In general, there is an aversion [of WG21] towards more qualifiers.
> I suspect this is mostly because of the committee being burned
> by "volatile" and also because qualifiers tend to lead to
> combinatorial explosion when it comes to implicit conversions
> and overload resolution.

http://lists.gnu.org/archive/html/avr-gcc-list/2012-05/msg00044.html

Neben der Unterstützung im Sprachkern wäre zu klären, ob libsupc++ oder 
libstdc++ erweitert werden müssen, um sowas zu unterstützen.  Und als 
C++-Maintainer würd ich dann erstmal nachfragen, warum die Sprache für 
ein Target aufgebohrt werden sollte, das noch nicht einmal die o.g. 
Bibliotheken generiert.  Und Gaby weiter:

> The trend has been to use classes (sometimes with compiler
> support) to render abstractions such as these.  See for example
> how C++11 handles atomics (std::atomic<T>) compared to C11 (_Atomic).

Was immer das bedeutet ;-) Für Flash wäre das dann wohl ein 
std::flash<T>?

Was ist "flash" in dem Zusammenhang?  Und wer wo wie wird das 
implementiert und spezifiziert?

Johann L. schrieb:
> Was ist "flash" in dem Zusammenhang?  Und wer wo wie wird das
> implementiert und spezifiziert?

Na ich würde aus
>> to use classes (sometimes
>> with compiler support
So interpretieren, dass der Compiler bestimmte Klassen "kennt" oder 
speziell behandelt (analog zum 'native' Konstrukt in Java), man würde 
dann halt nur die definition per header einbinden, und die 
Implementierung kommt "irgendwie" (entweder durch den Compiler oder eine 
speziell gebaute lib) dazu.

Johann L. schrieb:
> Was ist "flash" in dem Zusammenhang?  Und wer wo wie wird das
> implementiert und spezifiziert?

Das wäre die Frage, die ich mir dabei auch stellen würde. ;-)  Auch,
wenn ich an sich natürlich einen gewissen Sinn darin sehe, dass man
das (zumindest auf User-Ebene) über Klassen abstrahiert.

Im Prinzip könnte man ja trotzdem den Qualifier __flash dann haben
(der die nötigen Aktionen im Compiler triggert), nur dass man
derartiges halt nicht im Standard sehen will.  Die "offizielle"
Implementierung ist dann eine Klasse, die in einem compilerspezi-
fischen Header darauf aufbauend implementiert wird.

> Da meiner Erfahrung nach nichts in GCC einfach ist, ist das C++-Front
> garantiert nicht einfach.

Überzeugt. ;-)

c++User schrieb:
> Johann L. schrieb:
>> Es geht nicht mehr, sobald du ein nicht POD nimmst, wie es für eine
>> Fixedpoint-Implementierung in C++ der Fall sein würde.
>
> Was ist ein POD? Innerhalb eines Klassenkontextes muss ich natürlich mit
> diversen Einschränkungen leben (falls du das meinst).

Ja, z.B: keine Konstruktoren ;-)

"Plain Old Data"

http://stackoverflow.com/questions/146452/what-are-pod-types-in-c


Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Was ist "flash" in dem Zusammenhang?  Und wer wo wie wird das
>> implementiert und spezifiziert?
>
> Das wäre die Frage, die ich mir dabei auch stellen würde. ;-)


Von der Syntax her wäre es ein Template, das eine gewisse Magie 
implementiert aber weder vom Standard spezifiziert ist noch allgemen im 
GCC bekannt.  Ich vermute mal "atomic" is im C++ Standard, nebst 
unterschiedlicher Speichermodelle.

Wenn es denn ein Template ist bzw. syntaktisch so funktionieren soll, 
dann braucht GCC eine Möglichkeit, targetspezifische Templates zu 
definieren, die mehr oder weniger beliebige Semantik haben können:

- Datenablage
- Diagnostics
- Adressbildung und Pointer-Casts
- Überladungen von -> und was auch immer
- Konstruktion spätestens zur Linkzeit, oder es braucht nen Booltoader
- Testing und Rückwirkungsfreiheit auf nicht-betroffene Architekturen
- Support und zeitnahes Beheben von Front-End und Middle-End Bugs
  Ansonsten fliegt der ganze Krempel wieder raus, wär nicht der 1. Mal
- ...

Viel Spaß :-)

Selbst bei meinen rudimentären GCC und C++ Kenntnissen wird mir da ganz 
schummrig...

Und die POD-Einschränkung hätte man immer noch, in Endeffekt Mücke 
PR50807 aufgeblasen zum Elefanten.  Dies weil ein Konstruktor ausgeführt 
werden muss, d.h. ein nicht-POD erst zur Loadzeit konstruiert werden 
kann.

>> Da meiner Erfahrung nach nichts in GCC einfach ist, ist das C++-Front
>> garantiert nicht einfach.
>
> Überzeugt. ;-)

Vielleicht funktioniert ein klassischen Anti-Pattern: "Feature Creep" 
per PR43745 (Vtables im Flash).  Da wäre der Qualifier "unter der 
Motorhaube" und (noch) keine Spracherweiterung.

Wer std::flash<T> zum GCC beitragen mag, kann sich mit PR43745 ja schon 
mal warmlaufen :-))