Dessa fria begränsade kompilatorer

[stekern]

Nu är jag inte expert på vad denna optimering gör, men -Os ska man använda om man har ont om flashminne. Vill man istället göra snabb kod tar man någon annan optimering. -O3 ser lite konstig ut - den ökar på kodstorleken med 25% ... antagligen optimerar den maximalt för hastighet. Och det kostar i utrymme.

Att mer aggresiv optimering gör att koden växer är inget konstigt, loop unrolling, aggresiv inlining etc tar givetvis plats.

[sodjan]

> Att mer aggresiv optimering gör att koden växer är inget konstigt...

En mer aggresiv optimering "for speed", ja.
Om switcharna gäller en mer aggresiv optimering "for size" så gäller ju inte det.
Då vore det väldigt konstigt om koden växer...

> Det ska nog tolkas som andel utnyttjat minne i processormodellen som projektet använde.

Ja, det var även min tolkning av meddelanderna.
Men då förstår jag inte uttrycket att "den ökar på kodstorleken med 25%".
25% mer än vilken kodstorlek då?

Men att alla %-satser gäller rellativt det tillgängliga minnet på den aktuella
processorn är väl den mest rimliga tolkningen...

[jesse]

Det kanske blev lite förvirrande. "ökar med 25%" - då menar jag i förhållade till kodstorleken ooptimerad. Procentsatserna är i förhållade till flashminnets storlek, i det här fallet 65536 bytes. Jag bara kopierade siffrorna direkt. Nu råkar den ooptimerade koden ta upp 99.1% av processorns minne, så man kan ju använda procentsiffrorna direkt för att kolla ungefär hu mycket optimeringen gör. Ooptimerad kod är både stor och långsam. Tar ofta mer än dubbelt så lång tid att köra.

Jag gör ett körtest också, och skriver upp antalet processorcykler som gått sedan reset på vissa punkter i programmet.

Kod: slumpvist valt stort projekt. innehåller timade loopar och en hel del interrupt.
Kör i Atmel Studio simulator.

Kod: Markera allt

ooptimerad
kodrad					Δ (100%)
A   802	 start				10332	
B   899	 efter init		 18953	  8621
C   968	 mer init			2453679	2434726
D   1228	Loop (1)			2595721	142042
E   1248	efter funktion	2628489	32768
F   1228	Loop (2)			2803831	175342
G   1248	efter funktion	2815926	12095
			
-Os	Δ 	%	
A   10332			
B   18801	  8469	   98%	
C   1216895	1198094	49%	
D   1404771	187876	 132%	
E   1422871	18100	  55%	
F   1602559	179688	 102%	
G   1620659	18100	  150%	
			
-O1	Δ 	%	
A   10332			
B   18799	  8467	   98%	
C   1235241	1216442	50%	
D   1405005	169764	 120%	
E   1420694	15689	  48%	
F   1602644	181950	 104%	
G   1618333	15689	  130%	
			
-O2	Δ 	%	
A   10332			
B   18800	  8468	   98%	
C   1159819	1141019	47%	
D   1207379	47560	  33%	
E   1220761	13382	  41%	
F   1405017	184256	 105%	
G   1418399	13382	  111%	
			
-O3	Δ 	%	
A   10334			
B   18790	  8456	   98%	
C   982951	 964161	 40%	
D   1008833	25882	  18%	
E   1021171	12338	  38%	
F   1206630	185459	 106%	
G   1218968	12338	  102%	
			

Kommentarer:

Varje rad är ett programstopp på en specifik plats i programmet. Första sifferkolumnen är antalet klockcykler sedan reset. Andra kolumnen är skillnaden mot föregående stopp. Tredje är skillnaden i förhållande till ooptimerad kod. Exempel:

-O3 , rad C:
982951 cykler sedan reset. 964161 cykler sedan breakpoint B. Tiden mellan B och C tog 40% vid -O3 jämfört med ooptimerad kod.


A hit kommer processorn efter att ha initierat t.ex. globala variabler mm. Samma oavsett optimering.
B Efter initiering av diverse register och portar. Här blir optimeringen bara 2% och det beror väl på att det inte kan optimeras så mycket.
C Efter ett antal initieringsrutiner, bl.a. SPI, UART, ladda dynamiska data från EEPROM, flash, utskrift 'hello world' ungefär mm...
D inne i huvudloopen. Hit kommer programmet först efter att viss tid gått (timerstyrda interrupt som räknar upp)... dock verkar det ju ske vid väldigt olika tidpunkter..
E efter att ha anropat ett par funktioner som i huvudsak bara går igenom en mängd data och gör diverse beräkningar.
F och G --- samma som D och E, fast andra varvet.

Intressant att F -> G tar mycket längre tid om koden är optimerad. Antagligen någon timer-effekt som jag inte riktigt kan se. Det 'borde' vara ren successiv kod tycker jag men jag kanske har missat något (det är tusentals rader kod)...

Extra kommentar: jag avaktiverade alla "delay" och liknande (gjorde "dummy-funktioner istället). Jag avaktiverade även sändning av UART - istället för att fylla bufferten och sedan ligga och vänta på att den ska tömmas så satte jag dit ett 'return' i början av UART_TX-funktionen, så den gör ingenting. Annars hade stor del av tiden gått åt till att vänta på utskriftsbufferten.

[stekern]

> Att mer aggresiv optimering gör att koden växer är inget konstigt...

En mer aggresiv optimering "for speed", ja.
Om switcharna gäller en mer aggresiv optimering "for size" så gäller ju inte det.
Då vore det väldigt konstigt om koden växer...

Givetvis, men nu var det ju gcc det var frågan om, som bara har en inställning för
optimering med betoning på storlek. Dessutom så var det ju -O3 som det var frågan om,
så det var ju underförstått.

[Gizmo]

Det vore intressant att se lite fler jämförelser mellan olika språk för pic, finns ju standardspråken assembler och C, men det finns ett par alternativ däribland ett som jag tycker verkar trevligt JAL2 (just another language) som är lite pascal-liknande. Värt att nämna kanske även är picbasic eller den fria varianten great cow basic. Dock, bägge är väl för hobbyister och kanske inte för mer seriösa arbeten.

Sedan undrar jag varför man ska använda en processor som gör att man kanske riskerar att slå i taket för vad processorns minne/resurser klarar av? Det är väl bättre att ha lite takhöjd än att slå i taket?

[Icecap]

Gizmo: Att använda språk utan en klar standard är, i professionella sammanhang, självmord. Projekt har en förmåga att expandera så att man bygga en grej som kan <något> och alla är glada.

Sedan vill man kanske även ha med <något annat> och det går fortfarande, alla är fortfarande glada.

När detta ska uppgraderas vill man göra ytterligare ett tillägg men just denna processor klarar inte jobbet och en annan processorfamilj har en specifik hårdvara som kan vara en stor hjälp så det är "bara" att portera koden dit, då är alla glada.

Och då kommer problemet: Med JAL, PBP, BASIC eller liknande är algoritmerna sannolikt helt enkla att omskriva MEN:
- Man ska just omskriva hela programmet.
- Det ska debuggas för alla skrivfel.
- Det ska testat från grunden.

Har man ett programmeringsspråk som har en standard kan man i stort rakt av använda koden. Såklart blir det omskrivning av hårdvarunära delar men resten kan sannolikt användas direkt.

Vissa av mina projekt delar källkodfiler mellan PIC och PC-program, alltså bokstavligen delar samma fil.

För en hemmapysslare med mer ambition att få det att fungera än att sälja/utveckla duger vilket programmeringsspråk som helst så länge jobbet blir utförd pålitligt och stabilt, hur enkelt man kan portera källkoden till andra processorfamiljer har ringa betydelse.

[sodjan]

> Det är väl bättre att ha lite takhöjd än att slå i taket?

Bättre och bättre, det är ju helt vanliga designbeslut som man
som en duktig utvecklare inte ska ha några problem med att ta.

För hobbybruk så kan man så klart lika bra välja den "största"
modellen i den aktuella familjen. För volymproduktion vill man
snarare ha "rätt kostym" och inte ha oanvänt minne i onödan,
d.v.s extra kostnader utan nytta.

Så det går inte att svara entydigt på din fråga, it depends...

[AndLi]

Oftast är anledningen till att ligga på gränsen kronor och ören, kanske inte om du producerar några tusen enheter, men får du lite volym på produkten kan en besparing på 10 öre per µC betyda ganska mycket på sista raden. Även om det kräver några dagars extra kodande för att få det att funka...

I hobby projekt borde man alltid ta i rejält...

-Jag var visst lite långsam...

[Krille Krokodil]

Det vore intressant att se lite fler jämförelser mellan olika språk för pic, finns ju standardspråken assembler och C, men det finns ett par alternativ däribland ett som jag tycker verkar trevligt JAL2 (just another language) som är lite pascal-liknande. Värt att nämna kanske även är picbasic eller den fria varianten great cow basic. Dock, bägge är väl för hobbyister och kanske inte för mer seriösa arbeten.

Känner man för att uppfinna hjulet på nytt så... Jag menar, vadän för gizmo du hittar och vill koppla på din uC så är chanserna stora att du kan hitta ett färdigskrivet bibliotek till den i C, det är en ofantlig mängd människor som sitter och knackar saker i det språket. Samt att om man kan C som ett rinnande vatten så har man ett försprång till att lära sig C++ och dess varianter, en dag kanske man vill göra något i WinDOS, Android, IOS, Linux, OSX etc. eller Java.

[Icecap]

Kan bara hålla med KK: ska man ändå lära sig ett språk som är hyggligt objektorienterat i betydelsen att man bygger funktioner, då kan man likaväl lära sig ett universellt språk som C.

Jag har tidigare fipplat med BASIC (därför att jag är allergisk mot det nu) och senare Pascal. Och Pascal'en var en snabb ingångsport till C, det var ju i grunden samma struktur på det hela.

Sedan har jag lekt med CiCode, PLC-programmering på SioX och en massa annat där strukturen i stort har varit likadan.

JAL och PBP är evolutionärt en död väg att gå.

Visst kan man utföra jobbet med dessa språk men vad om jobbet kräver att man t.ex. ska stega upp ett projekt gjort i PBP från PIC18 till PIC24 eller PIC32?
Då håller man sig ju inom processorfamiljen men måste ändå skaffa en annan kompiler och skriva om programmet till det språk, det finns ju ingen PBP till PIC24+.

JAL vill jag inte ens sia om, det är nog än mer dött.

[Glenn]

Ja, och det är ju självklart att man ju köpa ett trumset för 320000 spänn till sitt barn, hur ska han någonsin kunna spela på de stora arenorna annars ? risken finns ju att han fastnar med att banka på kastruller om man låter honnom leka med dom som tvååring..

*SUCK*

Varför har folk så OERHÖRT svårt att förstå att för de allra flesta så är INTE målet att jobba med sin hobby, och då är argumentet att man inte kan "stega upp" fullkomligt irrlevant, ofta känns det lite som att det är nåt mantra som det tjatas om efterssom det inte finns riktiga argument att ta till.

Dessutom är det ju även helt felaktigt, i praktiken är det "tänket" som är viktigast när man programmerar, ju fler språk man kan desto lättare är det att lära sig ett annat.

[jesse]

Eller så gör man en hobby av att pressa in så mycket som möjligt i en så liten processor som möjligt. Det lär man sig säkert en hel del på också
Phasor by lft (Video och musik skapad med en ATMega88)

[Gizmo]

Jag menar, vadän för gizmo du hittar och vill koppla på din uC så är chanserna stora att du kan hitta ett färdigskrivet bibliotek till den i C

Du har säkert rätt. Jag får gå på nånslags mental kurs för att tycka att C är "snyggt". Ja jag vet, det här är inte logiskt, men jag avskyr alla klammrar och hakparanteser, det bär mig emot. Det ser fult ut för mitt öga. Assembler är snyggt, men lite för omständligt, pascal är nog det språk jag trivs bäst i. Ja, jag vet, det här är lyxtänkande, och nej jag arbetar inte som programmerare, just for fun är väl en bra summering.

[bearing]

Du får göra en .h-fil med en massa #defines, vilka gör att syntaxen ser mer estetisk ut, kanske som Pascal.

Kod: Markera allt

#define Begin {
#define End;  }

#define If  if(
#define Then  )

[vfr]