Bug in microchip/xc8/v2.20/pic/sources/c90/common/awdiv.c?

[Rudi R. (microwitsch)]

25:                while((divisor & 0x8000U) == 0) {
07C8  1BF1     BTFSC n, 0x7
07C9  2FD4     GOTO 0x7D4
07D3  2FC8     GOTO 0x7C8

mit Dissasambling habe ich hier diese Stelle in XC8 2.20/ C90 awdiv.c 
gefunden, die ja zu einer Endlosschleife führen würde, wenn Bit7= 0 
ist!??

Und dann weiß ich als C-Neuling noch nicht, was 0x8000U bedeuten 
soll?Was bedeutet das U am Ende des Literals??

Ich arbeite gerade an einer Programmanalyse, die mir helfen sollte 
C-Code mit Gegenüberstellung von Assemlercode für mich begreifbarer zu 
machen.Also meine Praxis gleich an Mikrocontrollern, statt wie in meinem 
Buch mit Getränkeautomaten.
Letztlich brauche ich C für Mikros, deshalb hoffe ich in der Hinsicht 
lehrmäßig abkürzen zu können.

Danke schon mal,hier wurde mir ja schon einige Male weiter 
geholfen...eine super Anlaufstelle hier!

Gruß André :)

[Edit: code-Tags eingefügt. – Mod.]

[Harald K. (kirnbichler)]

Rudi R. schrieb:
> Und dann weiß ich als C-Neuling noch nicht, was 0x8000U bedeuten
> soll?Was bedeutet das U am Ende des Literals??

Steht in Deinem C-Buch. U wie unsigned.

[Oliver S. (oliverso)]

Rudi R. schrieb:
> 125:                while((divisor & 0x8000U) == 0) {
> 207C8  1BF1     BTFSC n, 0x7
> 307C9  2FD4     GOTO 0x7D4
> 407D3  2FC8     GOTO 0x7C8
>
> mit Dissasambling habe ich hier diese Stelle in XC8 2.20/ C90 awdiv.c
> gefunden, die ja zu einer Endlosschleife führen würde, wenn Bit7= 0
> ist!??

Nein, tut es nicht.
„BTFSC  Übergehe nachfolgenden Befehl, wenn Bit=0  (bit test f, skip if 
clear)“

Vermutlich ist es wenig hilfreich, C-Code u. Assembler zu vergleichen, 
wenn man beides nicht kann. Lern erst eins von beiden, oder leg dir 
zumindest ein Assembler-Befehlsverzeichnis zum Nachschlagen zu.

Oliver

[Oliver S. (oliverso)]

Oliver S. schrieb:
> Nein, tut es nicht.

Ok, das nehme ich zurück. 207C8 soll wohl 0x7C8 bedeuten.

Da müsstest du dann doch mal etwas mehr vom C-Code zeigen, um zu 
erkennen, was da eigentlich gewollt ist.

Oliver

[Volker S. (vloki)]

Oliver S. schrieb:
> Ok, das nehme ich zurück. 207C8 soll wohl 0x7C8 bedeuten.

Passt schon. 0x7C8 ist eine Adresse im Programmspeicher.
Wenn mit BTFSC ein Befehl (der an 0x7C9) übersprungen wird,
kommt man dadurch nicht nach 0x7D3 -> keine Endlosschleife!

[Oliver S. (oliverso)]

Volker S. schrieb:
> Wenn mit BTFSC ein Befehl (der an 0x7C9) übersprungen wird,
> kommt man dadurch nicht nach 0x7D3 -> keine Endlosschleife!

Natürlich.

Jetzt bleibt nur die offene Frage, die sich wohl auch der TO gestellt 
hat, wer oder was da Bit 7 setzen sollte, wenn es ursprünglich nicht 
gesetzt war. Denn ohne das ist das tatsächlich eine  Endlosschleife.

Dazu müsste man mal das ganze C-Programm sehen.

Oliver

[Sebastian W. (wangnick)]

Oliver S. schrieb:
> bleibt nur die offene Frage

... und was von 0x7CA bis 0x7D2 alles so passiert ...

LG, Sebastian

[Volker S. (vloki)]

Oliver S. schrieb:
> Dazu müsste man mal das ganze C-Programm sehen.

// integer signed division

signed int
#ifdef __PICC__
__awdiv(signed int divisor, signed int dividend)
#else
__awdiv(signed int dividend, signed int divisor)
#endif
{
  signed int  quotient;
  unsigned char  counter, sign;

  sign = 0;
  if(divisor < 0) {
    divisor = -divisor;
    sign = 1;
  }
  if(dividend < 0) {
    dividend = -dividend;
    sign ^= 1;
  }
  quotient = 0;
  if(divisor != 0) {
    counter = 1;
    while(((unsigned int)divisor & 0x8000U) == 0) {
      divisor <<= 1;
      counter++;
    }
    do {
      quotient <<= 1;
      if((unsigned int)divisor <= (unsigned int)dividend) {
        dividend -= divisor;
        quotient |= 1;
      }
      *(unsigned int *)&divisor >>= 1;
    } while(--counter != 0);
  }
  if(sign)
    quotient = -quotient;
  return quotient;
}

[Harald K. (kirnbichler)]

Wenn das mit Optimierung übersetzt wird, ist der Bezug zwischen 
einzelnen Assemblersequenzen und dem C-Quellcode praktisch nicht mehr 
vorhanden; es ist also nicht ansatzweise klar, ob das vorher gezeigte 
Codeschnipsel irgendwas mit der dort als Kommentar enthaltenen 
Quelltextzeile zu tun hat.

Eine 1:1-Abbildung gibt es nur bei Übersetzung ohne jedwede Optimierung.

[Oliver S. (oliverso)]

Harald K. schrieb:
> es ist also nicht ansatzweise klar, ob das vorher gezeigte
> Codeschnipsel irgendwas mit der dort als Kommentar enthaltenen
> Quelltextzeile zu tun hat.

Es ist zumindest nach dran, und das Problem mit der Endlosschleife ist 
nun mal im Assemblercode vorhanden.

Aber ja, man müsste auch den ganzen Assemblercode sehen.

Oliver

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

Oliver S. schrieb:
> Es ist zumindest nach dran, und das Problem mit der Endlosschleife ist
> nun mal im Assemblercode vorhanden.

Wenn du dir den C-Code ansiehst, solltest du erkennen können, dass die 
nicht endlos laufen kann. Die Schleife wird nur betreten, wenn der 
Divisor nicht 0 ist. Dann hat er also schon einmal mindestens ein Bit 
gesetzt. Dann wird in der Schleife so lange nach links geschoben, bis 
das höchstwertige gesetzte Bit in Bitposition 15 auftaucht. An dieser 
Stelle bricht sie ab.

[Oliver S. (oliverso)]

Jörg W. schrieb:
> Dann wird in der Schleife so lange nach links geschoben, bis
> das höchstwertige gesetzte Bit in Bitposition 15 auftaucht. An dieser
> Stelle bricht sie ab.

Ja, das steht im C-Code.

Nur steht trotzdem im Assemblercode eine Schleife, die, falls das MSB im 
Register n nicht gesetzt ist, zur Endlosschleife wird. Jetzt kann es ja 
durchaus sein, daß der Fall "MSB nicht gesetzt" da vorher abgefangen 
wird, was dann allerdings den gezeigten Code ad absurdum führt, da 
nutzlos. Dafür müsste man halt den ganzen Code sehen.

Oliver

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

Oliver S. schrieb:
> Jetzt kann es ja durchaus sein, daß der Fall "MSB nicht gesetzt" da
> vorher abgefangen wird

Genau so ist es, das wird vorher abgefangen.

> was dann allerdings den gezeigten Code ad absurdum führt, da nutzlos

Der gezeigte Code sind doch nur aus dem Ganzen heraus geschnipselte 
Teile, wie man anhand der Adressen sehen kann. Die weggeschnittenen 
Teile werden dann schon dafür zuständig sein, die im C-Code zu sehende 
Bitschubserei zu erledigen.

[Rudi R. (microwitsch)]

Oh,hier ist viel passiert...und ich habe natürlich zwischendurch weiter 
gegrübelt und mein Programmzeug dazu klären 
können!...Reverse-"Ingenieering" ist schon eine lustige Sache!...aber 
mir sollte es hier nur helfen beide Code zu verstehen bzw. 
nachvollziehen zu können.Es werden definitiv beim Dissass zu viele 
Zwischen-Speicherungen gemacht, die man nachher im Code weglassen 
kann!Dienen wohl etwas zur Verwirrung, weil man ja die Optimierungen 
käuflich erwerben soll denke ich mal....Aber Assemler ist nach wie vor 
cool muss ich sagen, wenn man Fehler aufspüren will...erscheinen mir die 
Assembler-coder immer viel plausibler, nachvollziehbarer.Nichts desto 
Trotz ist C nachtürlich schneller zu schreiben und ein Unding, wenn man 
C nicht nutzen wollen würde.:o)...das wurde mir dann schnell bei diesem 
Beispiel hier auch klar!Habe jetzt aber beide Versionen davon...also mit 
Picas und mit XC8...nun kann ich mir das mal in Ruhe angucken und 
gegenüberstellen?Ich bin doch bestimmt nicht der Erste, der das so macht 
oder??:)

Danke für eure Beteiligung, also hier kann man schon was Fragen, hier 
gibts dann genügend die Ahnung haben!Das ist immer gut zu wissen.

[Rudi R. (microwitsch)]

Hier habe ich mal das Projekt angehangen.(Linux Mplap X IDE v5.40 mit 
Pic-as (V2.30))Es ist nicht aufgeräumt, muss ich mal ran.

Ich hatte nun aus dem Disass alles in LimbreOffice-Calc copiert und dann 
was ich für die Picas-Datei (.s) brauchte dann wieder rübercopiert.

Die "mainDissasFromMV.s" ist die Datei, die man includen muss und dann 
hat man die Assembler-Version, die ich aber noch nicht komplett 
überprüft habe!

Vielleicht mache ich das mal in der Simulation, weil ich den Controller 
nicht habe.Werde das mal versuchen für einen universelleren PIC wie 
meinen 16F18877 umzuschreiben, da lerne ich gleich wieder mit der Doku 
davon umzugehen.

Also vielleicht ist das gerade für welche, die doch mal mit den 
Pic-as-Compiler was probieren wollen und Einsteiger sind ganz hilfreich?
2925 Codezeilen sind mit der Navigation in Mplab eigentlich noch gut 
überschaubar.

Hier dazu dann auch noch das Orginal von der Seite " Simple Circuit", es 
ist eine Realtime-clock mit Alarm und Thermometer.Das Beispiel gefiel 
mir ganz gut,um mal Menue-Führungen zu studieren."Button-debounce" war 
für mich ebenfalls interessant, scheint eine Taster-Entprellung zu sein, 
werde ich auch für einen anderen Code gebrauchen 
können.[[https://simple-circuit.com/mplab-xc8-ds3231-alarm-temperature/]]

[Peter D. (peda)]

Rudi R. schrieb:
> 25:                while((divisor & 0x8000U) == 0) {
> 07C8  1BF1     BTFSC n, 0x7
> 07C9  2FD4     GOTO 0x7D4
> 07D3  2FC8     GOTO 0x7C8

Nicht Dein Ernst?
Du unterschlägst Code und behauptest dann frech, das wäre ein 
Compilerbug.
Was passiert in den Zeilen 07CA..07D2?
In einer Schleife muß immer irgendwo ein Rücksprung stehen, nur eben 
nicht direkt nach dem Testbefehl wieder zum Test.

[Rudi R. (microwitsch)]

Peter D. schrieb:
> Du unterschlägst Code und behauptest dann frech, das wäre ein
> Compilerbug.

Die zweite Frage war ja das mit "0x8000U"...wusste noch nicht was das 
"U"aussagen sollte...dadurch war der Rest für mich auch noch nicht so 
plausibel!?

Ich hatte mich gefragt,ob es ein Bug oder Falschmeldung sein sollte?
Aber hatte sich ja nun geklärt...
Deshalb hatte ich hier auch die Quelle" awdiv.c" in der Frage angegeben, 
damit jeder,der Mplab nutz, bei sich die Datei hätte aufrufen 
können...Ich meinte dass es reichen würde  aber muss ich dann wohl beim 
nächstem Mal die komplette Datei anhängen.

Was beim Disass doof ist, das alle Variablen zwischendurch wieder anders 
verwendet werden und man dann wirklich genau gucken muss, was gemeint 
ist...aber ist wohl eine Gewönungsfrage und wohl auch nix für Anfänger, 
die da erst einmal durchsehen müssen.

Ich denke mal wer C beherrscht, dem wird Disass nur noch selten 
interessieren, weil das meiste ja wohl doch hinzuhauen scheint, was der 
Compiler da zaubert.