ARM-GCC: Unsigned-Integer-Overflow

[Walter T. (nicolas)]

Hallo zusammen,

gibt es eine Möglichkeit (z.B. ein Intrinsic, das ich nicht gefunden 
habe), dem ARM-GCC beizubringen, einen Überlauf einer Addition mit 
Unsigned Integer einfach über das Carry-Bit zu machen, ohne Overhead zu 
erzeugen?

Quasi das hier in minimaleffizient:

// Globals
uint32_t v = UINT32_MAX/10;

void ISR_HIGH_FREQU(void)
{
    static uint32_t a = 0;

    if( a > UINT32_MAX - v )
        do_some_fast_operation_with_nebeneffekt();
    
    a+= v;
}

Viele Grüße
W.T.

[Niklas G. (erlkoenig)]

Wenn der eine Takt wirklich so wichtig ist ginge es mit Inline Assembly:

#include <stdint.h>
#include <limits.h>

void do_some_fast_operation_with_nebeneffekt (void);

uint32_t v = UINT32_MAX/10;

void test1 (void) {
  static uint32_t a = 0;
  uint32_t* ap = &a;
  uint32_t* vp = &v;
  __asm__ volatile (  "ldr r0, [%[ap]]\n"
            "ldr r1, [%[vp]]\n"
            "adds r0, r1\n"
            "it cs\n"
            "blcs do_some_fast_operation_with_nebeneffekt\n"
            : 
            : [ap] "r" (ap), [vp] "r" (vp)
            : "r0", "r1", "r2", "r3", "lr", "r12", "cc", "memory");
  
  a += v;
}

void test2 (void) {
  static uint32_t a = 0;
    if( a > UINT32_MAX - v )
        do_some_fast_operation_with_nebeneffekt();

    a += v;
}

ergibt

00000000 <test1>:
   0:  b530        push  {r4, r5, lr}
   2:  4c06        ldr  r4, [pc, #24]  ; (1c <test1+0x1c>)
   4:  4d06        ldr  r5, [pc, #24]  ; (20 <test1+0x20>)
   6:  6820        ldr  r0, [r4, #0]
   8:  6829        ldr  r1, [r5, #0]
   a:  1840        adds  r0, r0, r1
   c:  bf28        it  cs
   e:  f7ff fffe   blcs  0 <do_some_fast_operation_with_nebeneffekt>
  12:  6823        ldr  r3, [r4, #0]
  14:  682a        ldr  r2, [r5, #0]
  16:  4413        add  r3, r2
  18:  6023        str  r3, [r4, #0]
  1a:  bd30        pop  {r4, r5, pc}
  ...

00000024 <test2>:
  24:  b538        push  {r3, r4, r5, lr}
  26:  4d07        ldr  r5, [pc, #28]  ; (44 <test2+0x20>)
  28:  4c07        ldr  r4, [pc, #28]  ; (48 <test2+0x24>)
  2a:  682a        ldr  r2, [r5, #0]
  2c:  6863        ldr  r3, [r4, #4]
  2e:  43d1        mvns  r1, r2
  30:  4299        cmp  r1, r3
  32:  d203        bcs.n  3c <test2+0x18>
  34:  f7ff fffe   bl  0 <do_some_fast_operation_with_nebeneffekt>
  38:  682a        ldr  r2, [r5, #0]
  3a:  6863        ldr  r3, [r4, #4]
  3c:  4413        add  r3, r2
  3e:  6063        str  r3, [r4, #4]
  40:  bd38        pop  {r3, r4, r5, pc}
  42:  bf00        nop
  ...

Allerdings richtet der GCC den Stack bei test1 nicht korrekt aus; wenn 
do_some_fast_operation_with_nebeneffekt ein 8-Byte-Alignment braucht 
gibt es einen Absturz. Habe auch nicht herausgefunden wie man dem GCC 
beibringt dass ein Inline-Assembler-Block einen Funktionsaufruf enthält 
und daher Alignment nötig ist...

[Walter T. (nicolas)]

Niklas G. schrieb:
> Wenn der eine Takt wirklich so wichtig ist

Hallo Namensvetter,

ich zähle jetzt zwei Takte Unterschied - aber nein: So wichtig, dass der 
Mehraufwand für Assembler gerechtfertigt wäre, sind mir diese zwei Takte 
nicht. Zumindest nicht heute. Mich interessiert nur die Möglichkeit.

Und ich will noch nicht so recht wahrhaben, dass der nicht-seltene 
Anwendungsfall "Überlauferkennung" von den Compilerbauern einfach so 
links liegen gelassen wurde.

Viele Grüße
W.T.

[temp (Gast)]

meinst du sowas:

 ... 
  __asm volatile 
    (
    // Load loop count to register
    " mov r3, %[loops]\n"
    " .align 4\n"
    "loop: sub r3,#1   \n" 
    "      bne loop  \n\n"
    : // No output registers
    : [loops] "r" (CyclestoLoops) // Input registers
    : "r3" // clobbered registers
      );
 ...

Ich hatte mal das Problem, dass sich eine Delay() Funktion (ja man 
braucht so was ohne Timer hin und wieder doch mal) ständig anderes 
verhielt. Das ging soweit, dass eine Programmänderung an einer ganz 
anderen Stelle auf einmal die Laufzeiten der Delay-Funktion grob 
veränderten. (Alle ohne jeden Interrupt oder DMA dazwischen). Am Ende 
stellt sich raus, dass das wohl mit dem Flash Waitstates und Cachings zu 
tun hatte, denn es war davon abhängig an welchen Adressen im Flash am 
Ende der Codeschnipsel oben landete. Das align 4 hat mein Problem 
jedenfalls gelöst.

[Niklas G. (erlkoenig)]

temp schrieb:
> meinst du sowas:

Nein, ich meinte das Alignment des Stack Pointers ("SP"). Bloß was für 
Füll-Bytes produziert der Assembler an der Stelle? Die werden ja vom 
Prozessor als Instruktionen interpretiert...

[Oliver S. (oliverso)]

Walter T. schrieb:
> Und ich will noch nicht so recht wahrhaben, dass der nicht-seltene
> Anwendungsfall "Überlauferkennung" von den Compilerbauern einfach so
> links liegen gelassen wurde.

https://godbolt.org/z/K1DpyW

So ganz links liegen gelassen haben die das wohl doch nicht.

Oliver

[Luther B. (luther-blissett)]

__builtin_uadd_overflow() vielleicht?

https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

[Walter T. (nicolas)]

Luther B. schrieb:
> __builtin_uadd_overflow()

Das sieht hervorragend aus:

https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,lang:c%2B%2B,source:'%23include+%3Cstdint.h%3E%0D%0A%0D%0Avolatile+uint32_t+v+%3D+42%3B%0D%0Avoid+foo()%3B%0D%0A%0D%0Avoid+ISR()+%7B%0D%0A++++static+uint32_t+a+%3D+0%3B%0D%0A++++uint32_t+vl+%3D+v%3B%0D%0A%0D%0A++++if(__builtin_uadd_overflow(a,+vl,+%26a))%0D%0A+++++++foo()%3B%0D%0A%0D%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%231',t:'0')),k:57.507360157016684,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:armg820,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'1',trim:'1'),lang:c%2B%2B,libs:!(),options:'-O1',source:1),l:'5',n:'0',o:'ARM+gcc+8.2+(Editor+%231,+Compiler+%231)+C%2B%2B',t:'0')),k:42.492639842983316,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4