Erfahrungen mit STM8 und sdcc

Torsten R. OP (Firma: Torrox.de) #4141868
Lesenswert?
• ▲
▼ 
Hallo,
hat jemand von euch Erfahrung mit dem sdcc und STM8. Hintergrund meiner 
Frage ist, dass ich hier gerade ein ganz kleines Beispielprogramm habe 
und der Compiler mir hier offensichtlich falschen Code erzeugt. Wenn das 
jetzt die einzige Stelle ist, dann würde ich den Bug evtl. versuchen zu 
patchen.

Auf der Suche nach dem Bug in der Bug-Datenbank, bin ich dann wieder 
über einen Bugreport gestolpert, bei dem jemand versucht hat, den von 
mir gefundenen Bug zu umschiffen und ist dabei wieder auf einen Bug 
gestoßen.

Kann man den sdcc benutzen oder guckt man da ständig nur noch ins 
assembler listing?

mfg Torsten
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Max D. #4141878
Lesenswert?
• ▲
▼ 
Also sdcc kenn ich jetzt persöhnlich nicht, aber normalerweise ist ein 
compilerbug die letzte Möglichkeit für den fehler...
Sind alle anderen Komponenten (source, header-files, usw) sicher 100% 
fehlerfrei ?
Was genau ist der bug ?
Ich wette der compiler ist unschuldig.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Torsten R. OP (Firma: Torrox.de) #4141902
Lesenswert?
• ▲
▼ 
Das ist der Bug: https://sourceforge.net/p/sdcc/bugs/2290/

getriggered wird er durch z.b. folgenden C-Code

1
if (clock() % 2000 <= 1000)

2
{

3
    PE_ODR &= 0x7f;

4
    PC_ODR &= 0x7f;

5
}

6
else

7
{

8
    PE_ODR |= 0x80;

9
    PC_ODR |= 0x80;

10
}


daraus wird folgender ASM Code:

1
                                    189 ;  /sensorlager.c: 48: if (clock() % 2000 <= 1000)

2
      00005E CDr00r00         [ 4]  190   call  _clock

3
      000061 90 AE 07 D0      [ 2]  191   ldw  y, #0x07d0

4
      000065 65               [ 2]  192   divw  x, y

5
      000066 90 A3 03 E8      [ 2]  193   cpw  y, #0x03e8

6
      00006A 22 0D            [ 1]  194   jrugt  00102$

7
                                    195 ;  /sensorlager.c: 50: PE_ODR &= 0x7f;

8
      00006C 72 17 50 14      [ 1]  196   bres  0x5014, #7

9
                                    197 ;  /sensorlager.c: 51: PC_ODR &= 0x7f;

10
      000070 AE 50 0A         [ 2]  198   ldw  x, #0x500a

11
      000073 F6               [ 1]  199   ld  a, (x)

12
      000074 A4 7F            [ 1]  200   and  a, #0x7f

13
      000076 F7               [ 1]  201   ld  (x), a

14
      000077 20 E5            [ 2]  202   jra  00105$

15
      000079                        203 00102$:

16
                                    204 ;  /sensorlager.c: 55: PE_ODR |= 0x80;

17
      000079 72 17 50 14      [ 1]  205   bset  0x5014, #7

18
                                    206 ;  /sensorlager.c: 56: PC_ODR |= 0x80;

19
      00007D AE 50 0A         [ 2]  207   ldw  x, #0x500a

20
      000080 F6               [ 1]  208   ld  a, (x)

21
      000081 AA 80            [ 1]  209   or  a, #0x80

22
      000083 F7               [ 1]  210   ld  (x), a

23
      000084 20 D8            [ 2]  211   jra  00105$

24
      000086 81               [ 4]  212   ret


Sobald man 2 Bit-Manipulationen hat, generiert der Compiler für die 
erste eine BRES oder BSET instruction (bei nur einer Manipulation nimmt 
er den längeren code). Laut "Programming Manual" müsst die Bitposition 
mit 2*pos codiert sein (und +1, wenn das bit reseted werden soll). Beide 
Bit-Operationen resultieren hier aber im gleichen opcode (72 17 50 14). 
Das kann ja wohl nicht richtig sein ;-)

mfg Torsten
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Torsten R. OP (Firma: Torrox.de) #4141928
Lesenswert?
• ▲
▼ 
Ich habe das aktuellste release installiert, da ist der Bug noch/wieder 
vorhanden. Ich habe den compiler jetzt aus den aktuellen sourcen gebaut 
und da funktioniert es.

Aber mir geht es geht es jetzt weniger um diesen einen, konkreten Bug, 
sonder eher darum, ob der Compiler zu gebrauchen ist.

mfg Torsten

p.S. hier das gleiche Listing mit heilem compiler:

1
                                161 ;  /sensorlager.c: 48: if (clock() % 2000 <= 1000)

2
      000044 CDr00r00         [ 4]  162   call  _clock

3
      000047 90 AE 07 D0      [ 2]  163   ldw  y, #0x07d0

4
      00004B 65               [ 2]  164   divw  x, y

5
      00004C 90 A3 03 E8      [ 2]  165   cpw  y, #0x03e8

6
      000050 22 0D            [ 1]  166   jrugt  00102$

7
                                    167 ;  /sensorlager.c: 50: PE_ODR &= 0x7f;

8
      000052 72 1F 50 14      [ 1]  168   bres  0x5014, #7

9
                                    169 ;  /sensorlager.c: 51: PC_ODR &= 0x7f;

10
      000056 AE 50 0A         [ 2]  170   ldw  x, #0x500a

11
      000059 F6               [ 1]  171   ld  a, (x)

12
      00005A A4 7F            [ 1]  172   and  a, #0x7f

13
      00005C F7               [ 1]  173   ld  (x), a

14
      00005D 20 E5            [ 2]  174   jra  00105$

15
      00005F                        175 00102$:

16
                                    176 ;  /sensorlager.c: 55: PE_ODR |= 0x80;

17
      00005F 72 1E 50 14      [ 1]  177   bset  0x5014, #7

18
                                    178 ;  /sensorlager.c: 56: PC_ODR |= 0x80;

19
      000063 AE 50 0A         [ 2]  179   ldw  x, #0x500a

20
      000066 F6               [ 1]  180   ld  a, (x)

21
      000067 AA 80            [ 1]  181   or  a, #0x80

22
      000069 F7               [ 1]  182   ld  (x), a

23
      00006A 20 D8            [ 2]  183   jra  00105$

24
      00006C 81               [ 4]  184   ret
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Philipp Krause Gast #4163316
Lesenswert?
• ▲
▼ 
sdcc mag zwar nicht das Niveau von gcc oder llvm erreichen, aber unter 
den Compilern für 8-Bit-Architekturen würde ich ihn auf jeden Fall zu 
den besseren zählen. sdcc hat umfagreiche regression tests, die auch 
einen Großteil der Tests von gcc umfassen. Er ist Referenzcompiler für 
das Betriebssystem FUZIX, und ist für manche Mikrocontroller der vom 
Hersteller empfohlene Compiler.
Das STM8-Backend war zum ersten Mal in sdcc 3.4.0 enthalten, und hatte 
demnach zu jenem Zeitpunkt nur wenige Nutzer, und damit auch mehr noch 
ungefundene Bugs.
Inzwischen gibt es release candidate 1 von sdcc 3.5.0. Gegenüber 3.4.0 
gibt es in 3.5.0 unter anderen zahlreiche Bugfixes und Verbesserungen im 
STM8-Backend.

Philipp

3.5.0 rc1:
https://sourceforge.net/projects/sdcc/files/
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Torsten R. OP (Firma: Torrox.de) #4163360
Lesenswert?
• ▲
▼ 
Hallo Philipp,

Philipp Krause schrieb:

> Das STM8-Backend war zum ersten Mal in sdcc 3.4.0 enthalten, und hatte
> demnach zu jenem Zeitpunkt nur wenige Nutzer, und damit auch mehr noch
> ungefundene Bugs.

Na, nun hat der sdcc noch einen Nutzer mehr :-) Ich finde es ja immer 
total toll, wenn Leute in Ihrer Freizeit professionelle Software 
entwickeln und andere dann an dem Ergebnis Teil haben lassen.

Für uns war es auf jeden Fall toll, das wir einen Compiler für das 
Target gefunden haben, der unter Unix läuft. Ich konnte mir gar nicht 
vorstellen, dass das ein Problem werden könnte.

mfg Torsten
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Philipp Krause Gast #4163679
Lesenswert?
• ▲
▼ 
A. K. schrieb:
> Interessant finde ich, dass die im Schema gleichen Statements
>     PE_ODR &= 0x7f;
>     PC_ODR &= 0x7f;
> zu völlig unterschiedlichem Code führen.

Möglicherweise sind die gar nicht so gleich. Es war schießlich kin 
kompilierbares Beispiel, wir wissen nicht, welche Präprozessormakros da 
gelten, und wie die Variablen deklariert sind. Ich habe gerade versucht, 
ein kleines kompilierbares Odebsispiel dauas zu machen:

#include <stdint.h>

#define PC_ODR  (*(volatile uint8_t *)0x500a)
#define PE_ODR  (*(volatile uint8_t *)0x5014)

unsigned int clock(void);

void f(void)
{
  if (clock() % 2000 <= 1000)
  {
      PE_ODR &= 0x7f;
      PC_ODR &= 0x7f;
  }
  else
  {
      PE_ODR |= 0x80;
      PC_ODR |= 0x80;
  }
}

und erhalte für f (Kommentare entfernt):

_f:
  call  _clock
  ldw  y, #0x07d0
  divw  x, y
  cpw  y, #0x03e8
  jrugt  00102$
  bres  0x5014, #7
  bres  0x500a, #7
  jra  00104$
00102$:
  bset  0x5014, #7
  bset  0x500a, #7
00104$:
  ret
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren