gcc/c++: Compilezeit-Array für progmem erstellen lassen

[Matho (Gast)]

Hallo nochmal,
könnte etwas redundant sein, aber eigentlich nicht:
Ich habe gerade diese Frage im PC-Programmierungs-Forum gestellt:
Beitrag "c++: Lookup-Table Inhalt zur Compilezeit erstellen"

Quasi der allgemeine Fall, aber ich frage mich auch, ob es einen 
Spezialfall für µCs gibt. Ich habe nämlich ein wenig das Gefühl, dass 
embedded-gcc etwas anders arbeitet. Z.B. macht es (oft) keinen 
Unterschied, ob ich pass-by-value, oder pass-by-reference mache. Und 
einen this-Zeiger habe ich im asm auch noch nicht entdecken können..

Ich möchte gerne eine progmem-array erstellen, wobei:

array[i] = fkt(i,Size); //Size:Template-Parameter, i:Index

Bislang müsste ich für ene bestimmte 'Size' außerhalb ein Array 
berechnen und die Werte dann manuell im Code einfügen. Schön ist das 
nicht.

Hat jemand für diesen Fall eine Idee?
MfG
Matho

[Einer K. (Gast)]

Ich habe Schwierigkeiten deine Frage zu verstehen, u.A. da ich einige 
deiner Annahmen nicht teile!

Matho schrieb:
> Z.B. macht es (oft) keinen
> Unterschied, ob ich pass-by-value, oder pass-by-reference mache.
Hier wüsste ich nicht, wie sich der AVR-GCC vom PC-GCC unterscheidet.
Denn C++ ist C++.

Matho schrieb:
> Und
> einen this-Zeiger habe ich im asm auch noch nicht entdecken können..
Tja...
Sowas gibts in Assembler auch nicht.
Und im Gcc Kompilat wird er nach Möglichkeit weg optimiert. z.B. nur 
einmal in einem Registerpaar gesetzt und dann stundenlang verwendet.

Matho schrieb:
> Ich möchte gerne eine progmem-array erstellen, wobei:array[i] =
> fkt(i,Size); //Size:Template-Parameter, i:Index
>
> Bislang müsste ich für ene bestimmte 'Size' außerhalb ein Array
> berechnen und die Werte dann manuell im Code einfügen. Schön ist das
> nicht.
Das verstehe ich überhaupt nicht.
Das ist auch kein testbarer Code.

Ich sehe noch nicht mal ein Template.

[Matho (Gast)]

>Hier wüsste ich nicht, wie sich der AVR-GCC vom PC-GCC unterscheidet.
>Denn C++ ist C++.

Als bestes Beispiel würden mir viellicht progmem-arrays einfallen, da es 
die so auf dem PC nicht gibt.

>Sowas gibts in Assembler auch nicht.
Ich habe generell das gefühl, dass für µC mehr 'geinlined', optimiert 
und verboten wird.. Irgendwas war da doch auch z.B. mit virtuellen 
Methoden!?

>Das verstehe ich überhaupt nicht.
>Das ist auch kein testbarer Code.
Testbaren Code hätte ich auch gerne.
Ganz konkret möchte ich ein array im PROGMEM vom Compiler füllen lassen.
Mit etwas Pseudocode unabhängig von Templates o.Ä.:

const int Size = 123;
const int PROGMEM array[Size];
for(int i = 0; i<Size; ++i) array[i] = sin(i/Size*2*PI);

[Dr. Sommer (Gast)]

Matho schrieb:
> Ich habe generell das gefühl, dass für µC mehr 'geinlined', optimiert
> und verboten wird..

Nö. Das macht der GCC beim PC ganz genauso. "Verboten" ist kaum was, nur 
manches braucht zu viel Speicher für die meisten µC. Dinge wie fopen() 
können nur funktionieren wenn man die entsprechenden Syscalls selbst 
nachbaut.

Matho schrieb:
> Irgendwas war da doch auch z.B. mit virtuellen
> Methoden!?
Die gehen ganz genau wie am PC. Man sollte nur die Funktion 
__cxa_pure_virtual überschreiben, weil die von der newlib zu viel 
Speicher braucht.

Der "this"-Pointer wirkt einfach wie ein 0. Parameter und wird z.B. bei 
arm in r0 übergeben.

[Einer K. (Gast)]

Matho schrieb:
>>Hier wüsste ich nicht, wie sich der AVR-GCC vom PC-GCC unterscheidet.
>>Denn C++ ist C++.
>
> Als bestes Beispiel würden mir viellicht progmem-arrays einfallen, da es
> die so auf dem PC nicht gibt.
Ne, ich bezog mich mit "Hier" konkret auf das was ich zitiert habe.
Und PROGMEM ist eher eine Sache des Linkers, der Umgebung.
Der Compiler weiß davon eher nichts.

Matho schrieb:
> Irgendwas war da doch auch z.B. mit virtuellen
> Methoden!?
Ja?

Matho schrieb:
> Pseudocode
Ja, das habe ich jetzt verstanden.
Nein, leider weiß ich da auch keine Möglichkeit...
Weder mit constexpr noch mit Templates.

Außer:
Ein Miniprogramm schreiben, welches dir C/C++ Quellcode ausspuckt.

[Wilhelm M. (wimalopaan)]

Matho schrieb:
> Ich möchte gerne eine progmem-array erstellen, wobei:
>

> array[i] = fkt(i,Size); //Size:Template-Parameter, i:Index
>

Der schlüssel zum Erfolg liegt hier in `integer_sequence` und 
fold-expressions.

[Absolvent (Gast)]

Das wurde doch im anderen Thread jetzt hinreichend besprochen. Dieser 
Thread hier kann dann doch abgeschlossen werden.

[Wilhelm M. (wimalopaan)]

Wilhelm M. schrieb:
> Matho schrieb:
>> Ich möchte gerne eine progmem-array erstellen, wobei:
>>

>> array[i] = fkt(i,Size); //Size:Template-Parameter, i:Index
>>

>
> Der schlüssel zum Erfolg liegt hier in `integer_sequence` und
> fold-expressions.

Ich vergaß: und natürlich constexpr lambda-expressions als IIFE 
(immediately invoked function expressions);

[Einer K. (Gast)]

Wilhelm M. schrieb:
> Der schlüssel zum Erfolg liegt hier in `integer_sequence` und
> fold-expressions.

Wilhelm M. schrieb:
> Ich vergaß: und natürlich constexpr lambda-expressions als IIFE
> (immediately invoked function expressions);

Arduino ist noch auf C++11

C++17 nur mit inoffiziellem Update des AVR Core und Toolchain
Und mit STL sowieso nicht.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Wilhelm M. schrieb:
>> Der schlüssel zum Erfolg liegt hier in `integer_sequence` und
>> fold-expressions.
>
> Wilhelm M. schrieb:
>> Ich vergaß: und natürlich constexpr lambda-expressions als IIFE
>> (immediately invoked function expressions);
>
> Arduino ist noch auf C++11

Wer spricht von Arduino?

> C++17 nur mit inoffiziellem Update des AVR Core und Toolchain

Der offizielle avr-gcc 8.2.0 (C++17) ist dafür ausreichend.

> Und mit STL sowieso nicht.

Wer spricht von STL?

[Einer K. (Gast)]

Stimmt, d hast du Wahr.
Mein Fehler.

Und du weißt wie es geht und zeigst es nicht.
Sei stolz darauf und reibe es jedem unter die Nase.
.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Stimmt, d hast du Wahr.
> Mein Fehler.
>
> Und du weißt wie es geht und zeigst es nicht.
> Sei stolz darauf und reibe es jedem unter die Nase.

Hier die Umsetzung. Natürlich sollte man den Generator noch als 
template-template-Parameter parametrierbar machen, was ich hier aber 
unterlassen habe, denn die Kommentare der Unleserlichkeit kommen ja 
sicher schon bei diesem Beispiel:

#include <cstdint>
#include <cstddef> 
#include <cassert> 
#include <std/utility>
#include <avr/pgmspace.h>

template<auto Size>
struct PgmArray {
    template<typename> struct Generator;
    using mapper = Generator<std::make_index_sequence<Size>>;
    inline static char value(size_t index) {
        assert(index < Size);
        return pgm_read_byte(&mapper::data[index]);
    }
    template<auto... Index>
    struct Generator<std::index_sequence<Index...>> {
        inline static constexpr char data[Size] PROGMEM = {[](auto v){return v * 2;}(Index)... }; 
    };
};

using a1 = PgmArray<10> ;

int main() {
    return a1::value(2);
}

Die Realisierung von std::index_sequence und/oder 
std::make_index_sequence überlasse ich dem Leser. Oder man schaut halt 
mal in die C++-Standard-Bibliothek hinein ;-)

[Wilhelm M. (wimalopaan)]

Kleiner Nachtrag: wer einen gcc > 9.0.0 zur Verfügung hat, kann auch 
lambda-expressions in sog. unevaluated-contexts sowie dann auch 
default-constructible closures verwenden:

#include <cstdint>
#include <cstddef> 
#include <cassert> 
#include <utility>
#include <avr/pgmspace.h>

using cppversion = std::integral_constant<long, __cplusplus>;

//cppversion::_;

struct Functor {
    constexpr char operator()(auto v) const {
        return 2 * v;
    }
};

auto l1 = [](auto v){return 2 * v;};

template<auto Size, typename F>
struct PgmArray {
    template<typename> struct Generator;
    using mapper = Generator<std::make_index_sequence<Size>>;
    inline static char value(size_t index) {
        assert(index < Size);
        return pgm_read_byte(&mapper::data[index]);
    }
    template<auto... Index>
    struct Generator<std::index_sequence<Index...>> {
        inline static constexpr char data[Size] PROGMEM = {
            F()(Index)... 
        }; 
    };
};

using a1 = PgmArray<10, Functor>;
using a2 = PgmArray<5, decltype(l1)>; // -> default constructible closures neccessary
//using a2 = PgmArray<5, decltype([](auto v){return 2 * v;})>; // -> lambda in ue-context

int main() {
    if constexpr(cppversion::value > 201703) {
        return a1::value(2) + a2::value(1);
    }
    else {
        return a1::value(2);
    }
}

[Einer K. (Gast)]

Ich möchte dir für deine Mühe danken.
Danke!


Wilhelm M. schrieb:
> wer einen gcc > 9.0.0 zur Verfügung hat,
Leider kann ich das nicht (so einfach) testen.
Den Rahmen habe ich vorher schon genannt.
Genauer: avr-gcc 7.3.0 ist z.Zt. meine obere Grenze

Der Code ist aber zur weiteren Bearbeitung vorgemerkt.

Wilhelm M. schrieb:
> denn die Kommentare der Unleserlichkeit kommen ja
> sicher schon bei diesem Beispiel
Natürlich...
Ich empfinde das auch (noch?) als recht unleserlich, und wenig intuitiv 
erfassbar.

Ansonsten, lass sie schimpfen.
z.B. Ich akzeptiere gerne Lob/Kritik von Leuten, die es besser können.

Und ein "Besser" muss hier erst mal belegt werden.
Dann ist noch genug Zeit für Urteile und meckern.


Tipp:
Je mehr die Leute meckern, desto weniger investieren sie darin, das zu 
verstehen, worüber sie meckern.

Oder anders:
Die Intensität des Geschreis ist häufig proportional zu der Dicke des 
Brettes vor dem Schädel.

Wilhelm M. schrieb:
> Wer spricht von STL?
Naja, du selber setzt sie hier ein.

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Wilhelm M. schrieb:
>> wer einen gcc > 9.0.0 zur Verfügung hat,
> Leider kann ich das nicht (so einfach) testen.
> Den Rahmen habe ich vorher schon genannt.
> Genauer: avr-gcc 7.3.0 ist z.Zt. meine obere Grenze

Das war aber beim TO nicht genannt (auch keine Beschränkung auf 
Arduino-IDE).

> Wilhelm M. schrieb:
>> Wer spricht von STL?
> Naja, du selber setzt sie hier ein.

Nein.
i)  die STL ist etwas anderes als die C++-Standardbibliothek.
ii) da es für AVR keine C++-Standardbibliothek gibt, habe ich mir meine 
eigene Version geschrieben mit bestimmten Besonderheiten (auch für AVR).

[Einer K. (Gast)]

Ich sehe schon, dein Verständnis dafür, dass ich das leider nicht testen 
kann hält sich in Grenzen.
Is ok....

[Wilhelm M. (wimalopaan)]

Arduino Fanboy D. schrieb:
> Ich sehe schon, dein Verständnis dafür, dass ich das leider nicht testen
> kann hält sich in Grenzen.

Wie gesagt: die aktuelle gcc Version ist 8.2.1. Damit kannst Du schon 
mal die Functor-Variante testen ;-)