SDCC till PIC?

[TomasL]

Eller PIC32, Mycket imponerande liten prolle, som klarar det mesta.

[blueint]

Hur MIPS kompatibel är PIC32 egentligen? t.ex. med Texas Instruments TI-AR7 ..?

[TomasL]

Tja, MIPS är ju kärnan precis som ARM, och tillverkarna måste ju följa standarden för kärnan, dock kan de implementera valda delar av kärnan.
Men kompatibel måste den vara, dvs funktionerna och instruktionerna skall vara samma.

[blueint]

Om man implementerar MIPS som VHDL/Verilog bryter man mot något patent/copyright eller är den fri ..?

[TomasL]

Vet ej, kolla på MIPS hemsida.
ALternativt om det finns nån kärna hos nån av kretstillverkarna.

[dangraf]

Jag pratar om instruktions-cykler.
Du skulle kunna testa skriva följande kod i C18

Kod: Markera allt

 uint32 var =0x12345678;
 var >>=8;

som för mig tar 93 klockcykler vilket jag tycker är på tok för mycket medan

Kod: Markera allt

 uint32 var =0x12345678;
 var <<=8;

bara tar 13 cykler.

Tack för länken!

[TomasL]

Men åter till trådskaparens problem.
Alla kompilatorer har mer eller mindre egenheter för sig, MCC18 tillhör väl en av de mer buggfria till PIC-världen.

Dina problem med, vad du tror är ineffektivitet beror troligen på fel angreppsätt av problemet, till exempel varför skifta ett 32-bitars ord 16! gånger, när du ändå kommer åt samma värde genom att läsa av de två högsta Byten, samma gäller med in 8-bitars skift, då är det de tre höga byten som är gällande.

Ett vanligt sätt att hantera multi-byte variabler i en 8-bitars-miljö är att göra en union/strukt av dem så man på ett enkellt sätt kan komma åt de individuella byten.

Dina problem med varningar, beror på att MCC är petig i överkant, vilket iofs är rätt bra då det tvingar fram bättre kod.

Ett typexemplel är från en av dina tidigare poster, där jämförelse mellan en variabel och en "inline" konstant ger en varning, vilket är naturligt, då kompilatorn inte vet om din konstant är unsigned eller inte, då den inte är definerad i koden.

Vidare behöver du förklara om du menar "klockcykler" eller "Instruktions-cykler" vilket är två helt skilda saker (det går 4 klockcykler på en instruktionscykel"

Fortfarande, verkar du blanda ihop det även efter föregående inlägg

[TomasL]

Jag pratar om instruktions-cykler.
Du skulle kunna testa skriva följande kod i C18

Kod: Markera allt

 uint32 var =0x12345678;
 var >>=8;

som för mig tar 93 klockcykler vilket jag tycker är på tok för mycket

Javisst det ÄR ju en 8-bitars processor, när du högerskiftar måste den hålla reda på bit 0 som skiftas bort, för att sedan stoppa in det som högsta biten i byten under, alla kompilatorer gör på exakt samma sätt, vilket naturligtvis måste generera en del mer kod.

Kod: Markera allt

 uint32 var =0x12345678;
 var <<=8;

bara tar 13 cykler.



Tack för länken!

Naturligtvis, när du vänsterskiftar sparas den mest signifikanta biten i Carry-flaggan, vilket på ett enkelt sätt kan hanteras och läsas in i nästkommande högre byte.
Du måste lära dig hur instruktionsuppsättningen ser ut i en PIC18 för att förstå vilka begränsningar/fördelar som finns tillgängligt.

Återigen, det finns ingen anledning att hålla på att skifta hela byte, det finns smartare sätt.

[TomasL]

Ett litet tillägg, om du hade läst instruktionsuppsättningen till PIC18 så hade du notert att det INTE finns några skiftoperationer, utan detta måste utföras med en uppsättning "Rotate" operationer plus lite annat därtill.

Kompilatorn gör nog så gott den kan, med tanke på den begränsade uppsättning instruktioner som finns tillgängligt.

Samtidigt, (ar nu kört dina exempel) är resultatet från min kompilering

Kod: Markera allt

:                 	var1 >>=8;
  00EE    CFD9     MOVFF 0xfd9, 0xfe9
  00F0    FFE9     NOP
  00F2    CFDA     MOVFF 0xfda, 0xfea
  00F4    FFEA     NOP
  00F6    0E08     MOVLW 0x8
  00F8    6EE7     MOVWF 0xfe7, ACCESS
  00FA    90D8     BCF 0xfd8, 0, ACCESS
  00FC    0E03     MOVLW 0x3
  00FE    32EB     RRCF 0xfeb, F, ACCESS
  0100    0E02     MOVLW 0x2
  0102    32EB     RRCF 0xfeb, F, ACCESS
  0104    0E01     MOVLW 0x1
  0106    32EB     RRCF 0xfeb, F, ACCESS
  0108    32EF     RRCF 0xfef, F, ACCESS
  010A    06E7     DECF 0xfe7, F, ACCESS
  010C    E1F6     BNZ 0xfa
6:                 	
7:                 	var2 <<=8;
  010E    50D9     MOVF 0xfd9, W, ACCESS
  0110    0F04     ADDLW 0x4
  0112    6EE9     MOVWF 0xfe9, ACCESS
  0114    CFDA     MOVFF 0xfda, 0xfea
  0116    FFEA     NOP
  0118    50EF     MOVF 0xfef, W, ACCESS
  011A    6AEE     CLRF 0xfee, ACCESS
  011C    CFEF     MOVFF 0xfef, 0xff4
  011E    FFF4     NOP
  0120    6EEE     MOVWF 0xfee, ACCESS
  0122    50EF     MOVF 0xfef, W, ACCESS
  0124    CFF4     MOVFF 0xff4, 0xfee
  0126    FFEE     NOP
  0128    6EEF     MOVWF 0xfef, ACCESS

[dangraf]

Om du vill hålla dig till ursprungsämnet får du väldigt gärna berätta om dina erfarenheter kring SDCC.

Grattis för att du övertalat dig själv om att C18 är en så fantastisk kompilator.

Kring shift problematiken så BEHÖVS det inte någon som helst shift operation egentligen för operationen var>>=8; det räcker med 3 kopieringar samt att man nollställer den mest signifikanta byten. Carrie-flaggan struntar jag fullständigt i som C-programmerare, det går inte att komma åt den med något kommando.

Visst, det går att använda unions och structs OM MAN ALLTID VET EXAKT VAD KOMPILATORN GÖR, vilket man inte alltid vet på samtliga ställen i koden. Därför finns det ett gäng kod-standards som inte tillåter att man använder unions. Detta för att en 16 eller 32 bitars processor "paddar" ut en strukt till jämnt antal bytes som den arbetar med. Dessutom kan man råka i onåd med big och little-endian.

[TomasL]

Visst, men du kan inte räkna med, oavsett hur ansi kompatibel eller duktig en kompilator är, att du skal kunna använda samma standard på en 8-bitars processor som en 32-bitars och räkna med att du får optimalt resultat.

Orsaken är enkel, det finns en begränsad mängd resurser. Vilket gör att man alltid måste tillgripa en del knep, för att kunna utnyttja det man har.
8-bitarskod kan i princip aldrig bli porterbar, utan mycket handpåläggning.

Nej jag har inte övertalat mig själv, dock har resultaten vi får ut gjort det.