SDCC compiler " Warning"

bprosman

Golden Member

Aangezien ik atijd ben van 'Een warning is er niet voor niets" heb ik hier een stukje code waarbij de SDCC compiler "piept"

firmware.c:218: warning 230: label without statement

Keil, vind het prima en zegt er verder niets van.

De jongere generatie loopt veel te vaak zijn PIC achterna.
eSe

Honourable Member

Als er geen case "gevonden" word dan word de "default" uitgevoerd. Maar je hebt geen instructie na de default, dus 'warning'. Je mag dit label weglaten als je geen default nodig hebt.
En die laatste break is ook niet nodig, je bent toch al aan het einde :-)

Groetje,
eSe

[Bericht gewijzigd door eSe op vrijdag 14 mei 2021 17:25:28 (16%)

CChheecckk yyoouurr dduupplleexx sswwiittcchh..

Die laatste break zou ik laten staan, anders krijg je weer warnings, (en problemen als je ooit iets in de default gaat zetten.

En na de default: moet ook een statement, minstens een break;

In de default case gewoon ook een break zetten.
-edit- deKees was net wat sneller.

[Bericht gewijzigd door henri62 op vrijdag 14 mei 2021 18:02:30 (28%)

1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
eSe

Honourable Member

En na de default: moet ook een statement, minstens een break;

Of gewoon een ";", dat is ook een statement, een leeg maar een geldige.

Groetjes,
eSe

CChheecckk yyoouurr dduupplleexx sswwiittcchh..

Op 14 mei 2021 17:11:57 schreef bprosman:
Keil, vind het prima en zegt er verder niets van.

[bijlage]

Andere compiler nemen. (of configuratie aanpassen)

bprosman

Golden Member

Op 14 mei 2021 21:03:33 schreef ohm pi:
[...]Andere compiler nemen. (of configuratie aanpassen)

Ben op programmeergebied zeker geen ster maar de code gegenereerd door de Keil (8051) compiler heeft mij nog nooit rare zaken opgeleverd, sinds een paar dagen aan het spelen met SDCC.

De jongere generatie loopt veel te vaak zijn PIC achterna.

De code is op zich niet fout, en er gebeuren ook geen rare dingen.

Maar toch, het ziet er uit alsof er een stukje code vergeten is, dus dan is het wel terecht dat de compiler daarvoor een waarschuwing geeft.

En als Keil er niks van zegt, dan zou het me niks verbazen dat die er wel een compiler switch voor heeft om hiervoor alsnog een waarschuwing te geven.

Meestal gebruik ik zelf '-Wall' om alle warnings aan te zetten, maar ik heb hier geen Keil compiler om dat te proberen.

EricP

mét CE

Op zich is die warning natuurlijk terecht: je definieert een default, maar je doet er niks in. Dan kun je die default net zo goed weg laten... (alhoewel ik het goed gebruik vind om een switch een default te laten hebben). Net als deKees: zet alle warnings maar gewoon aan. En handle ze ook als error. Die ene enkele keer dat je iets doet wat echt zo moet en waar de compiler toch over struikelt (zo heeeeeeel soms heb je dat met embedded wel eens), dan kun je dat met #PRAGMA doorgaans prima weg werken: zeg tegen de compiler: zeur in deze 10 regels even niet over warnings #xxx. (onder het motto: hier is over nagedacht).

Vroeger veel met SDCC gewerkt voor 8051. Dat heeft nooit 'nare' code opgeleverd - als in 'dit klopt niet'. Wel een paar situaties waardoor ik er met een debugger op assembly niveau naar heb zitten kijken. En dan denk je als je ziet wat de compiler er van bakt... Gezien de architectuur en de taal is het een logische oplossing: PEBKAC.

bprosman

Golden Member

Ik zal de default netjes afsluiten met een break en eens bij de Keil instellingen kijken. Het is overigens code van Elektuur (SMD oven controller).

De jongere generatie loopt veel te vaak zijn PIC achterna.

Op 14 mei 2021 17:24:34 schreef eSe:
Als er geen case "gevonden" word dan word de "default" uitgevoerd. Maar je hebt geen instructie na de default, dus 'warning'. Je mag dit label weglaten als je geen default nodig hebt.

Mijn advies: Lekker laten staan.

Doordat je de default expliciet opschrijft documenteer je in de code dat je er over hebt nagedacht als geen van de eerdere case statements actief wordt. Verder is de waarschuwing dus: Je hebt een plekje waar naar toe gesprongen kan worden, maar d'r staat niets om te doen. Zoals voorgesteld waarschijnlijk zal een ; of een break de waarschuwing doen verdwijnen.

De laatste break kan je weghalen. Maar weer: Ik zou het niet doen. De kans dat je ooit nog een extra case toevoegt is aanwezig. Als daar dan een "gaat door naar de volgende" instaat in het stukje code waar je niet in geinteresseerd bent dan kan dat weer tot een fout in de code lijden. Waarschijnlijk krijg je een waarschuwing over de fallthrough, maar strict genomen: Het is hartstikke legale C-code om die fallthrough te gebruiken. Als 1 van je compilers dan besluit daar geen waarschuwing op te geven of je zit even in een fase in je project dat je moet accepteren dat er even een zwik waarschuwingen zijn, dan kan het zijn dat je het niet ziet en je weer een tijd aan het debuggen bent voordat je hem gevonden hebt.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Op 14 mei 2021 22:16:58 schreef bprosman:
[...]
Ben op programmeergebied zeker geen ster maar de code gegenereerd door de Keil (8051) compiler heeft mij nog nooit rare zaken opgeleverd, sinds een paar dagen aan het spelen met SDCC.

Keil genereerd voor de 8051 wel degelijk efficienter code dan SDCC.

1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.

Keil is toch gewoon onderwater gcc ?

Die doet tegenwoordig behoorlijk diepe analyses met het uit loops halen van constanten, het volgen van variabelen en zo. Ik zie hem er voor aan dat als je de eerste 100 getallen optelt

code:

for (i=0,t=0;i<=100;i++)t += i;

hij dat vereenvoudigd tot t=5050; Eigenlijk dacht ik dat ik iets aan het overdrijven was...

code:


        movl    $5050, %esi
        leaq    .LC0(%rip), %rdi
        xorl    %eax, %eax
        call    printf@PLT

Nope!

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
bprosman

Golden Member

De jongere generatie loopt veel te vaak zijn PIC achterna.
Anoniem

Op 15 mei 2021 08:34:40 schreef bprosman:
Ik zal de default netjes afsluiten met een break en eens bij de Keil instellingen kijken. Het is overigens code van Elektuur (SMD oven controller).

Om de bijbel K&R er even bij te pakken:

From The C programming language - Second edition (K&R 2):

Chapter 3.4 Switch

As a matter of good form, put a break after the last case (the default here) even though it's logically unnecessary. Some day when another case gets added at the end, this bit of defensive programming will save you.

Met andere woorden het hoeft niet, maar het is verstandig om het te doen. Vandaar ook de melding.

bprosman

Golden Member

Om de bijbel K&R er even bij te pakken:

From The C programming language - Second edition (K&R 2):

Zal m ook weer eens uit het stof trekken :-)

De jongere generatie loopt veel te vaak zijn PIC achterna.
EricP

mét CE

Keil genereer voor de 8051 wel degelijk efficienter code dan SDCC.

Ik denk dat je grosso-modo daar gelijk in hebt. Echter, als dat ZO belangrijk is, dan laat ik het niet meer op de optimization van m'n compiler aankomen - dat kan als ik ergens een paar regels code verander opeens anders uit pakken. Dan schrijf ik het wel in assembly...

Ik koop voor ontwikkelen de grote CPUs met lekker veel flash. Als ik dan ga produceren, kijk ik of het nog in de kleine past (met wat marge voor firmware aanpassingen) en koop ik de kleinere. Ik let niet/nauwelijks op code-size. En het is dus wel fijn dat de compiler wat helpt om m'n code klein te houden.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/

Op 15 mei 2021 11:25:39 schreef EricP:
[...] Dan schrijf ik het wel in assembly...

Success ermee.
Ik heb lang geleden best veel met de Keil compiler op de 8051 (of derivaten) gedaan. En wat er uit kwam was vaak efficienter/compacter als wat je handmatig in assembly zou doen.

Ik heb constructies gezien wat de compiler afleverde aan code die je zelf niet bedacht zou hebben. Knap werk van de compiler.

1-st law of Henri: De wet van behoud van ellende. 2-nd law of Henri: Ellende komt nooit alleen.
EricP

mét CE

Ik heb lang geleden best veel met de Keil compiler op de 8051 (of derivaten) gedaan. En wat er uit kwam was vaak efficienter/compacter als wat je handmatig in assembly zou doen.

Och... Ik heb heeeel lang geleden ook wel wat 8051 assembly gedaan (eigenlijk meer dan me lief is... ;) ). En ja, soms wat het machine cycles tellen om die kant op te optimaliseren. Niet zelden 'write only' code (in de hoek van: als we nou deze volgorde van instructies aanhouden, dan garandeert dat dat we dit niet hoeven te clearen (of setten). Scheelt weer een cycle).

Ik heb constructies gezien wat de compiler afleverde aan code die je zelf niet bedacht zou hebben. Knap werk van de compiler.

Er is niks op tegen om als uitgangspunt de genereerde code te nemen. En die verder voor specifiek jouw situatie verder te optimaliseren hoor. Beter goed gejat dan slecht zelf verzonnen tenslotte :).

Optimizen kan naar 'size' en naar 'speed'. Beiden is niet zelden tegenstrijdig. Echter, als je een beetje kunt programmeren is 'size' meestal niet het probleem (en ja, er zijn altijd situaties waar je niet aan 'proppen' ontkomt. Meestal veroorzaakt door een stropdas).
Meeste wat er uiteindelijk in gefrot wordt (als je de vrijheid heb om 'gewoon wat aan te schrijven) zijn op die manier toch bijna altijd libraries. Geschreven door een ander en afhankelijk van de herkomst van wisselende kwaliteit.