Guten Abend,
folgender Code führt, sofern das Projekt für PIC18 erzeugt wird, zum
aufhängen des ASPIC18.EXE (Teil des XC8) (Build dauert unendlich lange).
Sobald der Prozessor auf PIC16 oder PIC12 geändert wird, funktioniert
der Build-Prozeß.
1
#include <xc.h>
2
3
void main(void)
4
{
5
unsigned char a, b;
6
7
for (a = 0; a <= 32; a++)
8
{
9
b++;
10
}
11
12
while(1);
13
14
return;
15
}
Lasse ich die for-Schleife weg oder ersetze while(1); durch
while(1){b=a;} läuft der Build durch.
Seltener Fehler im ASPIC18?
XC16 und XC32 haben kein Problem mit dem Code, nur XC8 in Verbindung mit
PIC18
Hallo Vierauge,
auf microchip forum wurde das Problem auch gepostet, zur Info:
http://www.microchip.com/forums/m934265.
Streng genommen gehört das Thema in "Compiler & IDEs" rein
Unsinniger Code wird selten zum Compilertest genommen und kann daher gut
den Compiler durcheinander bringen.
Man könnte sogar sagen, das ist ein Feature, d.h. der Compiler sagt Dir
durch die Blume, Du hast Bockmist verzapft.
Sobald Du b initialisierst (lokale Variablen sind bei Eintritt
unbestimmt), muß der Code aber durchlaufen.
Dass der obige Code unsinnig ist weiß ich selber. Obiger Code ist ja nur
die eigentliche Ursache, warum ein ursprünglich größerer, durchaus
sinnvoller Code den Compiler zum hängen gebracht hat (Inititialisierung
der Peripherie in main(), Code nur im Interrupt, daher leere
while(1)-Schleife). Code wurde von nem PIC16 auf nen PIC18 migriert.
Falls es jemand interessiert: V1.35 hat kein Problem, V1.37 nur in den
Optimierungsstufen Free und Standard, Pro läuft hingegen, wobei es in
den Free & Standard-Stufen wohl in der standardmäßig aktivierten
Assembleroptimierung liegt (+asm hängt, -asm läuft). In V1.38 wird der
Bug behoben sein.
Vierauge schrieb:> Obiger Code ist ja nur> die eigentliche Ursache, warum ein ursprünglich größerer, durchaus> sinnvoller Code den Compiler zum hängen gebracht hat
Dann zeig dochmal Code, der hängt obwohl er keine unbestimmten Ausdrücke
enthält.
Der oben gezeigte Code ist deshalb unbestimmt, weil b bei der Verwendung
(b++;) nicht initialisiert ist und sowas ist erstmal ein Fehler des
Programmierers.
Nur globale Variablen werden per default mit 0 initialisiert.
Peter D. schrieb:> Dann zeig dochmal Code, der hängt obwohl er keine unbestimmten Ausdrücke> enthält.
Egal, wie unsinnig der Code ist, der Compiler hat sich davon nicht
aufzuhängen. Die Überschrift ist ja etwas schlecht formuliert, es
geht ja wohl nicht darum, dass der Zielprozessor irgendwie Mist macht,
sondern der Compiler (steht im Eingangsposting dann jedenfalls so).
anstandslos durch den Compiler läuft
Das Problem liegt aber wie bereits genannt in der Optimierungsfunktion
des erzeugten Assemblercodes des XC8 und dort auch nur in bestimmten
Konstellationen (V1.37, PIC18, Free o. Standard-Optimierung). Es ist
also kein genereller Code um Compiler ins Schwitzen zu bringen.
Wurde von Microchip auch als Antwort auf mein Ticket bestätigt
