Hur ta reda på var extra bytekod kommer från?

[bos]

Jag har en PIC-kod med bland annat följande funktion:

Kod: Markera allt

  char id;
  bit adapter_identified;
  bit adapter_unknown;

  void validate_adc(void) {
      unsigned int ADRES = (ADRESH << 8) | ADRESL;

      adapter_identified = 0;
      adapter_unknown = 0;

      if (ADRES >= VALUE_BARRIER)
        id = ID_BARRIER;
      else if (ADRES >= VALUE_REEF)
        id = ID_REEF;
      ... massa fler else if ...
      else
        id = 0;
  }

Hela koden kompileras till 283 bytes (maximal optimering påslaget) med XC8.

Om jag lägger till följande i slutet av ovanstående funktion:

Kod: Markera allt

    if (id > 0)
        adapter_identified = 1;
    else
        adapter_unknown = 1;

så växer storleken från 283 bytes till 330, enbart för att denna if-sats lagt till. Det är lite märkligt, så jag disassemblerar området:

Kod: Markera allt

  00EC  0875  MOVF id, W
  00ED  1903  BTFSC STATUS, 0x2
  00EE  28F1  GOTO 0xF1
  00EF  14F4  BSF adapter_identified, 0x1
  00F0  0008  RETURN
  00F1  1574  BSF adapter_identified, 0x2
  00F2  0008  RETURN

Endast 7 op-koder har lagts till, dvs 14 bytes.

Jag kan inte för mitt liv förstå var de övriga 33 bytesen kommer ifrån. Jag har disassemblerat båda varianter och kört en diff -u på dem, men får ingen riktig klarhet i saken.

33 bytes är väl inte hela världen, kan man kanske tycka, men det finns bara totalt 8192 bytes i ROM till programkod och det här projektet är just nu bara i startfasen, så att ödsla utrymme för saker som jag inte vet var det kommer från känns som en dum idé.

Har MPLABX nån sorts bytekod-diff eller liknande, eller hur kan jag kolla var dessa extra bytes kommer från?

[sodjan]

Säger MAP filen något intressant? Den brukar väl ha information
om de olika segmenten med storlek och var de kommer ifrån.

LIST filen är nog också smidigare att läsa än en disassemblering,
den brukar ha källkod och assemblerkod i samma lista vilket gör
att det är ganska lätt att se vad som genererar vad, så att säga.

Två listor med några hundra rader bör man kunna lägga bredvid
varandra och bara läsa igenom för hand.

[Nerre]

Ja, LIST-filen var min första reaktion också.

[bos]

Nu har jag kollat .lst-filen, tack för tipset.

Jag blir dock inte klok på vad kompilatorn sysslar i mitt fall. Den stora if-blaffan, som står i urinlägget, är exakt samma i de båda fallen. Kompilatorns .lst-fil för binären utan min extra if-rad ser ut såhär på if-blaffan:

Kod: Markera allt

 541                           ;main.c: 128: adapter_id = 1;
 542  001F  3003               	movlw	3
 543  0020  0273               	subwf	identify_adapter@ADRES+1,w
 544  0021  30C3               	movlw	195
 545  0022  1903               	skipnz
 546  0023  0272               	subwf	identify_adapter@ADRES,w
 547  0024  1803               	btfsc	3,0
 548  0025  0008               	return
 549
 550                           ;main.c: 130: adapter_id = 2;
 551  0026  3003               	movlw	3
 552  0027  0273               	subwf	identify_adapter@ADRES+1,w
 553  0028  3086               	movlw	134
 554  0029  1903               	skipnz
 555  002A  0272               	subwf	identify_adapter@ADRES,w
 556  002B  1803               	btfsc	3,0
 557  002C  0008               	return
 558
 559                           ;main.c: 132: adapter_id = 3;
 ...

Medan .lst-filen med den extra if-raden ser ut såhär:

Kod: Markera allt

 550                           ;main.c: 127: if (ADRES >= 963)
 551  0020  3003               	movlw	3
 552  0021  0273               	subwf	identify_adapter@ADRES+1,w
 553  0022  30C3               	movlw	195
 554  0023  1903               	skipnz
 555  0024  0272               	subwf	identify_adapter@ADRES,w
 556  0025  1C03               	skipc
 557  0026  282A               	goto	l637
 558
 559                           ;main.c: 128: adapter_id = 1;
 560  0027  01F5               	clrf	_adapter_id
 561  0028  0AF5               	incf	_adapter_id,f
 562  0029  28B1               	goto	l699
 563  002A                     l637:
 564
 565                           ;main.c: 129: else if (ADRES >= 902)
 566  002A  3003               	movlw	3
 567  002B  0273               	subwf	identify_adapter@ADRES+1,w
 568  002C  3086               	movlw	134
 569  002D  1903               	skipnz
 570  002E  0272               	subwf	identify_adapter@ADRES,w
 571  002F  1C03               	skipc
 572  0030  2833               	goto	l641
 573
 574                           ;main.c: 130: adapter_id = 2;
 575  0031  3002               	movlw	2
 576  0032  28AE               	goto	L14
 577  0033                     l641:
 578
 579                           ;main.c: 131: else if (ADRES >= 840)
 ...

Kompilatorn har naturligtvis en bra anledning till detta, men jag lyckas inte förstå hur det stora if-trädet kan bli så totalt diametralt olika i de båda fallen, där det enda som skiljer källkoden åt är en if-sats som testar en bit.

Om jag istället för den sista if-satsen lägger in en "gazonk = 42;" så ökar storleken med 2 opkoder (= väntat resultat), så det verkar inte ha att göra med att det finns valfri extra kod efter if-trädet, utan det är något med bit-if-satsen som gör att kompilatorn trollar på något för mig helt obegripligt vis, till bekostnad av 36 bytes extra. Till och med om jag flyttar ut bit-if-satsen ur funktionen och lägger på något annat ställe så blir det samma resultat.

Som sagt, det finns nog en bra anledning till det, men jag förstår den verkligen inte.

[TomasL]

Kan du inte posta de kompletta lst-filerna i stället för att klippa ur vad du tror är intressant, om man inte har dem så går det ju inte att svara på dina frågor.

Vill minnas att på 8-bitars PICar så kan man inte göra relativa hopp över en bank eller nått sånt, i alla fall är gränsen 256 adresser.

[bos]

Sure.

283 bytes: http://0d56105e10bd2462.paste.se/
330 bytes: http://0f701774aa921e14.paste.se/

Funktionen i fråga är "_identify_adapter".

[TomasL]

Och VARFÖR postar du inte filern här i stället, för någon jakla paste-bin tjänst.

[bos]

Du blir då aldrig nöjd med nånting.

[TomasL]

Nä, det blir lite jobbigt när man skall behöva klippa och klistra och det följer med 2000 extra rader innan koden i fråga.
Posta C-filerna också, här snälla.

[sodjan]

Ja, exakt de två C filerna som skapar de två LST filerna vore bra.
Det ser lite underligt ut... Varför listar t.ex bara den ena raderna
129, 131, 133 o.s.v.!? Finns t.ex. "if (ADRES >= 902)" i C filerna?

Går det att göra en nerskallad "reproducer" som visar samma fenomen?

Själv har jag bara den fria versionen så jag kan nog inte få samma fenomen.

[TomasL]

Jag lade upp det hela i UEdit med synkroniserad scrollning, och det verkar finnas en hel del mer C-kod i den "stora" filen, än den lilla If'en som lades till på slutet.

[lillahuset]

Ultraedit?

[TomasL]

ja, lite lat orkar inte skriva hela namnet.

[sodjan]

> och det verkar finnas en hel del mer C-kod i den "stora" filen...

I alla fall enligt LST filerna. Jag vill säga att "the jury is out" tills vi ser C filerna också...

[lillahuset]

OK, det var min favorit tills jag läste följande:
http://www.ultraedit.com/company/idm_full_story.html
Nu kan det ju hända att jag är onödigt ömhudad men det var definitivt för mycket för mig. Hellre "LuciferEdit".
Och sedan jag lärt mig behärska Emacs saknar jag inte UltraEdit.