warning in SDCC (pointer target lost const qualifier)

[Thomas Z. (usbman)]

ich baue gerade eine SDCC variante von einem meiner Programme (C51)

Der code läuft ohne Fehler / Warnungen unter Keil durch. Beim SDCC 
erhalte ich in einem Modul die Warnung "pointer target lost const 
qualifier" finde aber kein Problem an der Stelle.

code ist per macro nach __code umdefiniert, damit der SDDC zufrieden 
ist.
pdescr ist ein ein ptr der neben der Addresse auch die Speicherklasse 
enthält (3 byte ptr). Ich benutze den pointer später für memcpy.

...
uint8_t  *pDescr;        /**< pointer to a descriptor part */
...
extern code uint8_t DevDesc[];
...

void HandleUsb(void)
{
   ...
   case USB_DEVICE_DESCRIPTOR:
        pDescr = &DevDesc[0]; //<-- warning
        len    = DevDesc[0];
        break;  
   ...
}

kennt jemand das Problem? Vorläufige Tests ergeben keine Fehlfunktion, 
ich habs nur nicht so gerne wenn ich warnings bekomme.

[g457 (Gast)]

lass mir raten: __code impliziert const, dann..

const uint8_t* pDescr;

HTH

[Thomas Z. (usbman)]

g457 schrieb:
> lass mir raten: __code impliziert const, dann..

mm muss ich in der SDCC Doku nachlesen, keine Ahnung aber die Idee ist 
gut.
Danke schon mal.

Edit:
Volltreffer das wars.
Da sind doch glatt alle 5 Warnings weg. In der Doku hab ichs allerdings 
auf die Schnelle nicht gefunden.

[Thomas Z. (usbman)]

Ich muss den Thread noch mal hochholen, da mir ein meiner Meinung nach 
ein schwerer Bug in Verbindung mit den Interrupt Vektor Tabellen 
aufgefallen ist.

Ich hoffe einfach mal dass Philip hier mitliest.

Es gibt Fälle wo Interrupt Funktionen nicht in die Vektor Tabelle 
eingetragen werden.

Das Handbuch sagt:
"If you have multiple source files in your project, interrupt service 
routines can be present in any of them, but a prototype of the isr MUST 
be present or included in the file that contains the function main."

Ok kann man so machen, dann sollte aber der Linker zumindest eine 
Warnung werfen, Wenn es Interrupt Funktionen gibt die keinen Eintrag 
haben. Zusätzlich baut der Compiler bei unbenutzten Einträgen ein RETI 
ein.
Auch das ist ok allerdings gibt es Chips die wesentlich mehr Vektoren 
haben dort fehlt dann das RETI.

Ich hatte das bisher nicht bemerkt, weil meine Interrupt Funktionen 
bisher immer im Main File waren.

Das machen Keil und IAR aber auch Wickenhäuser besser.

[Philipp Klaus K. (pkk)]

Thomas Z. schrieb:

> Ich hoffe einfach mal dass Philip hier mitliest.

Wobei ich kaum am mcs51-Port arbeite. Andere (insbesondere Maarten) 
kennen sich da besser aus. Du könntest auf der sdcc-user-Liste 
schreiben, oder ein Ticket 
(https://sourceforge.net/p/sdcc/_list/tickets) öffnen.
Einen Bug sehe ich hier allerdings nicht, auch wenn die aktuelle Lösung 
nicht so benutzerfreundlich ist, wie man es sich wünschen würde.

[Thomas Z. (usbman)]

Philipp Klaus K. schrieb:
> Einen Bug sehe ich hier allerdings nicht, auch wenn die aktuelle Lösung
> nicht so benutzerfreundlich ist, wie man es sich wünschen würde.

Ich gebe zu das Bug wahrscheinlich etwas übertrieben ist. Tatsächlich 
wird man das vermutlich nur bemerken wenn man code von anderen Compilern 
portiert. Keil kann man ja auch anweisen keine Interrupt Tabelle 
anzulegen, dort werden dann aber auch kein RETI erzeugt. Ich hab das 
sogar mal gemacht und die Tabelle dann per ASM Modul erzeugt.

Ich hatte bei mir 3 IRQs T2irq (0x002B) USBIrq(0x0043) und 
UART1Irq(0x0053). Uart und T2 in einem extra file, USBIrq in main.

Der T2Irq wird einfach gleich beendet da der Eintrag fehlte und das RETI 
zum tragen kommt. Da der UARTIrq hinter den üblichen Vectoren lag fehlte 
das RETI mit dem Ergebnis dass beim ersten Rx oder Tx das Programm 
wieder im Startup landete.  --> Absturz

Diese RETI sind weitgehend nutzlos und dann kann man sie auch weglassen 
und den Platz für reguläre Funktionen nutzen (Keil macht das so)
Eine Deklaration der IRQs im Mainfile behebt das, ist allerdings 
wiederum nicht Syntax kompatibel mit Keil was ein weiteres #ifdef 
__SDCC_mcs51 braucht.

[Thomas Z. (usbman)]

Ich hatte in der Eröffnungspost geschrieben, dass ich den pointer für 
memcpy benutze. Nun habe ich allerdings bemerkt dass dies beim SDCC in 
Verbindung mit __using ziemlich ineffektiv ist.
Ich benutze memcpy im Usb_Irq auf der Registerbank 1. Wegen memcpy wird 
dann im Interrupt zusätzlich der komplette Registersatz R0..R7 von RB0 
auf den Stack gepushed. Das passiert bei Keil nicht.

Da ich immer nur 8 Bytes kopiere hab ich das dann in einer Schleife 
manuell gemacht und schon waren die Pushs für RB0 weg. Das läßt mich 
vermuten, dass SDCC nicht die Lib Funktionen kennt, und deshalb 
vorsichtshalber mal alles auf den Stack legt.

[Philipp Klaus K. (pkk)]

Thomas Z. schrieb:
> Ich hatte in der Eröffnungspost geschrieben, dass ich den pointer für
> memcpy benutze. Nun habe ich allerdings bemerkt dass dies beim SDCC in
> Verbindung mit __using ziemlich ineffektiv ist.
> Ich benutze memcpy im Usb_Irq auf der Registerbank 1. Wegen memcpy wird
> dann im Interrupt zusätzlich der komplette Registersatz R0..R7 von RB0
> auf den Stack gepushed. Das passiert bei Keil nicht.
>
> Da ich immer nur 8 Bytes kopiere hab ich das dann in einer Schleife
> manuell gemacht und schon waren die Pushs für RB0 weg. Das läßt mich
> vermuten, dass SDCC nicht die Lib Funktionen kennt, und deshalb
> vorsichtshalber mal alles auf den Stack legt.

Der MCS-51-Port war der Anfang von SDCC. Er arbeitet noch immer 
zuverlässig, und generiert brauchbaren Code, gefundene Bugs werden 
üblicherweise in angemessener Zeit behoben.
Wenn ich den MCS-51 Port allerdings mit den Z80 und STM8 Ports 
Vergleiche, fällt schon auf, dass ersterer inzwischen etwas 
Nachholbedarf hat:
In der Tat generiert SDCC für MCS-51 zur Zeit oft ineffizienteren Code 
als andere Compiler. Bei STM8 ist es andersrum.

[Thomas Z. (usbman)]

Philipp Klaus K. schrieb:
> Wenn ich den MCS-51 Port allerdings mit den Z80 und STM8 Ports
> Vergleiche, fällt schon auf, dass ersterer inzwischen etwas
> Nachholbedarf hat:
> In der Tat generiert SDCC für MCS-51 zur Zeit oft ineffizienteren Code
> als andere Compiler.

dem würde ich widersprechen. Ich beobachte den SDCC jetzt schon einige 
Jahre und er hat über die Zeit deutlich zugelegt. Das die Code 
Generierung etwas schlechter als bei anderen Compiler ist sehe ich nicht 
als Problem an.

Nach meiner Erfahrung sind das so 15..20% damit kann man leben. Wegen 
des gewählten Weges bei der Parameter Übergabe an Funktionen wird sich 
das vermutlich auch nicht mehr wesentlich ändern. Ich würde mir 
allerdings an einigen Stellen eine ausführlichere Dokumentation 
wünschen.

Aktuell suche ich einen Bug der nur beim SDCC auftritt nicht aber unter 
Keil. (bei gleichen Quellen) Ich bin mir relativ sicher, dass der im 
Zusammenhang mit nicht atomic Zugriffen auf Variablen verursacht wird 
und im Zusammenhang mit einer volatile struct steht. Der Zugriff auf die 
struct (im data seg) ist in SDCC etwas umständlicher als in Keil.