Compilieren in die andere RIchtung?

[Memby]

Hallo,

habe ein schönes Programm mit Bascom geschrieben und in den Atmega8 geladen. Leider mein ganzes Verzeichniss mit dem Programm auf meiner Festplatte gelöscht. (Unwiederruflich!).

Meine Frage: Das Programm bekomme ich ja ohne Probleme aus dem Flasch, mit Bascom oder auch Pony Prog. Doch kann ich jetzt das Programm von .hex nach .bas oder .c oder ähnliches kompilieren,
da ich es noch verändern möchte.

Wenn Nein, warum und was passiert den beim Compilieren genau?

MfG
memby

[super_castle]

Schau mal unter Decompiler für Hex-Dateien für AVR.
Dann kannst du dieses wenigstens mit AVR-Studio bearbeiten und evtl die ASM-Befehle zurückverfolgen zum Umsetzen in Basic.
Nach Bas und C kannst du es zur Zeit nicht zurückwandeln aber in ASMSource-Code.

Castle

[Marco78]

Nein.

Wenn Nein, warum und was passiert den beim Compilieren genau?

Weil der Code von Bascom in Assemblerbefehle "umgewandelt" wird. Wie schon gesagt wurde, kannst du denn Code wiederherstellen. Aber um es in Basic zu übersetzen fehlt es an Programmen. Schon alleine deshalb, weil es zu aufwendig wäre sowas umzuwandelt.
Vielleicht ein verständliches Beispiel:
Als Rechenergebnis hast du eine 5. Wie lautet die Rechnung dazu?

[super_castle]

Es ist machbar, das Zurückumwandeln in Bascom.
Das Programm kann aber nur der Bascomhersteller erstellen, weil er den Weg kennt. Es ist genauso einfach, als wenn man ein abgewickelten Bindfaden wieder aufwickeln tut. Nichts ist unmöglich.
Nur die Nachfrage für solch ein Programm ist zu gering.

Bei "C" ginge es nicht, weil der C-Compiler Teile wegoptimieren kann. Und beim Rückwärtsfahren, fehlen dann die Optimierungen in der Hexdatei und hat dort Luftlöcher.

Castle

[Marco78]

Ich habe ja auch nicht gesagt, das es nicht geht!
Es gibt halt (noch) kein Programm, was das kann. Weil es kein Bedarf dafür gibt. Soetwas zu programmieren ist schon fast aufwendiger als Bascom selbst zu programmieren.

Das Programm zum Rückwandeln bräuchte dann das was bei meinem Beispiel (Rechnung mit 5) auch nötig wäre. Zwei Vorgaben wie man zur Lösung kommt.

Um es deutlich zu sagen. So ein Programm gibt es (sehr höchst wahrscheinlich) nicht. Falls doch wäre das hier bestimmt schonmal aufgetaucht.
Um dein Programm zu ändern musst du Assembler lernen. Was man ja in der Regel nicht vor hat(te) wenn man (wie ich auch) sich für Bascom entschieden hat.
Selbst wenn du es lernst, fehlen im Code einige Kommentare, die das verstehen leichter machen würden. Heute ASM lernen und morgen schon den Code ändern geht nicht einfach so.

[super_castle]

Um mit Bascom meine Flashcard anzusprechen, musste ich ASM lernen.
Sonst hätte ich es nicht geschafft, meine 128MB mit Bascom anzusprechen.
Ich musste die "Lib" anpassen, sonst ging es nicht.
Es macht jetzt so einen riesen Spass, die "Lib" für Bascom mit ASM zu schreiben. Auch eine "Lib" für ein grafisches Display (256x12 habe ich umgeschrieben in ASM.

Castle

; CF-Register addresses

.equ Data_Reg = &H00
.equ Error_Reg = &H01
.equ Feature_Reg = &H01
.equ Sec_Cnt_Reg = &H02
.equ Sec_Num_Reg = &H03
.equ Cyl_Lo_Reg = &H04
.equ Cyl_Hi_Reg = &H05
.equ Head_Reg = &H06
.equ Status_Reg = &H07
.equ Command_Reg = &H07


; Commands for Compact Flash Card

.equ CF_Identify = &HEC
.equ CF_Write_Sec = &H30
.equ CF_Read_Sec = &H20


;------------------------------------------------------------------------------
[_DriveGetIdentity]
$EXTERNAL _CF_Write_Reg
; Read Identity Info from the CF-Card
_DriveGetIdentity:
   ldi r21, 1         ; 512 Bytes = 1 Sector to read
   ldi r23, CF_Identify         ; Command for Card identity
   rcall _CF_Write_CommandReg       ; send to card
   rjmp _CF_Read_Sector_LBASet      ; Read Info to SRAM (mit return)
[End]



[_CF_Check_Ready]
; Pin CF_Rdy is Low at Ready
_CF_Check_Ready:
 * sbis CF_Control_In , CF_Rdy ; no timeout check
   rjmp _CF_Check_Ready
   Ret
[END]



[_CF_Write]
$EXTERNAL _CF_Check_Ready
; give a pulse to WE to force Compactflash Card to read Data
; Registeraddress (A0-A2) and Data (D0-D7) must be set
_CF_Write:
   rcall _CF_Check_ready
 * cbi CF_Control_Out , CF_WE ; WE Line to Low
   ; Pulse is for Crystal 16 MHz, Approximitly 1 NOP for 2 MHz
   ; and can be reduced for slower CPU
   nop
   nop
   nop
 * #IF _XTAL > 6000000
   nop
   nop
   nop
 * #ENDIF
 * #IF _XTAL > 12000000
   nop
   nop
 * #ENDIF
 * sbi CF_Control_Out , CF_WE ; WE Line to High
   ret
[END]



[_CF_Read]
$EXTERNAL _CF_Check_Ready
; Read 1 Byte from the CF
; Register address must be set.
_CF_Read:
   rcall _CF_Check_Ready
   ldi _temp1, &H00            ; change data-port to Input
 * out Cf_Data_DDR , _temp1
 * cbi CF_Control_out , CF_OE ; OE Line to Low
   nop
   nop
   nop
 * #IF _XTAL > 6000000
   nop
   nop
   nop
 * #ENDIF
 * #IF _XTAL > 12000000
   nop
   nop
 * #ENDIF
 * in r23 , CF_Data_in ; Read Byte
 * sbi CF_Control_Out , CF_OE ; OE - Line to High
   ldi _temp1, &HFF            ; change Data-port back to OUTPUT
 * out CF_Data_DDR , _temp1
   ret
[END]


[_CF_Set_RegAddr]
; Set register address, and leave pins 3 - 7 unchanged
; two entry-points to routine
; 1: CF_Set_RegAddr: Register address must passed in r22
; 2: CF_Set_RegAddr23: register address is Data
_CF_Set_RegAddr23:
   ldi r22, Data_Reg
_CF_Set_RegAddr:
 * in _temp1 , CF_Addr_Out ; get current output at Port
   andi _temp1, &B11111000         ; CF-Address-bits masked out
   or _temp1, r22            ; add CF-Address with OR
 * out CF_Addr_Out , _temp1
   ret
[End]



[_DriveReadSector]
$EXTERNAL _CF_Set_CntLBA , _CF_Write_Reg , _CF_Read
; Read Sector(s) from CF-Card to SRAM
; Entry with following parameters set:
; Register r21: Count of Sector(s) to transfer
; Register X: Pointer to Sectornumber (LONG)
; Register Z: SRAM-Address, where the data to transfer
_DriveReadSector:
   ldi r21, 1         ; fixed to 1 sector to read
   rcall _CF_Set_CntLBA          ; LBA-Sector to CF
   ldi r23, CF_Read_Sec         ; read command
   rcall _CF_Write_CommandReg       ; to Compactflash
_CF_Read_Sector_LBASet:
   rcall _CF_Set_RegAddr23       ; turn register-address to data
   clr r20            ; Low-Byte of Byte-Count always zero
   lsl r21           ; Change Sector-Count to HighByte of Transferlenght
_CF_Read_Sector1:
   rcall _CF_Read              ; read 1 Byte
   st z+, r23
   dec r20
   brne  _CF_READ_SECTOR1
   dec r21
   brne  _CF_READ_SECTOR1         ; all bytes read?
   clr r25                          ; set default no error
   clc
   Ret
[END]



[_DriveWriteSector]
$EXTERNAL _CF_Set_CntLBA , _CF_Write_Reg
; write Sector(s) to CF-Card
; Entry with following parameter set:
; Register r21: Count of sector(s) to transfer
; Register X: Pointer to Sectornumber (LONG)
; Register Z: SRAM-Address, at which Data to transfer starts
_DriveWriteSector:
   ldi r21, 1         ; fixed to 1 sector to write
   rcall _CF_Set_CntLBA          ; LBA-Sector to CF
   ldi r23, CF_Write_Sec         ; write command
   rcall _CF_Write_CommandReg       ; to compactflash
_CF_Write_Sector_LBASet:
   rcall _CF_Set_RegAddr23       ; turn register-address to data
   clr r20            ; Low-Byte of Byte-Count alwas zero
   lsl r21           ; Change Sector-Count to HighByte of Transferlenght
_CF_Write_Sector1:
   ld r23, z+
 * out CF_Data_out , r23 ; Byte to data port
   rcall _CF_Write             ; force CF to read byte
   dec r20
   brne  _CF_Write_SECTOR1
   dec r21
   brne  _CF_Write_SECTOR1         ; last byte written?
   clr r25                           ; set default no error
   clc
   Ret
[END]



[_CF_Write_Reg]
$EXTERNAL _CF_Set_RegAddr , _CF_Write
;------------------------------------------------------------------------------
; write a value to a specified register address, value is passed in r23
; two different entry points
; 1: CF_Write_CommandReg: write value to command-register (default)
; 2: CF_Write_Reg: Register passed in r22
_CF_Write_CommandReg:
   ldi r22, Command_Reg        ; Default register: Command
_CF_Write_Reg:
 * out CF_Data_out , r23 ; set data to data port
   rcall _CF_Set_RegAddr         ; set register address
   rjmp _CF_Write              ; force CF to accept register and data
[End]



[_CF_Set_CntLBA]
$EXTERNAL _CF_Write_Reg
; Write count of sector(s) (read or write) and Sectornumber (LBA) to CF-Card
; following parameter must be set:
; Register CF_SectorCount: Count of Sector(s) (max &7F)
; Register X: Pointer to sectornumber
;
_CF_Set_CntLBA:
   ldi r22, Sec_Cnt_Reg        ; Start with Sector-Count Register in CF (2)
   mov r23, r21       ; prepare for output
   rjmp _CF_Set_LBA2
_CF_Set_LBA1:
   ld r23, X+               ; load next byte of sectornumber
_CF_Set_LBA2:
   rcall _CF_Write_Reg           ; set register-address
   inc r22               ; set to next register address
   cpi r22, 6
   brmi  _CF_Set_LBA1            ; Reg. 6 reached? (LBA/Disk/Header)
   ld r23, X+               ; need special handling
   andi r23, &B00001111         ; mask upper nibble (LBA-Sign and drive)
   ori r23, &HE0             ; set to LBA
   rjmp _CF_Write_Reg            ; write to CF; incl Ret
[END]



[_DriveInit]
$EXTERNAL _DriveReset
; Setup the pins needed for the CF-Card
_DriveInit:
   ; Data port to OUTPUT
   ldi _temp1, &H00            ; all Data pins to low
 * out CF_Data_Out , _temp1

   ldi _temp1, &HFF
 * Out CF_Data_DDR , _temp1 ; Data pins to output

   ; Controlport: prepare 6 pins, leave other two unchanged
 * in _temp1 , CF_Control_Out ;
 * andi _temp1 , CF_Control_Dir_Mask ;
 * ori _temp1 , CF_Control_Init
 * Out CF_Control_Out , _temp1

 * in _temp1 , CF_Control_DDR ; read direction of pins at control port
 * andi _temp1 , CF_Control_Dir_Mask ; mask out used pins
 * ori _temp1 , CF_Control_Direction ; set direction in and Out
 * Out CF_Control_DDR , _temp1 ; set new direction configuration

   ; Address port: attention: adjust if not on Port C at ATMega103
   ; ATMega103 Port C have only output, so here no configuration is necessary
 * in _temp1 , CF_ADDR_DDR
   ori _temp1, &B00000111
 * Out CF_Addr_DDR , _temp1
   ; waitms 1
*BASIC:WAITMS 1
;   ldi r24, 1
;   clr r25
;   call _Waitms ; 1 ms delay
   rjmp _DriveReset
[End]



[_DriveReset]
;------------------------------------------------------------------------------
; force CF-Card to a Hardware-reset
_DriveReset:
 * sbi CF_Control_Out , CF_Reset
   ; waitms 1
   ldi r24, 1
   clr r25
   call _waitms ; 1 ms delay
 * cbi CF_Control_Out , CF_Reset
   ;  waitms 500
   clr r24
   ldi r25, 2
   call _waitms ; 512 ms delay
   clr r25                      ; set default no error
   clc
   ret
[End]



[_DriveCheck]
;------------------------------------------------------------------------------
; Checks, whether Card is plugged in: Pin CD1 is LOW
; if OK r24 = 1; otherwise 0
_DriveCheck:
   clr r25
   clc
 * sbis CF_Control_In , CF_CD1 ; flashcard plugged in
   ret
 * ldi r25 , cpErrDriveNotPresent
   sec
   ret
[END]

[recycle]

@Marco78

Es gibt halt (noch) kein Programm, was das kann. Weil es kein Bedarf dafür gibt.

Naja, dass es keinen Bedarf für Decompiler gibt würde ich nicht behaupten.
Ich denke schon, dass eine ganze Menge Leute und Firmen für einen Decompiler der ihnen aus jedem beliebigen Programm die Quelltexte rekonstruiert ein paar Euro springen lassen würden

In Java ist das z.B. auch problemlos möglich. Bei einem guten Decompiler sieht der decompilierte Quelltext mitunter besser aus als das Original.
Dass es in Java so gut geht, liegt aber wohl daran, dass Java nur Bytecode und keinen Maschinencode generiert.

Ansonsten hast du natürlich recht. So einfach wie man Texte vom englischen ins deutsche und wieder zurück übersetzen kann, wird das bei Quelltexten die man compilert micht gehen.


@super_castle

Auch der Bascom Compiler dürfte beim Compilieren einige Optimierungen vornehmen.
Es wäre jedenfalls nicht besonders geschickt, wenn Bascom den knapp bemessenen Speicher eines µC mit langen Variablen und Funktionsnamen usw. vollpumpt.
Bei einigen Bascom-Anweisungen, z.B CONST und ALIAS steht sogar drin, dass sie keinen Speicher belegen. (weil der Compiler an den esntprechenden Stellen einfach den Namen durch den Wert der Konstanten ersetzt.
Wenn im decompilierten Quelttext nur Variabelnnamen, Funktionsnamen, Konstanten usw. fehlen würden, wäre der Quelltext zwar noch brauchbarere aber nicht mehr besonders gut lesbar.

Der Hersteller von Bascom wird glaube ich genauso wie die meisten anderen Hersteller von Programmiersprachen gar kein grosses Interesse haben, dass man seine Sprache decompilieren kann.
Die meisten Kunden wären davon sicher wenig begeistert, denn dann könnten sie ihre Quelltexte ja auch gleich im Web veröffentlichen.

[SprinterSB]

Wenn du avr-gcc verwendet hast, kommst du evtl an die Quelle dran, wenn du ein asm mitgeneriert hast (*.s) oder ein Precompile (*.i). Dann siehst du evtl, aus welcher Quelle das asm erstellt wurde.
Evtl geht es auch, wenn du noch das elf (*.elf) oder die Objekte (*.o) hast und Debug-Info erzeugt hast (Option -g).

Eine erhellende C-Quelle aus asm oder hex zu generieren ist nicht möglich.
asm kennt keine Variablennaben, Dinge können wegoptimiert worden sein, Makros sind aufgelöse, Funktionen können geinlinet worden sein, Schleifen können aufgerollt worden sein, Konstanten gefaltet, toter Code wurde eliminiert, Blöcke umsortiert ... und noch 1000 andere Dinge können passiert sein, bevor du dein hex aus ner Quelle bekommst.

[PicNick]

SprinterSB, ganz so schlimm ist es auch nicht. Ich hab mich einigermassen mit dem reverse-engineering beschäftigt, die BasCom- Source läßt sich aus der Assembler-Source recht gut erkennen, da Bascom ja immer die gleichen Muster liefert. Aber insofern hast du recht, es bleibt eine Schweinearbeit und Precompiler-Sachen (z.B Const /Alias) lassen sich natürlich nicht rekonstruieren.

[Hellmut]

Nur so als Kommentar am Rande. Es macht als Programmierer von Kode für uC eine Menge Sinn sich vertraut zu machen wie der vom eingesetzten Compiler erzeugte Kode aussieht. Immer dann wenn Teile des Kodes zeitkritisch oder platzkritisch sind erwege ich den Nutzen diese Teile durch Assembler Kode zu ersetzen. Im Unterschied zur Programmierung für z.B. PC Programme, hat man im uC knappen Speicher und beschäftigt sich mehr mit Echtzeitproblemen.