Frage zu Disassemblinglist

[Rudi R. (microwitsch)]

---  C:/Users/Admin/CH8-Demo1.X/mcc_generated_files/interrupt_manager.c  --------------------------------

            #include "interrupt_manager.h"
            #include "mcc.h"
                        
                       void __interrupt() INTERRUPT_InterruptManager (void)

    BSF 0x7FE, 0x0
    MOVLP 0x0                                            
    MOVLB 0xE       // interrupt handler / if(PIE0bits.IOCIE == 1 && PIR0bits.IOCIF == 1)
    BTFSS PIE0, 0x4
    GOTO 0xA
    GOTO 0xB
    GOTO 0x1D
    BTFSS PIR0, 0x4
    GOTO 0xE
    GOTO 0xF
    GOTO 0x1D           
    MOVLB 0x0      // if(IO_RA3_GetValue())
    BTFSS PORTA, 0x3
    GOTO 0x13
    GOTO 0x14
    GOTO 0x17      
    BSF LATD, 0x2    // IO_RD2_SetHigh();
    GOTO 0x19
    GOTO 0x19                
    BCF LATD, 0x2    // IO_RD2_SetLow();
    GOTO 0x19                          
    MOVLB 0x3E       // IOCAFbits.IOCAF0 = 0;
    BCF IOCAF, 0x0              
    GOTO 0x1D                   // else
    GOTO 0x1D
    BCF 0x1F7E, 0x0
    RETFIE

Hallochen,

Dieser Code hier war in der Dissassembling, ich will hier nur wissen 
wohin diese GOTO´s gehen?
Hexadezimal stimmen sie jedenfalls nicht mit den Registern in den Bänken 
überein!Welches Register wird hier vom GOTO angepeilt?

[Irgend W. (Firma: egal) (irgendwer)]

Rudi R. schrieb:
> Dieser Code hier war in der Dissassembling, ich will hier nur wissen
> wohin diese GOTO´s gehen?
Bist du dir sicher, dass das wirklich ein Dissassembling von einem 
Programm ist?
Was soll denn das für eine merkwürdiger Prozessor sein? ich habe noch 
keine asm- Mnemonik gesehen wo es ein "goto" gibt, die heißen eigentlich 
fast immer jump oder so ähnlich?

Für mich sieht das ganze irgendwie mehr nach einem assembler listing aus 
das als Zwischencode von einem c-compiler erzeugt wurde. Da dürfte es 
sich um einen fiktiven Sprungbefehl zu fiktiver Adresse innerhalb dieser 
Datei handeln (also die erste Zeile ist quasi Adresse 0x00 usw.) Diese 
werden dann später vom linker in echte jumps umgerechnet, wenn er die 
ganzen Dateien zu einem Ergebnis zusammenfügt.

[michael_ (Gast)]

Und mehrere GOTO hintereinander machen gar keinen Sinn.
Bitte das nächste Salami-Scheibchen.

[Hp M. (nachtmix)]

Rudi R. schrieb:
> ich will hier nur wissen
> wohin diese GOTO´s gehen?

Dann hättest du mal den Prozessor nennen und den Hexdump zeigen sollen.

[foobar (Gast)]

Das ist irgendein PIC.  Da gibt's GOTO und die Condition-Tests skippen 
die nächste Instruktion oder nicht, ein "BTFSS GOTO GOTO" ist nichts 
anderes als ein if-then-else.    Merkwürdig sieht der Code aber schon 
aus - automatisch generiert ohne auch nur ein fitzelchen Optimierung.

Der Parameter vom GOTO ist an sich direkt die Zieladresse.  Adressen 
sind in dem Listing aber nicht zu sehen ...

[Lotta . (mercedes)]

Eigendlich müsste ein Disassembler vor die
ensprechenden Befehle den entsprechenden Code
stellen.
Das kann man auch irgendwo einstellen.

Schau nach, ob dein Disasssembler ne Symboltabelle
ausspuckt!
Spiele mit dem Kommandozeilenprompt!

mfg

[BetaTest (Gast)]

Solchen Codeverhau erzeugt der Compiler, weil sein Herrchen
zu geizig ist, ein paar Kullerchen für die Lizenz abzudrücken.

Selber schuld!

[Chregu (Gast)]

foobar schrieb:
> ein "BTFSS GOTO GOTO" ist nichts anderes als ein if-then-else.

Aber 3 GOTOs hintereinander...?

Gruss Chregu

[Rudi R. (microwitsch)]

BetaTest schrieb:
> Solchen Codeverhau erzeugt der Compiler, weil sein Herrchen
> zu geizig ist, ein paar Kullerchen für die Lizenz abzudrücken.
>
> Selber schuld!

Das könnte durchaus möglich sein!:(

Ich dachte erst es wären die Speicherplätze,die hier automatisch mit den 
vor der Routine zu speichernden Daten bestückt werden, um sie danach 
wieder abzuarbeiten!?

[Einer (Gast)]

Chregu schrieb:
> Aber 3 GOTOs hintereinander...?

Das scheint so eine Art break zu sein.
1D ist wohl die Adresse vom RETFIE.

[Rudi R. (microwitsch)]

Irgend W. schrieb:
> Für mich sieht das ganze irgendwie mehr nach einem assembler listing aus
> das als Zwischencode von einem c-compiler erzeugt wurde. Da dürfte es
> sich um einen fiktiven Sprungbefehl zu fiktiver Adresse innerhalb dieser
> Datei handeln (also die erste Zeile ist quasi Adresse 0x00 usw.) Diese
> werden dann später vom linker in echte jumps umgerechnet, wenn er die
> ganzen Dateien zu einem Ergebnis zusammenfügt.

Ja,das ist doch eine Disassebling!?

Haben sie vielleicht mal eine Disassembling von Ihnen?
Würde mich mal interessieren, wie das richtiger weise aussehen müsste.
Das Programm dazu funktioniert aber in meinem Fall!...

Ich will es halt versuchen nachzuvollziehen, was da passiert, weil mir 
das Codegewusel da zu lang und uneffizient erscheint.

Also kann man sich die Sprünge da auch wegdenken, weil sie nur der 
Zusammenführung vom Linker dienen??

Danke;o)

[Rudi R. (microwitsch)]

michael_ schrieb:
> Und mehrere GOTO hintereinander machen gar keinen Sinn.
> Bitte das nächste Salami-Scheibchen.

Zumindest ein Goto könnte übersprungen werden, wenn ein entsprechender 
Sprungbefehl davor liegt.

Ähm,ich bin noch neu in diesem Gebiet, vielleicht gibt es sowas?
Garade das fand ich ja auch so eigenartig...also das Programm dazu 
funktioniert jedenfalls.:)

[Andras H. (kyrk)]

Ist das der HI-Tech compiler? Oder schon MCC? Oder XC8?

[Rudi R. (microwitsch)]

ähm das ist MCC...sorry war ne weile nicht aktiv hier...im Sommer 
weniger Zeit und Muse für sowas,deshalb!;o)...jetzt gehts gerade 
weiter...besser als Fernsehgucken und so ein Zeug ne...:)

[Erich (Gast)]

Du solltest versuchen, eine höhere Optimierrungsstufe des Compilers 
einzusetzen.
Statt 0 zumindest 1.
Gruss

[Blame4Lame (Gast)]

michael_ schrieb:
> Und mehrere GOTO hintereinander machen gar keinen Sinn.

Doch, nennt sich Sprungtabelle:

https://de.wikipedia.org/wiki/Sprungtabelle

[Hugo H. (hugo_hu)]

Rudi R. schrieb:
> Welches Register wird hier vom GOTO angepeilt?

Keines, das sind absolute Adressen.

[Volker S. (vloki)]

Rudi R. schrieb:
> Dieser Code hier war in der Dissassembling, ich will hier nur wissen
> wohin diese GOTO´s gehen?

Sieht aus wie der vom XC8 in der FREE Version generierte Code ohne jede 
Optimierung. Wenn man sich nicht die Dateien, sondern den 
Programmspeicher in der IDE anschaut, dann sieht man auch noch, an 
welcher Adresse die Befehle stehen und damit auch wohin die GOTOs 
springen.