Moin, gibt es eine Möglichkeit, "kompilierten" asm-Code in ein Programm einzubinden? Also ich meine den Opcode mit Inhalt, wie z.B. 931f einem "push R17" entsprechen würde. Wenn ich also an einem definierten Bereich anfange: .cseg .org $030 und da unter einem Label code hinlege: code: .dw 931f, 932f,... und das ganze dann aufrufe mit call code Haut mir das um die Ohren, oder würde das gehen??? Viele Grüße, Ozzy
Soviel ich weiß sind Adressen teilweise absolut hinteregt, z.B. bei JMP und CALL. Damit die Einbindung funktioniert, müsstest du alles über relative Sprünge machen, also ausschließlich RJMP und RCALL in dem eingebundenen Code verwenden. Dann sollte es gehen.
Schätze mal daß Dein Vorhaben gelingt, wenn - nur relative Sprünge verwendet werden, - bei den .dw xxyyy - Anweisungen darauf geachtet wird, daß die Reihenfolge der Bytes eingehalten wird! Meines Wissens wird bei ".dw" erst das low, dann das high-Byte angenommen, screibe hat ".db" und die Bytes danach. Vorteil bei ".dw" immer gerade Anzahl an Bytes, bei ".db" muß man wg. gerader Byteanzahl aufpassen, ggf. mit einem 0x00-Byte auffüllen.
Moin,
vielen Dank für Eure Antworten! Also ich habe das mal ausprobiert,
und es scheint wirklich gut zu funktionieren. Das mit den relativen
Sprüngen ist natürlich eine gute Sache, dann brauche ich ja eigentlich
keine festen Adressen, unter denen die Unterprogramme liegen...
Vielen Dank noch einmal,
Ozzy
Also.... damals... beim Apple II (6502 Processor) hat man das auch so gemacht. Der hatte, glaube ich, 5 Stück Slots für Erweiterungsboards. Jeder Slot hatte aber einen eigenen Adressbereich. Damit die selbstgebaute Karte aber in jedem beliebigen Slot funktioniert musste der Code eben relativ sein. Gruss k.
Hi Trotzdem ist die Methode von Oz zy (ozzy) Unsinn. Das Ganze lässt sich wesentlich unkryptischer mit einem Macro erledigen. MfG Spess
Moin, es geht aber genau um dieses kryptische. Ich möchte Code vorgeben der allerdings nicht (ohne weiteres) lesbar/veränderbar ist. Klar kann man das auch wieder lesbar machen, aber es soll das ganze erschweren. Da helfen mir auch keine Macros...
... du willst also ein Plugin ? Dan reicht ja auch ein HEX-Block ohne wirkliche Funktion. Einfach eine 256 byte grosse Ziffernfolge als Prüfsumme. Gruss k.
Moin, ne, es geht um ein Programmierpraktikum. Die Leute sollen etwas programmieren, aber manchmal ist es eben schwierig Fehler zu lokalisieren. Deshalb möchte ich meinen Code als backup-Lösung nehmen können. Da die Leute die Fehler in dem entsprechenden Unterprogramm selber finden sollen und nicht einfach plump die Lösung kopieren ohne nachzudenken, soll die Backup-Lösung nicht einfach lesbar sein...
Oz zy schrieb: > Moin, > > es geht aber genau um dieses kryptische. Ich möchte Code vorgeben der > allerdings nicht (ohne weiteres) lesbar/veränderbar ist. Klar kann man > das auch wieder lesbar machen, aber es soll das ganze erschweren. Da > helfen mir auch keine Macros... Das macht es aber nicht. Es kommt das Gleiche dabei rum. Es bereitet nur dir Arbeit. Die Formatierung deines Quelltextes und mehr ist das nicht wird einen Kopierer wahrscheinlich nichmal auffallen.
Hi >es geht aber genau um dieses kryptische. Ich möchte Code vorgeben der >allerdings nicht (ohne weiteres) lesbar/veränderbar ist. Muss man das jetzt verstehen? >Klar kann man >das auch wieder lesbar machen, aber es soll das ganze erschweren. Da >helfen mir auch keine Macros... Wem willst du etwas erschweren? Hoffentlich nicht irgend welchen Schülern. Außerdem kann man damit nichts erschweren. Die Hexdatei von deinem Programm über einen Disassembler laufen lassen und schon ist dein Aufwand für die Katz. MfG Spess
Der Ansatz wäre dann im Praktikum nachzufragen ob die mit der Aufgabe zu vermittelten Inhalte aufgenommen sind. Sprich zu den Lösungen mal ein oder 2 Fragen stellen. Das prüft dann auch, ob nicht einfach vom Nachbarn übernommen/vom Partner geschrieben worden ist.
spess53 schrieb: > Die Hexdatei von deinem > Programm über einen Disassembler laufen lassen und schon ist dein > Aufwand für die Katz. Das ist nun auch nicht richtig. Wenn man passende Füllbytes einbaut ist der Disassembler auch im Arsch. Der Disassembler orientiert sich ja am erwarteten Alignment. Klaus
Hi >Das ist nun auch nicht richtig. >Wenn man passende Füllbytes einbaut ist der Disassembler auch >im Arsch. Der Disassembler orientiert sich ja am erwarteten >Alignment. Ich habe das so verstanden, das er funktionierenden Code einbauen will: >.cseg >.org $030 >und da unter einem Label code hinlege: >code: .dw 931f, 932f,... >und das ganze dann aufrufe mit >call code Das wird wohl nicht mit 'Füllbytes' funktionieren. MfG Spess
Hallo Spess, eigentlich wollte ich nur sagen, das ein dissassebler auch sehr leicht an der Nase herumzuführen wäre, da schon ein falscher Startpunkt zu unsinnigen Ergebnissen führt. Wenn man dann halnwortige Jumps einfügt sollte dieser Disasm vollkommen aus dem Tritt kommen. K.
Hi >Wenn man dann halnwortige Jumps einfügt sollte dieser Disasm >vollkommen aus dem Tritt kommen. Was sind 'halnwortige Jumps'? Ich habe meinen eigenen AVR-Disassembler. Und den kann ich ggf. an sehr viel anpassen. MfG Spess
Klaus De lisson schrieb: > Also.... damals... beim Apple II (6502 Processor) > hat man das auch so gemacht. Der hatte, glaube ich, 5 Stück Slots > für Erweiterungsboards. Jeder Slot hatte aber einen eigenen > Adressbereich. > Damit die selbstgebaute Karte aber in jedem beliebigen Slot funktioniert > musste der Code eben relativ sein. Und das ohne relative JMP und JSR Befehle.
spess53 schrieb: > Was sind 'halnwortige Jumps'? Nun , ein DisASM ist ja eine Software, die die ASM Befehle aus einer Hexstruktur herauslesen will. Wenn man dan aber einen Offset für den Start hinzufügt kommt etwas ganz anderes und unsinniges heraus. Sicher wird der kundige Anwender das Offsetfenster so lange verschieben, bis es Sinn macht. Aber ein Programm welches unsinnigerweise sachen auf den Stack packt und es logisch versetzt wieder darunter holt wird wohl schwerlich zu disassen sein. k.
Alter 6502 Hase schrieb: > Und das ohne relative JMP und JSR Befehle. Die Software stellt fest wo sie ist und macht ihre Arbeit.. ... das fand ich super k.
Klaus De lisson schrieb: > Nun , ein DisASM ist ja eine Software, die die ASM Befehle aus einer > Hexstruktur herauslesen will. > Wenn man dan aber einen Offset für den Start hinzufügt kommt etwas > ganz anderes und unsinniges heraus. > Sicher wird der kundige Anwender das Offsetfenster so lange verschieben, > bis es Sinn macht. Gibst du uns ein Beispiel? Bisher kamen alle von mir verwendeten Disassembler für uC locker damit zurecht. Gegen statische Analyse helfen zwar Dinge wie Masken auf Instruktionen (z.B. bei BD+), die habe ich aber bei uC noch nicht sehen können. > Aber ein Programm welches unsinnigerweise sachen auf den Stack packt > und es logisch versetzt wieder darunter holt wird wohl schwerlich > zu disassen sein. Was auf dem Stack liegen wird, interessiert den Disassembler nicht. Unorthodoxer Umgang mit Stack oder Calling-Mechanismen verändert auch nicht die Algorithem und das meist leichte Auffinden von Funktionsblöcken. Gewonnen ist daher dadurch meiner Meinung nach nur Fehleranfälligkeit aund Arbeitsaufwandt für den menschlichen Obfuscator.
Ich find die Anwendung vom TE schon sinnvoll. Die Schüler, die das disassemblieren schaffen (dazu muss man schon mal wissen, wie sich der Maschinencode vom Asm-Code) unterscheidet), die programmieren auch die gegebene Aufgabe runter, ohne die Hilfe der Vorlage zu benötigen. Für die anderen ist der Aufwand für das deassemblieren sowieso größer, als sich über die eigentliche Aufgabe Gedanken zu machen.
Ich find' es unsinnig. Entweder sind dann die Aufgaben zu schwer/falsch gestellt oder die Schüler haben eh keinen Bock. Was soll es den helfen, wenn ich mit einer Aufgabe nicht weiterkomme "erst mal" eine fertige Routine zu nutzen? Damit ich mit der nächsten Aufgabe auch nicht weiterkomme weil mir das Vorwissen fehlt?
Läubi .. schrieb: > Was soll es den helfen, wenn ich mit einer Aufgabe nicht weiterkomme > "erst mal" eine fertige Routine zu nutzen? vieleicht weißt du nicht mehr wie das als Anfänger ist wenn man noch keine Erfahrung hat und an zig Baustellen den Fehler suchen soll, deshalb kann es durchaus sinnvoll sein nur in einer Baustelle zu suchen und sich beim Rest auf funktionierenden Code verlassen.
Oh, da habe ich ja etwas losgetreten... Um das Umfeld ein klein wenig zu erläutern: in den ATmega kommen in Echtzeit Daten von einer externen Quelle rein. Diese sollen dann verarbeitet werden. Z.B. soll ein bestimmten Pattern (Preambel) gefunden werden, und danach die nachkommenden Daten weiter verarbeitet werden. Solche Sachen lassen sich allerdings verdammt schwer simulieren. Natürlich kann man das mit Stimuli-Dateien machen, aber ich denke es kann immer Abweichungen zwischen Realität und Simulation geben (leicht abweichende Taktgeschwindigkeiten,...). Realtime-Anwendungen lassen sich natürlich auch besch*** Debuggen. Man kann nicht so einfach mit dem Debugger da durch gehen, da die Daten ja wie gesagt in realtime kommen. Deshalb ist es auch, gerade frü Anfänger, schwierig, die Fehlerstelle zu finden. Um den Fehler nun einzugrenzen könnte man also fertigen Code vorgeben. Wenn das Programm nicht läuft, dann kann der eigene Code durch den vorgegeben austauscht werden, und hiermit das/die falschen Unterprogramm(e) erkannt werden. Dann soll man sich natürlich selber überlegen, wo der Fehler ist (NATÜRLICH können Fragen gestellt werden). Ich persönlich(!) finde es aber besser, den Leuten den fertigen Code nicht auf dem Präsentierteller zu überreichen, sondern sie nachdenken zu lassen. Es geht hierbei ja nun nicht um Gemeinheiten, aber man nimmt Sachen einfach sehr schnell hin, wenn man sie sieht, statt sich zu überlegen, warum das jetzt falsch ist. Es geht mir auch nicht darum, den Hex-Code dann noch zu zerstückeln, dass er bloß nicht deassembliert werden kann. Die Leute bekommen diese Codestücke nur in der Übung von mir und haben da gar nicht die Möglichkeit, das zu übersetzen. Und wer das kann, der hat auch mit dem Rest keine Probleme... P.S. Dieser Text spiegelt meine persönliche Meinung wieder!
Walter S. schrieb: > vieleicht weißt du nicht mehr wie das als Anfänger ist wenn man noch > keine Erfahrung hat und an zig Baustellen den Fehler suchen soll Deswegen schreib ich ja: "Entweder sind dann die Aufgaben zu schwer/falsch gestellt" Als Aufgabe für einen Anfänger eignet es sich wohl kaum eine eigenes RTOS zu schreiben... Sinnvolle und aufeinander aufbauende kleine Aufgaben welche man am Simmulator oder in Real testet dann schon eher. Es bringt doch nix einem Grundschüler einen Taschenrechner in die Hand zu drücken falls er "bei einigen Rechnungen für das Lösen eines Integrals" er es nicht schafft diese im Kopf zu lösen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.