Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Z8001 Assembler » Themenansicht

Autor

Thread - Seiten: -1-

000
25.08.2009, 19:40 Uhr
Olli

Hallo,

ich bin gerade mal wieder dabei Quellen von WEGA zu "recovern" - durch disassemblieren und vergleichen mit SystemIII Quellen. Dabei bin ich auf sowas gestossen.

Im Original wird ein Registerinhalt weggesichert:
5df60000 ldl %0000(r15),rr6
Bei meinem compilierten Programm komme ich aber auf:
1df6 ldl @r15,rr6

Passiert bei beidem nicht das gleiche? 0000+r15 im ersten Fall ist doch das gleiche wie direkt auf die Adresse zu laden die in r15 steht oder
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
25.08.2009, 22:01 Uhr
Olli

Ich glaube, das mit den Userlevel Tools wieder disassemblieren und in C herstellen von WEGA so das die gleichen Objekte erzeugt werden die unter WEGA vorliegen schenke ich mir. Die Deppen von Zilog haben die Programme fuer jedes ZEUS Release nicht neu compiliert. Heisst - in die Programme sind alle moeglichen Versionen von libc-Funktionsimplementierungen hineingelinkt... was beim Programmcompile gerade so aktuell war. Heisst... man wird verschiedene libc brauchen damit man die gleichen Objekte erhaellt... und die haette ich schon gerne - zummindest einmalig um zu wissen "jo, ist somit das gleiche C-file". Das ist aber wohl ne sch* Arbeit da malloc() in dem einen Objekt mal vom Maschinencode her so aussieht, und in dem anderen Programm anders... und dann kommt noch dazu das sich der C-Compiler pro ZEUS Release ja auch weiter entwickelt hat... das duerfte auch die Ursache fuer 001 sein....
OMG... ich haette ja irgendwann mal erwartet neues ZEUS Release - alle Programme neu uebersetzen... aber nix da - also auch nix anderes als beim Kernel wo sie auch immer nur bei Aenderungen neu uebersetzt haben....
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
25.08.2009, 22:11 Uhr
Tom Nachdenk

Immerhin hatten sie wohl ein funkionierendes make ...
Hätte sonst fast vermutet das obiges vom Code obfuszieren im EAW kommen könnte ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
25.08.2009, 22:24 Uhr
Olli

Naja, der C Compiler der fuer obigen code eingesetzt wurde hat scheinbar Zeiger immer so uebersetzt. Der "aktuelle" C-Compiler von Zilog macht es halt so Vielleicht ist der Sourcecode ja doch irgendwie anders und es liegt nich am C-compiler.

Quellcode:

char whatstr[] = "@[$]unlink.c  2.1  07/23/82 21:19:30 - 87wega3.2";

main(argc, argv) char *argv[]; {
        if(argc!=2) {
                write(2, "Usage: /etc/unlink name\n", 24);
                exit(1);
        }
        unlink(argv[1]);
        exit(0);
}

mein ASM faengt so an:

Quellcode:

.code

_main::
{
        dec     fp,#~L2
        ldl     @fp,rr6
// char whatstr[] = "@[$]unlink.c       2.1  07/23/82 21:19:30 - 87wega3.2";
//
// main(argc, argv)
// char *argv[];
// {

das Original-ASM hat halt dort bei ldl halt %0000(fp) stehen. Kann auch sein, das argv irgendwie anders deklariert ist, aber ich habe denke ich alles ausprobiert (char **argv, register, char argv, char *argv) - fuehrt alles nich zum gewuenschten Ergebniss....

Dann habe ich mit "logname" weitergemacht - auch n kleines Prograemmchen - und dort kam mir dann der Mist mit der libc entgegen - wobei es schon mit crt0.o anfaengt - dem "Urlader" der WEGA-Programme...

aktuell ist der:
http://cvs.laladev.org/index.html/P8000/WEGA/src/lib/libc/csu/crt0.s?rev=1.1&content-type=text/x-cvsweb-markup

bei aelteren ZEUS-Programmen findet man aber den:
http://cvs.laladev.org/index.html/P8000/WEGA/src/cmd/compat1crt.s?rev=1.1&content-type=text/x-cvsweb-markup

und bei mittelalten noch einen anderen... aber das bekommt man ja durch disassemblieren recht leist hin... aber jetzt die reingelinkten libc Funktionen erstmal alle zu disassemblieren.... OMG....
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
26.08.2009, 17:20 Uhr
Olli

Ach was solls, ich setz mich jetzt an die libc... man hat ja sonst keine Sorgen

Der WDC Plan bleibt dann noch etwas liegen... brennt ja auch nich...
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
26.08.2009, 18:30 Uhr
Olli

Ich glaube fast nicht, das es jemand weiss - aber ich frage trozdem mal

Ich habe folgenden PLZ/ASM Source:

http://cvs.laladev.org/index.html/P8000/WEGA/src/lib/libc/sys/signal.s?rev=1.2&content-type=text/x-cvsweb-markup

Der compiliert soweit durch. PLZ/ASM erstellt nun verschiedene Sektionen die automatisch mit dem Modulnamen ge-prefixt werden.

#229 nm /z/src/libc/orig_obj/signal.o
0000 T _signal
U cerror
0000 s signal_b
0000 s signal_d
0000 s signal_p

Bei meinem Code fehlt nun die _b Sektion. Wie ich mittels objdu sehe, hat das Original-Objekt eine BSS Sektion. Die fehlt mir.

#227 nm signal.o
0000 T _signal
U cerror
0000 s signal_d
0000 s signal_p

Weiss einer wie man BSS Sektionen in PLZ/ASM definiert bzw. kann mir sagen was genau das ist?
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
26.08.2009, 18:59 Uhr
Olli

habe mir jetzt meine Section selber definiert.

Quellcode:

$SECTION signal_b
  internal
    L1
      ARRAY [20 WORD]
$SDEFAULT

Irgendwie wird das sicherlich mit irgend ner Direktive in den BSS Bereich verschiebbar sein, habe im PLZ/ASM Handbuch von Zilog aber nix gefunden.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
26.08.2009, 19:32 Uhr
holm

Avatar von holm

B ist mit höchster Warscheinlichkeit bss, das Stack Segment.
Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
27.08.2009, 18:10 Uhr
Olli

Ich habe folgenden ASM Code:

Quellcode:

.
             61f20002  ld      r2,%0002(r15)
         4c2100012b2b  cpb     %0001(r2),#%2b
                 bd30  ldk     r3,#0
                 af36  tcc     z,r3
                 b130  extsb   r3
                 a13d  ld      r13,r3

dazu habe ich folgenden C Code gebastelt:

Quellcode:

.

_endopen (file, mode, iop)
char *file, *mode;
register FILE *iop;
{
        extern int errno;
        register int rw;
        register int f;
[...]
        rw = mode[1] == '+';
[...]

Da kommt bei mir nun folgender ASM Code bei raus:

Quellcode:

.
             61f20002  ld      r2,%0002(r15)
         4c2100012b2b  cpb     %0001(r2),#%2b
                 bd30  ldk     r3,#0
                 af36  tcc     z,r3
                 a13d  ld      r13,r3

Das extsb fehlt mir... Einer Idee was das verursachen koennte?
extsb klingt fuer mich nach signed/unsigned Umwandlung - tcc setzt ja nur das letzte Bit - und extsb holt es dann auch nach vorne. Habe also schonmal rw als unsigned int deklariert.... ohne Erfolg...
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 27.08.2009 um 18:12 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
27.08.2009, 18:30 Uhr
Olli

Ich mags meine Fragen selbst zu beantworten

Des Raetsels Loesung:

rw = (char)(mode[1] == '+');

wieder ein Objekt mehr :
#494 cmp endopen.o /z/src/libc/orig_obj/endopen.o
#495
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
27.08.2009, 22:09 Uhr
Olli

libc fast fertig... aber jetzt kommen eher die harten Brocken hehe

http://cvs.laladev.org/index.html/P8000/WEGA/src/lib/libc/
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
27.08.2009, 22:30 Uhr
holm

Avatar von holm

Ich habe sowas noch nie gemacht, allenfalls eine Platte darüber was ein Compiler wie gelöst haben könnte.
Du bist auf dem Gebiet eindeutig unsere Spitzenkraft...

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
28.08.2009, 07:30 Uhr
Olli

naja, is eigentlich nich so schwer.

Fuer das was im Original aus C-Sourcen gemacht wurde:
man nehme SYSIII und V7 Sourcen, compiliere diese, disassembliere sie wieder und vergleiche dann das Ergebniss mit dem disassemblierten Original. Optional kann man auch gleich mit -Sl das ASM Listing der neuen C-Quelle herzaubern, das disassemblierte vergleicht sich aber besser mit dem disassemblierten des Original-Objekts.
Naja, und bei Unterschieden schaut man halt was da anders sein koennte. Wenn z.B. mehr Zugriffe auf den Stack sind, kann man mit anderen Stackzugriffen die "passen" vergleichen um was fuer Variablen es sich handelt auf die da zugegriffen wird. Bei den Aktionen die ausgefuehrt werden weiss man es entweder irgendwann was das war, oder man probiert etwas rum

Wenn externe Prozeduren zusaetzlich aufgeruffen werden (call %0000) sieht man am disassemblierten nicht unbedingt was es ist, aber da hilft dann nm vom Originalobjekt weiter - entweder liefert das zusaetzliche undefined Symbole oder es sind schon sowieso verwendete externe Symbole. Dann kann man entweder mit "hd" gucken was da passen koennte, oder probiert ein wenig rum - so viel ists ja meist nicht.... und so gehts halt weiter bis es irgendwann passt.
Am Anfang einer Prozedur werden auch so Sachen wie verwendete Stackgroesse reserviert, und die Uebergabeparameter werden umgeladen, entweder auf register oder auf den Stack. Daran erkennt man dann wieviel Uebergabeparameter es sind, wieviel Variablen (grob) in der Funktion verwendet werden, und wo mit register-Variablen und wo mit Stack-Variablen gearbeitet wird. Bei einfachen Datentypen noch recht simpel... bei Struckt wird es schon etwas schwerer... Das erkennt man meist am umgelade und Zugriff auf eine bestimmte Position ab der Adresse des Structs... bei der Position kann man dann meist ausrechnen welches Struct-Element es ist auf das zugegriffen wird (Im Kernel wird ja meist mit grossen Structs wie dem user-struct gearbeitet, da hatte ich dann irgendwann Tabellen... bei +168 weisst du nicht immer auswendig welches Element das genau ist

)

Wenn die Quelle eine ASM Datei war, sieht man an dem nm Output ob die Quelle PLZ/ASM war, oder eine cas-Assembler Datei. existieren dort 2 gleichnamige Symbole (in der Regel == Dateiname) mit _d und _p am Ende handelt es sich um eine PLZ/ASM Datei wo der PLZ/Assembler autom. 2 Sektionen (programm, data) angelegt hat. Sind diese Sektionen nicht da, wurde die Datei mit cas erzeugt - wahrscheinlicher ist aber, dass das Original eine C-Datei war. Zilog hat wenn ASM eigentlich "immer" PLZ/ASM benutzt.

Bei den libc Quellen geht es in der Regel, weil die Objekte recht klein sind. Da sind dann Unterschiede im 10...20 Zeilen Bereich zu den Original-V7/SYSIII-Quellen. z.B.:

http://cvs.laladev.de/index.html/P8000/WEGA/src/lib/libc/stdio/system.c.diff?r1=1.1&r2=1.2&sortby=rev&f=h

Soweit dazu.... wenn nun aber kein SYSIII / V7 Aequivalent vorliegt, und du da so mehrere Hundert Byte unbekannten Code hast wird es schon sehr schwer... da gebe ich dann meist auch irgendwann auf....
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 28.08.2009 um 07:41 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
28.08.2009, 20:51 Uhr
Olli

Naja - bei kleineren Files gehts auch mit disassemblieren ganz ohne "Vorlage" - Mit ner man page weiss man ja ungefaehr was passieren soll...

Man Page: http://pofo.de/cgi-bin/man.cgi?query=goodmagic
Disasm: http://files.pofo.de/goodmagic.asm

Resultat: http://cvs.laladev.org/index.html/P8000/WEGA/src/lib/libc/gen/goodmagic.c?rev=1.2&content-type=text/x-cvsweb-markup

So 1:15h hab ich da aber schon drann gesessen

EDIT: habe mal den ASM Code kommentiert falls es interessiert

--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 28.08.2009 um 21:00 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
29.08.2009, 11:27 Uhr
Olli

Nun habe ich auch noch rausgefunden, wie man Floating Point Funktionen unter WEGA "disassembliert" und auch noch im PLZ/ASM (oder cas) verwendet... bringt zwar nix, da wir gar keine FPU haben, aber Funktionen sind in der libc

disassemblierter code mit extended instructions:

Quellcode:

0044                 abf3  dec     r15,#4
0046             0ffcc401  ext0f   #%0ffcc401
004a             8e04c640  ext8e   #%8e04c640
004e         14023f800000  ldl     rr2,#%3f800000
0054             0b071388  cp      r7,#%1388
0058                 e705  jr      c,%0064
005a                 a52e  set     r2,#14
005c             8f088201  ext8f   #%8f088201
0060                 a9f3  inc     r15,#4
0062                 9e08  ret

Man bastelt sich ein executable was diese pow10() funktion verwendet und benutzt dann adb zur disassemblierung:

Quellcode:

#61 adb a.out
ADB: P8000 1.6
? 0x0044/i
%0044:          dec     sp,#4
? 0x0046/i
%0046:          fldctl  @sp,fflags
? 0x004A/i
%004a:          fsetmode        rn
? 0x004e/i
%004e:          ldl     rr2,#%3f800000
? 0x005c/i
%005c:          flds    f0,r2
?

Dann stueckelt man das obere disassemblierte mit diesen extended Aufrufen in eine PLZ/ASM Datei zusammen:

Quellcode:

#67 cat pow10.s
pow10 module
  global
    _pow10 procedure
      entry
        dec     r15,#4
        fldctl  @r15,fflags
        fsetmode rn
        ldl     rr2,#%3f800000
        cp      r7,#%1388
        jr      c,L1
        set     r2,#14
        flds    f0,r2
        inc     r15,#4
        ret
L1:
    end _pow10
end pow10

Und dann wird compiliert - aber mit "-f" fuer floating point Support!

Quellcode:

#66 as -f -o pow10.o pow10.s 
#67 objdu pow10.o
File pow10.o
Image size:     32
Bss size:       0
Entry point:    0x0
Segment 0
Text size:      32
Data size:      0
Bss size:       0
Text......

0000:     abf3  0ffc  c401  8e04  c640  1402  3f80  0000
0010:     0b07  1388  e705  a52e  8f08  8201  a9f3  9e08
Data......

#69

Gleicher Objektcode wenn man mit dem Disassemblierten Listing oben vergleicht

--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
29.08.2009, 12:21 Uhr
Tom Nachdenk

die fehlende FPU kann man ja per Trap emulieren lassen, dürfte aber langsamer sein also ein direkter Aufruf einer entsprechenden Floatingpoint-lib. Wobei ich der Meinung bin mal etwas davon gelesen zu haben das die FP-Anbindung in ZEUS unoptimal langsam gewesen wäre, also evtl. doch per Softwaretrap?

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
29.08.2009, 13:28 Uhr
Enrico
Default Group and Edit

Fehlt also doch noch ne FPU

--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
29.08.2009, 14:16 Uhr
holm

Avatar von holm

Wieso fehlt..?
Man kann so ein Ding dran bauen, das Wega selber benutzt sie aber nicht und ich vermute mal das Du das Teil nicht für Number Crunching verwenden möchtest.

Wofür also fehlt die?

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
29.08.2009, 15:25 Uhr
Olli

Fuer TCP/IP waere es vielleicht ganz gut - zum Checksummen berechnen. Wobei - da kann man auch gleich n Chip mit Checksum-Offloading nehmen.... wobeei das eh alles so komplex ist - kann man machen wenns grundsaetzlich laeuft

--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
29.08.2009, 15:40 Uhr
Enrico
Default Group and Edit

Na, ich dachte mal, wenn in SW die Möglichkeit schon vorgesehen ist...

Ist die Frage, ob es da Programme gibt die grossartig was zu berechnen haben , und davon profitieren könnten.
--
MFG
Enrico

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
29.08.2009, 18:25 Uhr
Tom Nachdenk

Wieso eine FPU?, Zilog hat ja dankenswerter Weise 'das' so konstruiert das ein System bis 4 FPUs unterstützt, wobei mir nicht so ganz klar ist wie das dann mit der Software ist, da müssten dann ja je nach Rechnerausstattung die FPU-Register gerettet werden was wiederum kräftig an der Resource Zeit nagt. Evtl. gabs aber auch den Ansatz das bis zu <Anzahlt der FPUs> Prozesse jeweils eine FPU bekommen und der Programmlader dann die entsprechenden OP-Codes patcht ... hab diesbezüglich nicht wirklich was gefunden und die meisten Literaturquellen sind Asbach Uralt ...

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

021
29.08.2009, 18:55 Uhr
Olli

Gibt ja auch nich wirklich Literatur dazu.... Habe hier eine 917 seitige Schwarte "Z8000 Assembly Language Programming by Lance A.Leventhal, Adam Osborne & Chuck Collins". Da steht recht viel drinn. Die Extended Instructions die dort jedoch drinn stehen, fangen alle mit X an - der WEGA C-Assembler und PLZ/ASM-Assembler kennt nur Mnemoniks die mit F anfangen...
Das Buch ist sonst ganz gut.. sind auch viele Beispiele.. auch 47 Seiten ueber Interrups inkl. Z80-SIO und PIO Interrups... dann auch so abgedrehte Kapitel "Large Configurations" bzgl. MMU Verwendung und Multi-CPU Konfiguration (multi micro instructions)... Ansonsten findet man ja nur noch die 2...3... PDFs im Netz von Zilog selber.
Daneben habe ich noch die DDR-U8000-Biebel (auch nur von Zilog abgeschrieben und uebersetzt).

Wenn noch einer was wissen will, kann ich schauen ob ich was in meinem engl. Z8000 Buch finde und scanne... bis morgen - ansonsten muss es 2 Wochen warten

@EDIT oder bei amazon gebraucht zuschlagen

http://www.amazon.de/dp/0931988365/
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 29.08.2009 um 18:59 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
29.08.2009, 20:44 Uhr
holm

Avatar von holm

Du könntest mal gucken, ob das zu den Interrupts noch neue Erkenntnisse drin stehen, nicht nur das, was Du vor ein paar Tagen gelernt hast, also das was wir schon wissen :-)

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

023
29.08.2009, 21:42 Uhr
Olli

Naja, meiner Meinung nach steht nicht viel neues drinn. auf 12-13 steht nochmal was ueber die manuelle RETI Erzeugung fuer Z80 Schaltkreise - aber allgemein gehalten.
Ansonsten natuerlich noch ueber die ganzen Z8000 Besonderheiten usw... ich habe es mal gescannt:

http://pofo.de/P8000/notes/Z8000_ASM_Ch12.pdf
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]