SDCC och pic18

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
Rick81
Inlägg: 746
Blev medlem: 30 december 2005, 13:07:09

Re: SDCC och pic18

Inlägg av Rick81 »

Tror du ens på det själv?

0026  3622     LSRF maxDev, W

0027  00F2     MOVWF 0x72

0028  0872     MOVF 0x72, W

0029  00A2     MOVWF maxDev


vad i hela världen fyller MOVWF och MOVF 0x72, W för funktion här? om du nu inte kan assembler (vilket du ger intrycket av) så är har de inget med C-koden att göra och att flytta ett statiskt värde 0x72 mellan register fyller ingen funktion.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45176
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: SDCC och pic18

Inlägg av TomasL »

Läste du vad jag skrev, kompilatorn fyller på platshållare eftersom den inte har en aning om vad nästa rad C-kod skall göra.
Om man vet något hur kompilatorer jobbar, så vet man att de bearbetar koden radvis, så som i mitt exempel ovan, kommer det en if() så vet den inte om, huruvida det kommer mer kod som är beroende på raden ifråga, därför fyller den på platshållare, vilka senare tas bort vid optimeringen.
Och jo jag vet mycket väl vad asm är och vad C är.
Användarvisningsbild
Icecap
Inlägg: 26106
Blev medlem: 10 januari 2005, 14:52:15
Ort: Aabenraa, Danmark

Re: SDCC och pic18

Inlägg av Icecap »

Jag får hålla med TomasL här. Det händer ofta att ett värde dels kollas och dels räknas med och då ger mellanlagringen mening.
Mr Andersson
Inlägg: 1394
Blev medlem: 29 januari 2011, 21:06:30
Ort: Lapplandet

Re: SDCC och pic18

Inlägg av Mr Andersson »

Nej det är skräpinstruktioner som enbart finns där för att öka binärstorleken. Ingen annan kompilator än xc8 gör så, inte ens med optimeringar avstängda.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45176
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: SDCC och pic18

Inlägg av TomasL »

Och det är du 100% säker på, och har fakta på att det verkligen är så?
Mr Andersson
Inlägg: 1394
Blev medlem: 29 januari 2011, 21:06:30
Ort: Lapplandet

Re: SDCC och pic18

Inlägg av Mr Andersson »

Givetvis kan man aldrig vara 100% säker. Det kräver ju att man testat alla hemmasnickrade kompilatorer som någonsin gjorts. Men det är inte svårt att testa själv.
Ta exemplet från den länkade sidan i>>=1; och testa i valfri kompilator.
Visst finns det kompilatorer som producerar dålig kod, men mej veterligen ingen annan som lägger in helt meningslösa instruktioner.

Ditt if-exempel är bara en halmdocka då alla vet att villkorlig branching är beroende av andra instruktioner. Ovan nämnda rad är däremot helt fristående och ska inte innehålla padding.
Användarvisningsbild
swesysmgr
Inlägg: 14128
Blev medlem: 28 mars 2009, 06:56:43
Ort: Göteborg

Re: SDCC och pic18

Inlägg av swesysmgr »

Få andra kompilatorer hanterar heller den udda lösningen med separat hårdvarustack ej mappad till minnet som finns i PIC16/18?

Att reserver vissa fasta minnespositioner för att växla data mellan "overlayerna" utan att konsumera stack kan vara en anledning till att kompilatorn fluffar plats i minnet med till synes meningslösa instruktioner.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: SDCC och pic18

Inlägg av lillahuset »

Med tanke på att PICen ursprungligen (1975) var tänkt som en ren I/O-processor till GIs CP1600 och ursprungligen bara fanns som romvariant var det nog aldrig någon som ens tänkte tanken att programmera den i C.
https://en.wikipedia.org/wiki/PIC_micro ... rs#History

PIC16 är en sjuk men rolig arkitektur. PIC18 är däremot en seriöst sjuk arkitektur. Det var den som fick mig att sluta åta mig PIC-uppdrag. Inget ont som inte har något gott med sig. :D
Användarvisningsbild
swesysmgr
Inlägg: 14128
Blev medlem: 28 mars 2009, 06:56:43
Ort: Göteborg

Re: SDCC och pic18

Inlägg av swesysmgr »

PIC 18 har numera förbättrad minneshantering, vektoriserade interrupt och DMA, vad var det förutom den udda stacken du ogillade? Programmerar man i C tycker jag den i praktiken fungerar som de flesta andra 8-bitare.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45176
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: SDCC och pic18

Inlägg av TomasL »

Mr Andersson skrev:Givetvis kan man aldrig vara 100% säker. Det kräver ju att man testat alla hemmasnickrade kompilatorer som någonsin gjorts. Men det är inte svårt att testa själv.
Ta exemplet från den länkade sidan i>>=1; och testa i valfri kompilator.
Visst finns det kompilatorer som producerar dålig kod, men mej veterligen ingen annan som lägger in helt meningslösa instruktioner.

Ditt if-exempel är bara en halmdocka då alla vet att villkorlig branching är beroende av andra instruktioner. Ovan nämnda rad är däremot helt fristående och ska inte innehålla padding.
Nja, mina "if-exempel" var bara just ett exempel, alla kompilatorer stoppar in platshållare lite här och där i koden, skillnaden är väl snarare hur mycket som optimeras bort. Hitec-C optimerar uppenbarligen inte bort nånting.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: SDCC och pic18

Inlägg av lillahuset »

swesysmgr: Det var första generationen PIC18 och vi var tvungna att använda både C och assembler. Jag minns inte exakt vad det var som störde mig.
Rick81
Inlägg: 746
Blev medlem: 30 december 2005, 13:07:09

Re: SDCC och pic18

Inlägg av Rick81 »

TomasL:
Om du nu är så säker på din sak, kan väl du bevisa det?

Ser inte riktigt vad du hänger upp dig på, oavsett så generar ju kompilatorn en massa konstiga skräpinstruktioner som tar flash och gör koden långsammare. Sen om det är avsiktligt eller bara en sunkig kompilator spelar mindre roll.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45176
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: SDCC och pic18

Inlägg av TomasL »

Dessutom så säger ju microchip i klartext att kompilatorn i den fria versionen genererar kod som är 50 till 100% större än betalversionerna.
Sunkig kompilator, ja troligen är det så.
Bevisligen så genereras ren massa skräpkod i alla kompilatorer efter kompilering, dock i de flesta finns det någon form av optimering per default, i en del kan man även stänga av denna optimering, och i en del är optimeringen permanent, vilket städar upp mycket av de onödiga instruktionerna.
Sen om man med vilje lagt till en massa skräp i Hitech-C (XC8) låter jag naturligtvis vara osagt, men troligen är det helt enkelt så att den är sunkig i sitt fria utförande.
(Det brukar straffa sig om man gör på detta sättet, se exempelvis Microchips svar om de första pickit 3orna som kom ut Eller dieselgate, eller andra liknande händelser)
Dessutom hittar man bara ett par tre länkar om att Hitech-C (XC8) med vilje skulle skräpa ned, det verkar snarare vara så att de flesta är överens om att den genererar totalt o-optimerad kod, till skillnad från de flesta andra kompilatorer.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: SDCC och pic18

Inlägg av lillahuset »

Jag köpte tidigt en Hitech-C för PIC16 för ganska stora pengar (i mitt lilla företags värld) och studerade genererad assemblerkod. Jag var djupt imponerad och då hade jag ändå skrivit rätt mycket assembler för PIC16. Själva kompilatorn tror jag inte det är något större fel på, däremot processorns arkitektur, men optimeringen kanske är vital för bra resultat. Och vem vet, det kanske finns en funktion för att lägga till onödig kod också.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45176
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: SDCC och pic18

Inlägg av TomasL »

Med optimeringar påslagna skall det vara en rätt bra kompilator, dock den verkar inte supporta PIC18 Extended instruction set, efter vad jag förstår.
Skriv svar