Strukturierte Programmierung: Anti-Switch-Case

[Walter T. (nicolas)]

Hallo zusammen,

wenn ich in eine Schleife oder einen Quelltext-Teil an einer bestimmten 
Stelle hereinspringen will, bietet sich switch-case an. Wie gehe ich 
denn bei strukturierter Programmierung vor, wenn ich aus einem 
Programmteil herausspringen will?

Als Beispiel habe ich mal einen UTF-8-Dekoder gemacht:

    /** UTF8-Zeichenlaenge anhand des ersten Bytes ermitteln
     * Die Laenge eines UTF-8-Zeichens (1 bis 4 Byte) ist im ersten Zeichen einkodiert.
     *       0xxxxxxx -> 1 Byte
     *       110xxxxx -> 2 Bytes
     *       1110xxxx -> 3 Bytes
     *       11110xxx -> 4 Bytes
     *
     * Die clz() instruction benoetigt einen Takt auf dem Cortex M3.
     *
     * @param[in] Zeiger auf erstes Byte eines UTF-8-Zeichens
     * @return Anzahl der Bytes des UTF-8-Zeichens */
    int_fast8_t utf8bytes(const char *s0)
    {
        uint32_t a = *s0;
        a <<= 24;
        int_fast8_t r = __builtin_clz(~a);
        r = r==0 ? 1 : r;
        return r;
    }


    /** Konvertierung UTF8-Zeichen in Unicode
     *
     * @param[in] Zeiger auf erstes Byte eines UTF-8-Zeichens
     * @param[out] Unicode
     * @return Anzahl der konsumierten Bytes */
    int_fast8_t utf8ToUnicode(uint32_t *unicode, const char *s)
    {
        int_fast8_t nBytes = utf8bytes(s);
        uint32_t r = 0;

        switch(1)
        {
            case 1:

               /* 1-Byte-Bereich U+0000 bis U+007F */
                r = *s++;
                if( nBytes <= 1 ) break;


                /* 2-Byte-Bereich U+0080 bis U+07FF */
                r <<= 6;
                r |= (*s++) & 0x3F;
                r &= 0x000003FF;  /* Erste zwei Bits ausmaskieren */
                if( nBytes <= 2 ) break;


                /* 3-Byte-Bereich U+0800 bis U+FFFF */
                r <<= 6;
                r |= (*s++) & 0x3F;
                r &= 0x0000FFFF;  /* Erste drei Bits ausmaskieren */
                if( nBytes <= 3 ) break;


                /* 4-Byte-Bereich U+10000 bis U+10FFFF */
                r <<= 6;
                r |= (*s++) & 0x3F;
                r &= 0x01FFFFFF;  /* Erste vier Bits ausmaskieren */
        }
        *unicode = r;
        return nBytes;
    }

Ich habe mich dafür entschieden, dass switch-break an dieser Stelle das 
am wenigsten häßliche mir bekannte Konstrukt ist. Das ist schon beinahe 
goto-esk.

Man könnte den zweiten Teil auch mit einer while-Schleife machen und 
neben dem Schleifenzähler auch die Maske mitschieben.

Oder geht es noch besser?

[Oliver S. (oliverso)]

Walter T. schrieb:
> Oder geht es noch besser?

Das kommt ganz auf deine Definition von "gut" an. Ich würde bei dem Code 
fragen: geht es noch schlechter?

Das ist auf halben Weg zum Obfuscation-C-Contest, ohne jeglichen 
Mehrwert durch all die grotesken Konstrukte. Krampfhaftes vermeiden von 
if ist weder cool noch hipp noch modern, noch irgendetwas anderes, wenn 
if genau das ausdrückt, was es ausdrücken soll.

Oliver

[Walter T. (nicolas)]

Wie würdest Du es unobsfuskiert ausdrücken?

[Thomas F. (tommf)]

    int_fast8_t utf8ToUnicode(uint32_t *unicode, const char *s)
    {
        int_fast8_t nBytes = utf8bytes(s);
        uint32_t r = 0;
        if( nBytes >= 1 )
        {
           /* 1-Byte-Bereich U+0000 bis U+007F */
           r = *s++;
        }
        if( nBytes >= 2 )
        { 
           /* 2-Byte-Bereich U+0080 bis U+07FF */
           r <<= 6;
           r |= (*s++) & 0x3F;
           r &= 0x000003FF;  /* Erste zwei Bits ausmaskieren */
        }
        if( nBytes >= 3 )
        {
           /* 3-Byte-Bereich U+0800 bis U+FFFF */
           r <<= 6;
           r |= (*s++) & 0x3F;
           r &= 0x0000FFFF;  /* Erste drei Bits ausmaskieren */
        }
        if ( nBytes >= 4 )
        {
           /* 4-Byte-Bereich U+10000 bis U+10FFFF */
           r <<= 6;
           r |= (*s++) & 0x3F;
           r &= 0x01FFFFFF;  /* Erste vier Bits ausmaskieren */
        }
        *unicode = r;
        return nBytes;
    }

[Oliver S. (oliverso)]

Einfach das hinschreiben, was gemeint ist.

   /* 1-Byte-Bereich U+0000 bis U+007F */
   r = *s++;

   /* 2-Byte-Bereich U+0080 bis U+07FF */
   if( nBytes >1 ){
   r <<= 6;
//...
  }
 /* 3-Byte-Bereich U+0800 bis U+FFFF */
   if( nBytes >2 ){
   r <<= 6;
//...
  }
// usw.

Oliver
P.S. Thomas tippte schneller ;)

[Walter T. (nicolas)]

Stimmt. Das ist naheliegend. Manchmal sieht man den Wald nicht mehr. Die 
Abbruchbedingung nur einmal zu prüfen wird wohl nicht hinzubekommen 
sein.

[Rolf M. (rmagnus)]

Walter T. schrieb:
> wenn ich in eine Schleife oder einen Quelltext-Teil an einer bestimmten
> Stelle hereinspringen will, bietet sich switch-case an.

Tut es das?

> switch(1)
>         {
>             case 1:

Was zum Geier soll das denn sein?

> Ich habe mich dafür entschieden, dass switch-break an dieser Stelle das
> am wenigsten häßliche mir bekannte Konstrukt ist. Das ist schon beinahe
> goto-esk.

Man muss sich nicht zwanghaft irgendwelche kranken Konstrukte ausdenken, 
nur um auf Biegen und Brechen goto zu vermeiden, weil man halt mal 
indoktriniert wurde, dass das die Saat des Bösen sei.
Das hier ist einer der beiden Fälle, die ich kenne, in denen goto 
durchaus sinnvoll ist.

[JayLow (Gast)]

do
{
...
} while(0);

[Oliver S. (oliverso)]

Walter T. schrieb:
> Die
> Abbruchbedingung nur einmal zu prüfen wird wohl nicht hinzubekommen
> sein.

Wenn du unbedingt ein switch willst, dann nimm ein switch (nBytes), und 
ordne die Fälle absteigend ohne break an (fallthrough). Braucht etwas 
Umformulierung der Berechnung, aber das kriegst du hin. Das ist dann 
aber immer noch nicht "gut".

Oliver

[NichtWichtig (Gast)]

JayLow schrieb:
>

> do
> {
> ...
> } while(0);
>

+1

[Walter T. (nicolas)]

Ja, ein bischen Abstand tut gut. Eigentlich brauche ich die Einsen am 
Anfang gar nicht zu zählen. So geht es auch:

    /** Konvertierung UTF8-Zeichen in Unicode
     *
     * @param[in] Zeiger auf erstes Byte eines UTF-8-Zeichens
     * @param[out] Unicode
     * @return Anzahl der konsumierten Bytes */
    int_fast8_t utf8ToUnicode(uint32_t *unicode, const char *s)
    {
        assert( unicode != NULL );
        assert( s != NULL );

        /* char kann signed sein */
        uint_fast8_t byte0 = (uint8_t) *s++;

        /* Byte0 = 0xxxxxxx -> 1 Byte
         * 1-Byte-Bereich U+0000 bis U+007F */
        uint32_t r = byte0;
        int_fast8_t nBytes = 1;


        if( byte0 >= 0xC0 )
        {
            /* Byte0 == 110xxxxx -> 2 Bytes, U+0080 bis U+07FF */
            r <<= 6;
            r |= (*s++) & 0x3F;
            r &= 0x000003FF;  /* Erste zwei Bits ausmaskieren */
            nBytes++;
        }

        if( byte0 >= 0xE0 )
        {
            /* Byte0 == 1110xxxx -> 3 Bytes, U+0800 bis U+FFFF */
            r <<= 6;
            r |= (*s++) & 0x3F;
            r &= 0x0000FFFF;  /* Erste drei Bits ausmaskieren */
            nBytes++;
        }

        if( byte0 >= 0xF0 )
        {
            /* Byte0 == 11110xxx 4 Bytes U+10000 bis U+10FFFF */
            r <<= 6;
            r |= (*s++) & 0x3F;
            r &= 0x01FFFFFF;  /* Erste vier Bits ausmaskieren */
            nBytes++;
        }
        *unicode = r;
        return nBytes;
    }

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Rolf M. schrieb:
>> switch(1)
>>         {
>>             case 1:
>
> Was zum Geier soll das denn sein?

Verzweifelter Versuch dass er break verwenden kann, damit er kein 
"böses" return mitten aus einer Funktion verwenden muss.

Was vermutlich geht (ich habe jetzt keine Lust mir die Masken für r 
anzusehen), ist einfach eine Schleife, auch wenn die Berechnung etwas 
unsymmetrisch ist

int_fast8_t nBytes = utf8bytes(s);
uint32_t r = 0;
mask1 = ...
mask2 = ...

for(i = 0; i < nBytes; i++) {
...
}

Nebenbei ist die Bezeichnung der Konvertierung falsch

>     /** Konvertierung UTF8-Zeichen in Unicode

UTF-8 ist schon Unicode, im Transformation Format 8. Was er versucht ist 
den Unicode Codepoint auszurechnen.

[Walter T. (nicolas)]

Walter T. schrieb:
> So geht es auch:

Hng. Der strunzdumme Compiler merkt nicht, dass die vorherigen 
Bedingungen schon enthalten sind und er eigentlich bis zum Ende springen 
kann, ohne alles jeweils einzeln vergleichen zu müssen. Also müssen die 
if-Anweisungen geschachtelt werden oder doch wieder Goto oder ein 
Ersatz.

[fizzbuzz (Gast)]

if und if-else + andere Reihenfolge.

//>0xF0
if(a>240){
//bla bla
{
else if(a>224){
//bla bla
}
else if(a>192){
//bla bla
}

https://wiki.c2.com/?FizzBuzzTest

[Walter T. (nicolas)]

fizzbuzz schrieb:
> if und if-else + andere Reihenfolge.

Stimmt. Eigentlich ist es ja total egal, in welcher Reihenfolge die 
Bytes aus dem Array gelesen werden.

[mh (Gast)]

Walter T. schrieb:
> Hng. Der strunzdumme Compiler merkt nicht, dass die vorherigen
> Bedingungen schon enthalten sind und er eigentlich bis zum Ende springen
> kann, ohne alles jeweils einzeln vergleichen zu müssen. Also müssen die
> if-Anweisungen geschachtelt werden oder doch wieder Goto oder ein
> Ersatz.

Ich bin mir nicht sicher was genau du meinst, aber hast du Optimierungen 
aktiviert?

[Walter T. (nicolas)]

mh schrieb:
>
> Ich bin mir nicht sicher was genau du meinst, aber hast du Optimierungen
> aktiviert?

Die folgenden Varianten sind funktionell identisch, weil die Vergleiche 
aufsteigend sortiert sind:

if( byte0 >= 0xC0 )
{
    ...
}
if( byte0 >= 0xE0 )
{
    ...
}
if( byte0 >= 0xF0 )
{
    ...
}
return



if( byte0 >= 0xC0 )
{
    ...
    if( byte0 >= 0xE0 )
    {
        ...
        if( byte0 >= 0xF0 )
        {
            ...
        }
    }
}
return

Tatsächlich wird mit -O1 aber in der ersten Variante der Vergleich 
dreimal vorgenommen, wenn er schon beim ersten Mal schiefgegangen ist. 
Entsprechend wird dreimal gesprungen.

[mh (Gast)]

Walter T. schrieb:
> Tatsächlich wird mit -O1 aber in der ersten Variante der Vergleich
> dreimal vorgenommen, wenn er schon beim ersten Mal schiefgegangen ist.
> Entsprechend wird dreimal gesprungen.

Welcher Compiler?

[Walter T. (nicolas)]

mh schrieb:
> Welcher Compiler?

https://godbolt.org/z/e4jET8esc

[Rolf M. (rmagnus)]

-O1 ist halt minimale Optimierung. Bei -O2 macht er es. Außerdem ist gcc 
5.4 schon recht alt.

[Walter T. (nicolas)]

Sehr merkwürdig. Selbst beim neuesten ARM-GCC auf der höchsten 
Optimierungsstufe sind die beiden nicht äquivalent:

https://godbolt.org/z/7M7Y9h89K

Bis hin zu dem Kuriosum, dass die ersten beiden Zeilen unterschiedlich 
übersetzt werden, weil ein Block mit Textzeigern über die 
130-Bytes-Grenze wandert.

[Experte (Gast)]

static int8_t decode((uint32_t *unicode, const char *s, char mask, int8_t additional_bytes)
{
  *unicode = (uint32_t)(*s++ & mask);

  for (int8_t i = 0; i < additional_bytes; i++)
    *unicode = (*unicode << 6) | (uint32_t)(*s++ & 0x3f);

  return 1 + additional_bytes;
}

int8_t utf8ToUnicode(uint32_t *unicode, const char *s)
{
  if (!(*s & 0x80))
    return decode(unicode, s, 0x7f, 0);
  
  else if (!(*s & 0x20)) 
    return decode(unicode, s, 0x1f, 1);
  
  else if (!(*s & 0x10))
    return decode(unicode, s, 0x0f, 2);
  
  else
    return decode(unicode, s, 0x07, 3);
}

[Yalu X. (yalu) (Moderator)]

Wie wär's mit einer Schleife statt der If-Kaskade?

uint32_t utf8decode(uint8_t bytes[]) {
  uint8_t first = *bytes++;
  uint32_t result = first, mask = 0xffffff80;

  if (first & 0x80) {
    first <<= 1;
    while (first & 0x80) {
      result = result << 6 | *bytes++ & 0x3f;
      first <<= 1;
      mask <<= 5;
    }
  }
  result &= ~mask;

  return result;
}

[Experte (Gast)]

Yalu X. schrieb:
> mask <<= 5;

Clever!


> Wie wär's mit einer Schleife statt der If-Kaskade?

Wie gesagt, gut gesehen, gefällt mir aber nicht.

Ich mag es, wenn Code den Fällen der Spezifikation entspricht. Lässt 
sich in funktionalen Sprachen sehr schön formulieren (algebraische 
Datentypen, strukturelle Zerlegung etc.), ergibt in den alten, 
imperativen Sprachen wie C eben if-else-if-else-Kaskaden. Diese Kaskaden 
sind aber meiner Meinung nach leicht zu warten und zu verstehen, weil 
sie die Fälle aufzählen und dem menschlichen Denken entsprechen.

Aber wie immer, das ist subjektiv, jeder hat da seine eigenen Prägungen.

[udok (Gast)]

@Walter:
Warum nicht einfach die Betriebssystem Funktion verwenden?
Bist ja nicht der erste, der das Problem hat...
... und deine C Kenntnisse sind noch nicht so weit, das du
das einfach und effizient lösen kannst.

Die ganze Optimiererei (int_fast8_t???, Assembler anschauen???)
macht doch 0 Sinn, wenn das Klump nicht funktioniert.
Denke nur mal an all die Spezialfälle, die nicht in der Spec stehen, 
wenn
sich etwa ein Latin1 Char einschleicht...

[A. S. (Gast)]

oder wie Oliver das meinte, ein switch mit fallthrough

uint32_t utf8decode(uint8_t bytes[]) {
uint32_t result=0;

   switch(*bytes & 0xf0)
   {
   case 0xf0: result |= *bytes++ & 0x07; result<<=6;
              result |= *bytes   & 0x3f;
   case 0xe0: result |= *bytes++ & 0x0f; result<<=6;
   case 0xc0:  
   case 0xd0: result |= *bytes++ & 0x3f; result<<=6;
   default:   result |= *bytes++ & 0x7f; 
   }
   return result;
}

Ist unwartbar, obwohl er "nach Schema F" aussieht.

[Walter T. (nicolas)]

Yalu X. schrieb:
> Wie wär's mit einer Schleife statt der If-Kaskade?

Die ist es mittlerweile auch geworden.

Aber Respekt: Alle drei Varianten funktionieren.

[Peter D. (peda)]

Walter T. schrieb:
> int_fast8_t r = __builtin_clz(~a);

Solche Obfuscationen macht man erst, wenn riesige Datenmengen in kurzer 
Zeit zu verarbeiten sind.
Laß das ganze _fast und _builtin Gedöns weg und schreib lesbaren und 
funktionierenden Code.

[Walter T. (nicolas)]

Peter D. schrieb:
> Solche Obfuscationen macht man erst, wenn riesige Datenmengen in kurzer
> Zeit zu verarbeiten sind.

Was wäre denn Deine nicht-merkwürdige Variante, führende Einsen zu 
zählen? While-Schleife und hoffen, dass der Compiler das als Idiom 
versteht?

(Bei den fast-Int bin ich nicht Deiner Meinung. An die habe ich mich so 
gewöhnt, dass sie für mich mittlerweile "normaler" als "int" und "long" 
aussehen.)

[Rolf M. (rmagnus)]

Peter D. schrieb:
> Laß das ganze _fast und _builtin Gedöns weg und schreib lesbaren und
> funktionierenden Code.

int_fast8_t ist ein Standard-typedef. Da ist nichts falsch dran.

[mh (Gast)]

Rolf M. schrieb:
> Peter D. schrieb:
>> Laß das ganze _fast und _builtin Gedöns weg und schreib lesbaren und
>> funktionierenden Code.
>
> int_fast8_t ist ein Standard-typedef. Da ist nichts falsch dran.

Falsch nicht, aber der Nutzen ist sehr begrenzt und häufig ist es 
kontraproduktiv. Das Problem ist das "fast". Was genau bedeutet es? In 
welchen Situationen ist ein int_fast8_t schneller als ein int8_t? Gibt 
es Situationen wo ein int_fast8_t langsamer ist als ein int8_t?

Da die fast-Varianten nur typedefs sind, kann man dem Compiler damit 
schonmal ordentlich ausbremsen. Oder haben Compiler mittlerweile extra 
Logik für diese Typen integriert? Also weiß der Compiler, dass ein 
int_fast8_t einen 8Bit Wertebereich hat, auch wenn es ein typedef auf 
einen int32 ist?

[Prokrastinator (Gast)]

Rolf M. schrieb:
> goto zu vermeiden, weil man halt mal
> indoktriniert wurde, dass das die Saat des Bösen sei.

Hihi, ich hatte mal einen Anruf des Programmierers eines Kunden, der 
völlig Entsetzt, mit bebender Stimme sagte: 'Du hast GOTO verwendet ...'

Ja. Stimmt. Der Kandidat hat 100 Punkte.
Ist Teil des C Spachstandards und war an der Stelle die übersichtlichste 
Methode aus dem Loop zu entkommen. Für Glaubensfragen bitte an den 
Esotheriker des geringsten Mißtrauens wenden.

Den Teil mit Inline ASM und den Jumps auf Sprungmarken fand er okay.
Ist ja ein mega Unterschied zu GOTO ...

Den Teil mit der Pointerarithmetik ohne Bereichsprüfung hat er nicht mal 
gecheckt. Ist mir dann noch rechtzeitig aufgefallen.

[Jörg W. (dl8dtl) (Moderator)]

mh schrieb:
> In welchen Situationen ist ein int_fast8_t schneller als ein int8_t?

Kann dir beim ARM schnell passieren, denn da muss u.U. noch zusätzlich 
maskiert werden, während der int_fast8_t 32 Bit breit ist und damit die 
natürliche Maschinenwortbreite nutzen kann.

Packst du den gleichen Code aber auf einen AVR, kann der Compiler dafür 
tatsächlich eine 8-Bit-Einheit nehmen.

[mh (Gast)]

Jörg W. schrieb:
> mh schrieb:
>> In welchen Situationen ist ein int_fast8_t schneller als ein int8_t?
>
> Kann dir beim ARM schnell passieren, denn da muss u.U. noch zusätzlich
> maskiert werden, während der int_fast8_t 32 Bit breit ist und damit die
> natürliche Maschinenwortbreite nutzen kann.
Mir ist klar, dass es Situationen gibt, in denen es Vorteile gibt. 
Deswegen enthält mein Betrag mehr als die eine Frage. Ist der Vorteil 
beim Maskieren  größer als der Nachteil beim Kopieren wo 3 unnötige 
Bytes angefasst werden müssen? Kann der Compiler nicht vielleicht auch 
für den int8_t das 32Bit Register benutzen? Verhindert der int_fast8_t 
alias int32 eine Optimierung weil der Compiler nicht mehr sehen kann, 
dass der echte Wertebereich nur 8Bit groß ist?

[Experte (Gast)]

Peter D. schrieb:
> Walter T. schrieb:
>> int_fast8_t r = __builtin_clz(~a);
>
> Solche Obfuscationen macht man erst, wenn riesige Datenmengen in kurzer
> Zeit zu verarbeiten sind.

Witzig dabei auch, dass __builtin_clz(0) undefiniert ist...

[Walter T. (nicolas)]

Experte schrieb:
> Witzig dabei auch, dass __builtin_clz(0) undefiniert ist...

Ein UTF-8-Zeichen, das mit 0xFF anfängt, aber auch.

[Jörg W. (dl8dtl) (Moderator)]

mh schrieb:
> Kann der Compiler nicht vielleicht auch für den int8_t das 32Bit
> Register benutzen?

Ja, kann er nicht. int8_t sagt "nimm genau 8 Bit". int_fast8_t sagt 
"nimm mindestens 8 Bit, gern auch mehr, wenn es das schneller macht".

Der Vollständigkeit halber: int_least8_t sagt: "nimm möglichst 8 Bit; 
wenn du das nicht kannst, nimm halt mehr". Der Unterschied zu int8_t 
ist, dass eine Maschine, die keine 8-Bit-Einheiten handhaben kann (da 
gibt's wohl ein paar DSPs) halt zwar ein int_least8_t implementieren 
kann, aber ein int8_t kann sie dann schlicht nicht anbieten. Code, der 
so geschrieben ist, dass er per int8_t unbedingt genau 8 Bit haben 
möchte, lässt sich dann nicht compilieren.

[Klaus W. (mfgkw)]

Yalu X. schrieb:
> Wie wär's mit einer Schleife statt der If-Kaskade?

Ah, die berühmte if-Schleife? :-)

[Walter T. (nicolas)]

Interessanter finde ich aber trotzdem die Frage, was an den 
__builtin-Funktionen verkehrt ist und was die bessere Alternative ist.

Mein naiver Ansatz war ja: Sie sind schon da. Sie sind dokumentiert. 
Also kann man sie benutzen.

Wenn ich für den MSVC austauschbaren Code geschrieben hätte, hätte ich 
sie wohl in eine Funktion clz() gewrappt, wohl oder übel eine 
Compilerweiche benutzt und den anderen Zweig selbst implementiert. Mit 
dem Nebeneffekt, noch einmal einen eigenen Header mehr einfügen zu 
müssen.

[Markus F. (mfro)]

Walter T. schrieb:
> Interessanter finde ich aber trotzdem die Frage, was an den
> __builtin-Funktionen verkehrt ist

Nix, wenn dich nicht stört, daß sie nicht portabel und (auch wenn Du 
immer und ewig "nur" gcc benutzt) nur in einer hosted-Umgebung zur 
Verfügung stehen.

[Walter T. (nicolas)]

Markus F. schrieb:
> Nix, wenn dich nicht stört, daß sie nicht portabel und (auch wenn Du
> immer und ewig "nur" gcc benutzt) nur in einer hosted-Umgebung zur
> Verfügung stehen.

Kannst Du das näher erläutern? Ich verstehe den Begriff der 
"hosted-Umgebung" in diesem Zusammenhang nicht.

[Christian F. (christian_f476)]

Klaus W. schrieb:
> berühmte if-Schleife? :-)

Kurz nach dem Umstieg von Pacsal:

#define repeat do
#define until(x) while(x)

  repeat
  {
    _delay_ms(500);
  }
  until(messwert_lesen() == 1);

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:
> Ich verstehe den Begriff der "hosted-Umgebung" in diesem Zusammenhang
> nicht.

-fhosted (default Option des Compilers)

Es wird eine Standardbibliothek vorausgesetzt, und der Compiler darf 
entsprechend der standardmäßig definierten Bedeutung auch 
Bibliotheksfunktionen optimieren. Beispielsweise kann er dabei 
strlen("hi") durch die Konstante 2 ersetzen. Andererseits sind in diesem 
Falle auch Prototypen für main() genormt, das muss entweder

int main(void);

oder

int main(int, char **);

sein. Das im Embedded-Bereich so gern geschriebene

void main(void);

verletzt theoretisch diese Regel (und gibt entsprechend eine Warnung).

Alternative: "freestanding environment", -ffreestanding

Hier definiert der Standard einen deutlich eingeschränkteren 
Funktionsumfang, es ist keine Standardbibliothek vorausgesetzt, main() 
darf man beliebig deklarieren (es darf auch ganz fehlen). Aber: es kann 
halt auch keine Standardbibliothek optimiert werden.

Daher arbeiten selbst embedded-Systeme sehr oft mit -fhosted.

[Markus F. (mfro)]

Walter T. schrieb:
> Kannst Du das näher erläutern? Ich verstehe den Begriff der
> "hosted-Umgebung" in diesem Zusammenhang nicht.

Schau' mal hier: 
https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html 
(-ffreestanding bzw. -fno-hosted).

[Walter T. (nicolas)]

Jörg W. schrieb:
> -fhosted (default Option des Compilers)

Diese Erklärung ist sehr schön, und sollte irgendwo oben angepinnt sein. 
Hätte ich sie viel früher gelesen, hätte mir das viel Zeit gespart.

Aber ich finde nirgendwo ein Indiz dafür, dass die buildins in 
"freestanding" nicht verfügbar wären.

[Rolf M. (rmagnus)]

mh schrieb:
> Rolf M. schrieb:
>> Peter D. schrieb:
>>> Laß das ganze _fast und _builtin Gedöns weg und schreib lesbaren und
>>> funktionierenden Code.
>>
>> int_fast8_t ist ein Standard-typedef. Da ist nichts falsch dran.
>
> Falsch nicht, aber der Nutzen ist sehr begrenzt und häufig ist es
> kontraproduktiv.

Ja? Wann denn?

> Das Problem ist das "fast". Was genau bedeutet es? In welchen Situationen
> ist ein int_fast8_t schneller als ein int8_t?

Eine allgemengültige Antwort gibt es dafür nicht. Aber bei manchen 
Architekturen sind die Datentypen tendenziell unterschiedlich effizient 
im Bezug auf Rechenzeit. Und der kleinste muss nicht gezwungenermaßen 
auch der schnellste sein.

> Gibt es Situationen wo ein int_fast8_t langsamer ist als ein int8_t?

Kann es auch geben.

> Da die fast-Varianten nur typedefs sind, kann man dem Compiler damit
> schonmal ordentlich ausbremsen.

Das gilt für int8_t genauso.

> Oder haben Compiler mittlerweile extra Logik für diese Typen integriert?

gcc hat das anscheinend aktuell nicht, soweit ich erkennen kann.

mh schrieb:
> Mir ist klar, dass es Situationen gibt, in denen es Vorteile gibt.
> Deswegen enthält mein Betrag mehr als die eine Frage. Ist der Vorteil
> beim Maskieren  größer als der Nachteil beim Kopieren wo 3 unnötige
> Bytes angefasst werden müssen?

Werden sie sowieso. Das Prozessor-Register ist so oder so 32 Bit breit, 
und der Speicher wird oft auch sowieso immer in 32-Bit-Einheiten 
angesprochen. Der Unterschied ist dann nur, dass bei einem Kopieren 
eines 8-Bit-Werts aus dem Speicher die anderen 32 Bytes weggeworfen 
werden, bzw. beim Schreiben gar noch umständlich gelesen, dann das eine 
Byte ausgestauscht, dann wieder zurückgeschrieben werden müssen.

> Kann der Compiler nicht vielleicht auch für den int8_t das 32Bit Register
> benutzen?

Das muss er sowieso, weil der ARM gar keine 8-Bit-Register hat. Wenn du 
aber auf 8 Bit festzurrst, muss er sicherstellen, dass da nachher der 
gleiche Wert drin steht, als wäre das Register 8 Bit breit gewesen. Und 
das kann zusätzlichen Aufwand bedeuten.

> Verhindert der int_fast8_t alias int32 eine Optimierung weil der Compiler
> nicht mehr sehen kann, dass der echte Wertebereich nur 8Bit groß ist?

Nein.

[Walter T. (nicolas)]

Interessant. Das Schweigen der Experten sagt mehr als viele Worte 
anderer.

Zu "__builtin -- lieber nicht" gibt es von denjenigen in diesem Thread, 
von deren Kompetenz ich überzeugt bin, weder Zustimmung und Begründung 
noch Ablehnung.

Es scheint also ein vages Unwohlsein zu erzeugen, auf dessen Quelle man 
nicht genau mit dem Finger zeigen kann.

[A. S. (Gast)]

Walter T. schrieb:
> Interessanter finde ich aber trotzdem die Frage, was an den
> __builtin-Funktionen verkehrt ist und was die bessere Alternative ist.
>
> Mein naiver Ansatz war ja: Sie sind schon da. Sie sind dokumentiert.
> Also kann man sie benutzen.

Du kannst sie ja auch benutzen. Aber erst am Ende, wenn Messungen einen 
Bottleneck ergeben und es für diese Plattform wichtig ist. .

Im Ursprungscode sieht es hingegen fast so aus, als seien die Funktionen 
um das clz herum gebaut worden. Natürlich ist keines der Codebeispiele 
hier wirklich sinnvoll. Doch fällt gerade bei solchen Aufgaben der Code 
am Ende in sich zusammen, wenn man ihn portabel formuliert und 
verbessert. Nicht, wenn man ihn um eine fancy Funktion herum baut.

[Walter T. (nicolas)]

A. S. schrieb:
> Im Ursprungscode sieht es hingegen fast so aus, als seien die Funktionen
> um das clz herum gebaut worden.

Wenn der einschlägige Teil des Standards, den man vorliegen hat, 
aussagt: "Die Anzahl der Einsen/die Stellung der ersten Null am Anfang 
des ersten Bytes bestimmt, was dann gemacht wird" (Wikipedia).
Mein erster Gedanke: "OK, ich muss Einsen zählen. Moment mal. Für den 
Zweierlogarithmus hatte ich eine nette Funktion, die Nullen zählt, 
also..."

Wie würdest Du anfangen? Was machst Du ohne Bottleneck?


Das Fragen mag penetrant sein. Aber ich will verstehen, was für einen 
Softwareentwickler "normal" ist. Im Internet findet man wenig 
"normales". Man findet hauptsächlich laute Minderheiten. Ich meine: Wenn 
wir unsere sexuelle Früherziehung im Internet genossen und uns daran 
orientiert hätten, was "normal" ist...

Ich habe im Alltag keinen Kontakt zu Softwareentwicklern.

[Vincent H. (vinci)]

Walter T. schrieb:
> Interessanter finde ich aber trotzdem die Frage, was an den
> __builtin-Funktionen verkehrt ist und was die bessere Alternative ist.

In C++20 gibts std::countl_zero
https://en.cppreference.com/w/cpp/numeric/countl_zero

[udok (Gast)]

Walter T. schrieb:
> Wenn der einschlägige Teil des Standards, den man vorliegen hat,
> aussagt: "Die Anzahl der Einsen/die Stellung der ersten Null am Anfang
> des ersten Bytes bestimmt, was dann gemacht wird" (Wikipedia).

Das sagt der Standard eben nicht, bzw nur mit Einschränkungen.
Ohne sich mit dem Unicode Standard auseinanderzusetzen, kommen
da nur halbgare Sachen raus, allzu oft auch Sicherheitslücken
(Stichwort Überlange UTF-8 Sequenzen, Codepoint <= 0x10ffff,
Ungültige Zeichenbereiche, CESU-8).  Abgesehen vom Standard hast du
noch das Problem, dass es auch reichlich ungültiges UTF-8 gibt,
mit dem man aber in der Praxis umgehen muss.

Aber was willst du denn eigentlich machen?
Das ist doch erst mal die entscheidende Frage, die du nicht
beantwortest (so wie 90% der TE hier).
Ich habe so den Eindruck, dass du einfach jemanden zum Quatschen
brauchst, auch ok.
In der Zeit, die du hier verplemperst, hättest du dir auch
einige UTF-8 Libs auf github anschauen können, oder
in der Doku deiner uns unbekannten Entwicklungsumgebung suchen
können.

Optimieren ohne Ziel, und ohne Performancemessung ist doch reine 
Zeitverschwendung.  Wahrscheinlich liest deine Anwendung
gerade mal 100 Config Bytes, und das geht halt dann vielleicht
in 20 us statt in 30 us.
Aber schon dein Ansatz, einzelne Zeichen anzuschauen verhindert es,
das da irgendwas mit guter Performance rauskommt.
Du musst blockweise arbeiten, wenn es schnell gehen soll.
Ob du int8_t oder int verwendest, geht da im Rauschen unter,
aber alles kleiner als int wird in C erst mal auf int konvertiert.

Der Profi widmet dem Testen und der Behandlung von Fehlerzuständen
eher mehr Zeit, als der Implementierung der Grundfunktion.
Dann kommt erst die Optimierung und auch nur wenn es notwendig ist,
oder wenn Zeit ist. Bei dir ist es umgekehrt.

Als Referenz: die ziemlich gut optimierte Win32 MultiByteToWideChar 
Funktion schafft 1.2 Zeichen / Takt für Ascii Zeichen,
und ca. 0.5 Zeichen / Takt für komlexere Zeichen (ohne SSE 
Erweiterungen).
Eine moderne SSE Funktion schafft über 4 Zeichen / Takt.

Aber brauchst du wirklich UTF-8?  Am Mikrocontroller?
Nimm doch einfach ASCII oder Latin1, und gut ist es.
Schau mal, das deine Anwendung läuft, und wenn du dann Chinesische
Zeichen brauchst, ist UTf-8 vielleicht gar nicht die beste Wahl.

[Walter T. (nicolas)]

udok schrieb:
> Optimieren ohne Ziel, und ohne Performancemessung ist doch reine
> Zeitverschwendung.

Dazu gerne in einem anderen Thread, den ich soeben eröffnet habe.

udok schrieb:
> Aber was willst du denn eigentlich machen?

Ich dachte, das sei durch die umfangreiche Kommentierung des Quelltextes 
im Eröffnungsbeitrag geklärt. Ich brauchte einen UTF-Dekoder. Performanz 
ist auch nicht ganz nebensächlich, weil da wirklich jede einzelne 
Zeichenkette durchgeht, die auf dem Display erscheint. Mit chinesischen 
Zeichen habe ich es nicht. Aber mit dem griechischen Alphabet und ein 
paar anderen Formelzeichen.

Aber das läuft ja alles seit Samstag.

[Jörg W. (dl8dtl) (Moderator)]

Walter T. schrieb:

> Aber ich finde nirgendwo ein Indiz dafür, dass die buildins in
> "freestanding" nicht verfügbar wären.

Ich vermute, dass sie da auch verfügbar sind, aber wie heißt es so 
schön? "If all else fails, read the documentation."

[Walter T. (nicolas)]

Die Doku schweigt sich dazu aus. Ich nehme an, es handelt sich um ein 
beredtes Schweigen.


Aber welcher Frage ich immer noch kein Stück näher gekommen bin: Warum 
wird hier sofort "premature optimization" geschriehen, sobald ein paar 
Unterstriche vorkommen?

[A. S. (Gast)]

Walter T. schrieb:
> Mein erster Gedanke: "OK, ich muss Einsen zählen. Moment mal. Für den
> Zweierlogarithmus hatte ich eine nette Funktion, die Nullen zählt, also.

Vorzeitige Optimierung ist übel.

Solange Du die Aufgabe nicht durchdrungen hast, kann eine Optimierung 
keinen Sinn machen.

Das ist so, als würde man ein Schema suchen, obwohl man erst 5 der 8 
Sonderfälle gelesen hat. Wertlos, wenn man alle 8 implementieren will, 
weil es auch einfacher werden kann.

Wenn es nur 5 pattern gibt, ist Plain Code kein schlechter start, also 5 
ifs hier z.b.

[Walter T. (nicolas)]

Okay, also für Dich ist

if( (byte0 & 0xC0) == 0xB0 )
{
  ...
} 
if( (byte0 & 0xF0) == 0xC0 )
{
  ...
}

also leichter zu lesen als

    uint32_t a = byte0;
    a <<= 24;
    int_fast8_t r = __builtin_clz(~a);

Das klingt für mich ungewohnt, aber vielleicht macht es die tägliche 
Vertrautheit mit HEX-Wüsten, die mir absolut fehlt.

[A. S. (Gast)]

Walter T. schrieb:
> also leichter zu lesen als

Die beiden Schnipsel haben miteinander nichts zu tun. Ob Du  hexzahlen 
lesen kannst oder bitmuster (xxx_____ oder b11100000) nutzt, ist eine 
Sache.

Ob Du die Bestimmung der Einsen rausziehst und dafür eine (gedankliche) 
Übersetzung mehr hast, das andere.

Die wichtigen Fragen sind doch ganz andere: welchen Umfang willst Du 
dekodieren? Wie gehst Du mit Zeichen außerhalb um, wie mit fehlerhaften 
oder abgebrochenen (passiert sehr schnell mit strncpy + 0). Was ist als 
Funktion(sset) gut nutzbar (deine erfordert drumherum nochmal den 
gleichen Overhead)

Bis dahin habe ich nichts dagegen, dass auch zu programmieren (um es zu 
testen, zu verstehen) aber nicht Tricky in Sütterlin auf Stein 
gemeißelt, sondern lesbar und einfach.

[Peter D. (peda)]

Walter T. schrieb:
> Was wäre denn Deine nicht-merkwürdige Variante, führende Einsen zu
> zählen? While-Schleife und hoffen, dass der Compiler das als Idiom
> versteht?

Nun, erstmal kann nicht jede Maschine ein __builtin_clz und 2. mußte ich 
erstmal nachsehen, was das überhaupt macht. Und 3. ist Dein Code sowas 
von hinten durch die Brust ins Auge, nur um es benutzen zu können. Ich 
hab da ewig gebraucht, um durchzusehen.

Ich würde solche einfachen Sachen direkt hinschreiben, ohne komplizierte 
Konstrukte:

/** UTF8-Zeichenlaenge anhand des ersten Bytes ermitteln
 * Die Laenge eines UTF-8-Zeichens (1 bis 4 Byte) ist im ersten Zeichen einkodiert.
 *       0xxxxxxx -> 1 Byte
 *       110xxxxx -> 2 Bytes
 *       1110xxxx -> 3 Bytes
 *       11110xxx -> 4 Bytes
 * @return Anzahl der Bytes des UTF-8-Zeichens */

int_fast8_t utf8bytes(const char *s0)
{
  switch (*s0 & 0xF0)
  {
    case 0xF0: return 4;
    case 0xE0: return 3;
    case 0xC0:
    case 0xD0: return 2;
    default:   return 1;
  }
}

[Walter T. (nicolas)]

Peter D. schrieb:
>     case 0xC0:
>     case 0xD0: return 2;

Okay, wir haben wirklich sehr unterschiedliche Denkweisen, was als 
"naheliegend" zu bezeichnen ist.

Insofern macht das die Diskussion über den ursprünglichen Anwendungsfall 
hinaus interessant.

[A. S. (Gast)]

Peter D. schrieb:
> Ich würde solche einfachen Sachen direkt hinschreiben, ohne komplizierte
> Konstrukte:

Ich hab das oben ja genauso gemacht, nur ist das halt Tricky und nicht 
wirklich das gewünschte. Du kannst 4 nicht von 5 einen unterscheiden und 
bei Default fallen auch alle Fehler rein.

[Experte (Gast)]

Walter T. schrieb:
> Okay, wir haben wirklich sehr unterschiedliche Denkweisen, was als
> "naheliegend" zu bezeichnen ist.

Naja, wer das hier schreibt:

  switch(1)
  {
    case 1:

beurteilt "andere" Denkweisen?

Kennst Du den uralten Witz mit Bart:

> Verkehrsfunk: "Achtung: Ein Falschfahrer auf der Autobahn!"
> Autofahrer: "Ein Falschfahrer? Hunderte!"

[Walter T. (nicolas)]

Der Teil mit dem Heraussprung war ja auch der Teil, mit dem ich von 
Anfang an unzufrieden war - Anlass für diesen Thread. Der Teil mit den 
Einsen zählen normal. Bitte nicht mischen!