Robotrontechnik-Forum

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

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » ASM <-> C Frage » Themenansicht

Autor

Thread - Seiten: -1-

000
05.06.2008, 20:58 Uhr
Olli

So, ich mal wieder mit meinen bloeden Fragen

Ich bin Z.t dabei die Kernel Quellen welche mir noch fehlten bzw. fehlen durch
disassemblieren der Objekte und zurueckverwandeln des ASM Codes in C zu
erhalten. Ziel soll ein Kernel in seinen Sourcen sein, der 100% zu den
gleichen Objekten compiliert wie sie original im WEGA Kernel vorliegen.
Von den durch EAW entwickelten und/oder erweiterten Objekten ist das ja
kein Problem da ich von diesen Objekten ja die Sourcen habe.
Problematisch sind eher die Objekte welche wohl noch direkt und
unveraendert aus ZEUS stammen. Das ist wohl bei einem Grossteil der
Objekte aus sys/ bzw. LIB2 der Fall.
Aber auch dort habe ich einigen Fortschritt gemacht. Ich habe bereits
einen Grossteil der Sourcen wiedergewinnen koennen, stehe jetzt jedoch
bei einer Detailfrage vor einem Problem. Ich versuche einen ASM-Code
in C nachzubilden, welcher an einigen Stellen im Kernel in den
Original-ZEUS-Objekten vorkommt. Und zwar:

Quellcode:

0530 3582  0004     584         ldl     rr2,rr8(#4)
0534 9424                       ldl     rr4,rr2
0536 0704  7f00     585         and     r4,#32512
04d2 5d04  8000*    586         ldl     _u+78,rr4
04d6 004e*

Vom Verstaendniss her, denke ich schon zu verstehen was dort passiert. ab
der 4. Position des Langwortregisters RR8 in das Langwortregister RR2.
Danach wird RR2 nach RR4 kopiert. Dann wird der niedere Teil, also R4 mit
7F00 ueber AND verknuepft, und das ganze Ergebniss wird dann zurueck in
den User-struct u +78 geladen. Mein C-Code sieht auf Basis dieser Info
nun so aus:

u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF);

In ASM wird daraus jedoch:

Quellcode:

0530 3582  0004     584         ldl     rr2,rr8(#4)
0536 0702  7f00                 and     r2,#32512
04d2 5d02  8000*    585         ldl     _u+78,rr2
04d6 004e*

Da mit rr2 im Original-Code oben nichts weiter passiert, ist meine
Implementierung funktional wohl identisch, aber halt nicht von der Anzahl
der Instruktionen - was ich aber halt gerne erreichen wuerde.
Ich gruebele nun schon tagelang was hier fuer eine Operation stattfinden
koennte welche der Optimizer zu einem AND mit 7f00ffff optimiert und beim
optimieren halt die register-Kopie "uebrig" bleibt. Ich kommme einfach
nicht drauf. Ich habe schon verschiedenste andere Konstrukte wie
u.u_dirp.l = (long)((saddr_t *)uap->linkname)->l & 0x7f00ffffL;
u.u_dirp.l = ((long)uap->linkname&0x7F00FFFFL);
u.u_dirp.l = (long)((int)uap->linkname&0x7F00);
versucht. Alles ohne Erfolg...
Das ganze hier in dem Fall ist uebrigens aus dem link() Syscall aus
sys2.c Zu finden unter

http://cvs.laladev.org/index.html/WEGA/src/uts/sys/sys2.c?rev=1.7&content-type=text/x-cvsweb-markup

Wenn man dort nach link() sucht findet man die Syscall-Implementierung.
Der Rest der Kernels sowie die Header-Files sind auch auf der Seite
zu finden.

Die Frage ist halt - gibt es andere Operationen die mit einer AND Verknuepfung mit 7F00FFFF identisch sind? Vielleicht stand ja genau sowas im C-Code und erst der Optimizer hat daraus ein AND gemacht... Rein Mathematisch bedeutet das AND ja, das das 1. BIT geloescht wird, genauso wie die BITs 9-16. die Bits 2-8 und 17-32 werden aus dem Original unveraendert uebernommen.
Ein Kollege auf Arbeit meinte, es koenne evtl. eine Art Adressermittlung aus einem Speicher-Segment sein? Wer weiss...
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
06.06.2008, 10:40 Uhr
marko_oette

Wird denn rr2 später noch mal abgerufen?

Ein Compiler würde so etwas auch tun, wenn er den Wert in rr2 später noch einmal benötigt.
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
06.06.2008, 13:57 Uhr
Olli

Zitat:

marko_oette schrieb
Wird denn rr2 später noch mal abgerufen?

Ein Compiler würde so etwas auch tun, wenn er den Wert in rr2 später noch einmal benötigt.

Ne, rr2 wird nicht nochmal verwendet. Bzw. sofort wieder ueberschrieben mit anderem temp. Zeugs. Ich hatte einen aehnlichen fall wo der Ausgangs-Code so aussah:

Quellcode:

ldk     r2,#0
         ldb     rl2,_u+1060
         ld      r3,r2
         neg     r3
         add     r3,#256
         ldb     rh3,rl3
         clrb    rl3
         ld      _u+48,r3

In C versuchte ich

Quellcode:

u.u_count = (-u.u_segmts[NUSEGS-1].sg_limit+256)<<8

Daraus wurde dann aber:

Quellcode:

ldk     r2,#0
         ldb     rl2,_u+1060
         neg     r2
         add     r2,#256
         ldb     rh2,rl2
         clrb    rl2
         ld      _u+48,r2

War funktional auch wieder das gleiche - nur halt wieder ohne Registerkopie. Das Problem konnte ich mit:

Quellcode:

u.u_count = (256-u.u_segmts[NUSEGS-1].sg_limit)<<8

loesen. Dann machte er die Registerkopie.

Soetwas aehnliches habe ich oben bei 001 auch versucht und das 0x7f00ffff vorangestellt - ohne Erfolg.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
06.06.2008, 14:26 Uhr
Tom Nachdenk

Wurde da vielleicht eine temporäre Variable und keine Optimierung zur Codegenerierung eingesetzt?

Die Idee mit der Adressmanipulation kommt gut hin, die besteht ja auch Segmentnummer in den Bits 14:8 im Segmentteil und Offset. Werden also alle reservierten Bits aus 0 gesetzt wie dies für den U8001 gefordert wird.

Evtl. könntest Du ja mal prüfen ob in den EAW-Quellen eine ähnliche Manipulation vorgenommen wurde, nebst erfolgreicher Unoptimierung.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
06.06.2008, 14:50 Uhr
marko_oette

Vielleicht hat der Compiler eine Schwäche was den Umgang mit Konstanten betrifft.

In Beiden fällen hantiert er jeweils mit dem Speicher-Wert und nicht der Konstante.

Das was du mit den Casts versuchst dürfte dann auch nicht viel bringen.

Was passiert wen du die log. Verknüpfung umdrehst?

Warum willst du diese Binärkompatibilität erreichen?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
06.06.2008, 15:47 Uhr
Olli

temporaere Variable wuerde entweder im Stack-Bereich landen (also auf eine Adresse geladen), oder bei der deklaration einer Variable als Register-bound, wuerde sie auf einem anderen Register landen, da die Register jeweils von oben an nach unten an lokale Variablen vergeben werden... ehe man da bei rr4 angekommen ist... Und - ich habe keine freie Variable mehr - das Objekt sagt mit seiner ASM-Syntax pro Prozedur genau aus wieviel Speicher an Register und wieviel an Stack-Variablen vergeben ist. Das kann man dann in int/char/long/struckts aufteilen - und das ist alles verteilt und Verwendet.

Die log. Verknuepfung habe ich auch schon umgedreht. Schrieb ich irgendwo in 002 bestimmt auch schon

Und Binaerkompatiblitaet ist halt "toll" dann weiss ich das ich 100% kompatibel bin.

Ich habe auch schon den gesamten Kernel nach diesem Schema durchsucht - es tauch 4 bis 6 mal auf (habs nich mehr genau im Kopf), jedesmal aber in Objektteilen zu denen ich eben leider kein Source habe.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
06.06.2008, 16:15 Uhr
marko_oette

Also dass du die log. Verkettung umgekehrt hast steht nicht oben.

Ich meinte: u.u_dirp.l = (caddr_t)((0x7F00FFFF & (long)uap->linkname));

Nun steht wie in deinem anderen Beispiel die Konstante vorn.
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
06.06.2008, 16:45 Uhr
Olli

Doch, siehe letzter Satz in 002

Zitat:

Soetwas aehnliches habe ich oben bei 001 auch versucht und das 0x7f00ffff vorangestellt - ohne Erfolg.

Ich glaube halt irgendwie nich, das es wirklich damit ge-AND-et wird inzw... das muss irgendwas anderes sein...
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
06.06.2008, 17:57 Uhr
Tom Nachdenk

Hm was ist denn da oben? Weil wieso wird das RR8 nach RR2 kopiert. Da käme wenn RR0 ganz ganz oben ist (wird aber nicht benutzt) nach RR2 RR4 ... oder ist das ganze evtl. ursprünglich ein Assemblemakro gewesen?

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
07.06.2008, 11:47 Uhr
Olli

rr8 ist eine struct in C (uap) und von diesem struct die 3. Variable (linkname) beginnt an 4. Stelle des Registers. und r2/rr2 ist das bevorzugte temporaere register.

ASM-Makros, Pragmas usw kann der Compiler alles nich.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
08.06.2008, 12:22 Uhr
marko_oette

Wirklich interessant. Ich denke, der Compiler macht etwas grundlegend anders. Der von dir eingegebene Code führt auf optimierte Weise zum gleichen Ergebnis.

Kannst du mal folgendes probieren:

Zu was kompiliert er denn:

int a = 170;
int b = a - 85;

und anschließend:

int a = 170;
int b = -85 + (a);
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
08.06.2008, 22:13 Uhr
Olli

ich nehme mal an, du willst das ich die ints register-bound mache - habe ich mal gemacht. Dann kommt beim 1. mal raus:

Quellcode:

ld      r1,#170
        ld      r2,r1
        sub     r2,#85
        ld      r3,r2

beim 2.

Quellcode:

ld      r1,#170
        ld      r2,r1
        sub     r2,#85
        ld      r3,r2

Das ist zu einfach fuer ihn - da steigt er sofort "hinter" mein Beispiel aus 002 ist da schon komplexer wegen dem Struct wo er deswegen wohl auch das umladen macht.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
08.06.2008, 22:20 Uhr
marko_oette

Ja, das wollte ich. Danke zunächst mal.

Er hat es ja richtig erkannt. Die Frage ist, was passiert wenn du aus a und b Instanzen von

struct test{ int value; }

machst?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

013
09.06.2008, 18:00 Uhr
Olli

also... gegeben ist

Quellcode:

struct test
{
        int a;
        int b;
};
...
        extern struct test t;
        int a;

Quellcode:

t.b = 170;
        a = -t.b+85;

ergibt

Quellcode:

ld      _t+2,#170
        ld      r2,_t+2
        neg     r2
        add     r2,#85
        ld      ~L1(fp),r2

Quellcode:

t.b = 170;
        a = 85-t.b;

ergibt

Quellcode:

ld      _t+2,#170
        ld      r2,#85
        sub     r2,_t+2
        ld      ~L1(fp),r2

Quellcode:

t.b = 170;
        a = -85+t.b;

ergibt

Quellcode:

ld      _t+2,#170
        ld      r2,_t+2
        sub     r2,#85
        ld      ~L1(fp),r2

Quellcode:

t.b = 170;
        a = t.b-85;

ergibt

Quellcode:

ld      _t+2,#170
        ld      r2,_t+2
        sub     r2,#85
        ld      ~L1(fp),r2

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

014
09.06.2008, 20:16 Uhr
marko_oette

Hallo Olli, das meinte ich leider nicht.

Aber man kann gut erkennen, dass der Compiler in den 4 von dir gewählten Fällen immer die gleiche Optimierung durchgeführt hat.

In deinen zwei Beispielen wird einer Variable im Struct stets ein Wert der aus einer Berechnung mit Konstante und Struct-Member zugewiesen.

Im erfolgreich gelösten Beispiel hast du die Lesefolge der Konstante in der Subtraktion geändert.

Was ich meinte:

struct test
{
register int value;
}

struct test a, b;

a.value = 170;
b.value = -85 + a.value;

und:
...
b.value = a.value - 85;

Wenn es damit nicht hin haut lassen wirs lieber.

Gruß

Marko
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

015
09.06.2008, 22:09 Uhr
Olli

Quellcode:

struct test
{
        int value;
};

main() {
        register struct test a,b;

        a.value = 170;
        b.value = -85 + a.value;
}

ergibt:

Quellcode:

ld      ~L1(fp),#170
        ld      r2,~L1(fp)
        sub     r2,#85
        ld      ~L1+2(fp),r2

a.value-85 ergibt wieder das gleiche - worauf willst du eigentlich hinaus?

Ich glaube, das umladen in 002 macht er nur wegend er zusaetzlichen Shift-Operation. deswegen kommt er da wohl nich so richtig klar und laedt um. Fragt sich nur wie man dieses wissen fuer den 1. Fall gebrauchen kann.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Dieser Beitrag wurde am 09.06.2008 um 22:10 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

016
10.06.2008, 07:09 Uhr
marko_oette

Hallo Olli,

was ich will schrieb ich ja eigentlich schon: Herausfinden, warum der Compiler in deinem erfolgreich gelösten Fall ein weiteres Register verwendet. - Kommt man dahinter, kann man wie du schon schriebst, den Code leichter nachbilden.

Wenn man sich

u.u_count = ( -u.u_segmts[NUSEGS-1].sg_limit+256 ) << 8

und

u.u_count = ( 256-u.u_segmts[NUSEGS-1].sg_limit ) << 8

mal genau betrachtet macht der Compiler folgende Schritte immer gleich:

* Zuweisen des Ergebnisses auf u.u_count
ld _u+48,r2

* 'Shiften' des Ergebnisses um 8 Bit nach links
ldb rh2,rl2
clrb rl2

* Rechnen mit der Konstante #256 und u.u_segmts[NUSEGS-1].sg_limit
neg r2
add r2,#256

Geändert hast du nur, dass du Subtrahent und Minuent vertauscht und deren Vorzeichen geändert hast.

Die Vorzeichenänderung macht der Compiler in deinem Beispiel indem er die Zahl (stets u.u_segmts[NUSEGS-1].sg_limit) negiert. Anschließend addiert er immer die Konstante #256.

Warum macht er das im von uns konstruierten Beispiel nicht?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

017
10.06.2008, 20:32 Uhr
Olli

es scheint mit unterschiedlichen Typen zusammen zu haengen.

Quellcode:

main() {
        int          c;
        char         d;

        d=170;
        c=256-d;
}

ergibt naemlich:

Quellcode:

ldb     ~L1+3(fp),#-86
        ldb     rl2,~L1+3(fp)
        extsb   r2
        ld      r3,r2
        neg     r3
        add     r3,#256
        ld      ~L1(fp),r3

Achso - "256-" durch "0x0777&" oder so ersetzt macht dann wieder kein umladen

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

Dieser Beitrag wurde am 10.06.2008 um 20:33 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

018
10.06.2008, 21:45 Uhr
marko_oette

Hm, ich dachte es waren immer die gleichen Typen...

Nun ja... hilft dir diese Erkenntnis nun beim lösen deines Problems?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

019
11.06.2008, 06:03 Uhr
Olli

noe - bei einer AND-Verknuepfung wie ich iml letzten Satz schrieb, macht er ja wieder kein Umladen... vielleicht weil der Originalcode eben kein AND macht - jedenfalls nicht in der Form.... vielleicht macht er nur ein And aufden ersten teil der long variable - weist aber trozdem die ganze long variable zu - wie auch immer das gehen soll.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

020
11.06.2008, 21:28 Uhr
marko_oette

In deinem Beispiel (017) war doch aber auch keine AND Operation enthalten.
Wenn du dort Subtrahent und Minuent vertauscht passiert dann das, was du unter 000 versuchtst zu beheben?

Eine AND Operation auf andere weise..? Kenne ich nicht. Dass der Compiler der gleiche war, steht aber fest?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

021
11.06.2008, 21:36 Uhr
Olli

Ja, in 017 war kein AND - sondern eine Subtraktion - mein Ausgangsbeispiel unter 000 braucht aber zummindest laut dem ASM ein Umladen vor der AND-Aktion.

a = 100 - b -> es erfolgt ein umladen von b vor der Rechenaktion
a = 0x7f00 & b -> es erfolgt kein umladen von b vor der Rechenaktion

oder was wolltest du jetzt wissen? Ich kann nicht garantieren, dass der Compiler 100% der gleiche ist (ich war '83 beim kernel compile nicht dabei

) - aber da andere Quellen zu identischen Objekten generieren muss ich erstmal davon ausgehen. Dieses AND-Zeugs ist eins meiner wenigen letzten noch zu loesenden Probleme...

http://cvs.laladev.org/index.html/WEGA/src/uts/sys/sys3.s.diff?f=h&r1=text&tr1=1.1&r2=text&tr2=1.2
http://cvs.laladev.org/index.html/WEGA/src/uts/sys/sys2.s.diff?f=h&r1=text&tr1=1.1&r2=text&tr2=1.2
http://cvs.laladev.org/index.html/WEGA/src/uts/sys/sig.s.diff?r1=1.1&r2=1.2&f=h
http://cvs.laladev.org/index.html/WEGA/src/uts/sys/debug.s.diff?r1=1.4&r2=1.5&f=h

beim letzten sieht man auch schoen beim Abschnitt "Line 570" das er ein komplettes AND unterschlaegt mit der aktuellen Version - was ja auch Sinn macht - wenn ich den 1. Teil mit einem Wert AND-e - dann alles umlade und dann wieder den 1. Teil mit einem groesseren Wert AND-e - kann nur das gleiche wieder rauskommen da der Teil ja schon vorher "beschnitten" wurde und durch das AND mit einem groesseren Wert sich ja nicht aendern kann - daher loescht der Optimizer das wohl auch in meinem Fall - und genau daher denke ich, das er eigentlich irgendwas anderes macht..... *drauf-rumreit*

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

Dieser Beitrag wurde am 11.06.2008 um 21:38 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

022
11.06.2008, 22:08 Uhr
marko_oette

Okay... er macht irgendetwas anderes, das war ja schon immer meine Vermutung. :p

Erklär mich noch mal Folgendes:

RL ist doch low (untere 8 Bit) RH high (obere 8 bit). (Rx) das ganze Ding. Und was dann ist RR?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Dieser Beitrag wurde am 11.06.2008 um 22:11 Uhr von marko_oette editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

023
11.06.2008, 23:33 Uhr
Tom Nachdenk

RR ist ein effektiv 32 bit breites Doppelregister, bestehend aus Rn und Rn+1. Da gabs dann allerdings nur RR0 RR2 usw, also mit gerade Zahlen.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

024
12.06.2008, 06:51 Uhr
Olli

genau, wie tom sagte. RR2 z.B. setzt sich aus R2 und R3 zusammmen wobei sich R2 aus RL2 und RH2 und R3 aus RL3 und RH3 zusammmen. Adressierungen koennen beim U8000 32bit lang sein bzw. sind es.
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

025
14.06.2008, 14:03 Uhr
marko_oette

Hmm, danke für die Infos.

Leider kann ich, wie du merkst, nur raten.

Das "AND 0x7F00" kannst du auch durch "<< 8" mit anschließendem " >> 1" erreichen. Aber sowas programmiert doch sicher keiner..?
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

026
14.06.2008, 14:12 Uhr
Olli

wenn du es aber erst 8 bit nach links verschiebst, gehen dann nicht die 8bit welche du u.a. durch das 7F erhalten willst weg?
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

027
14.06.2008, 14:27 Uhr
marko_oette

Ja, du hast recht.

Habe die Reihenfolge vertauscht.

Richtig wäre "<< 1" und dann ">> (1+8)" - aber das wusstest du doch

--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

028
14.06.2008, 15:18 Uhr
Olli

das funktioniert dann aber immer noch nicht mit einem 32bit-wort bzw. mit dem 1. 16-Bit teil des 32Bit-Wortes... wuesste nicht wie man das in C schreiben sollte

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

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

029
14.06.2008, 16:38 Uhr
holm

Avatar von holm

...vor Allem ist fraglich was der Optimizer darüber denkt...

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

030
14.06.2008, 17:31 Uhr
marko_oette

Hallo Holm,

willkommen in dieser spannenden Diskussion ;-)

Warum der Optimizer so seltsam optimiert ist ja Gegenstand der Diskussion.

Wir haben ein 32 Bit register ja? Dieses wird mit 0x7F00 verunded?

Das höchstwertige Bit wird also geerdet richtig? Dann wird alles ab dem 9. Bit von links geerdet. Das kann man auch mit den og. Shifting Operationen erreichen.

Ich bin aber oben von nem kleineren Register ausgegangen.

Also...

Das höchstwertige Bit bekommst du mit << 1 und >> 1 weg. Dann ist noch der Rest über. Die müsstest du durch shiften um die entsprechende Bit-Zahl erreichen.

Wie gesagt, kann ich mir aber net vorstellen, wieso man das so umständlich machen sollte.

Marko
--
Bitte - wenn nötig - Kontakt via Email, ich bin selten im Forum.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

031
14.06.2008, 17:51 Uhr
Olli

der 1. 16Bit-Teil des 32bit Register wird mit 0x7F00 verANDet - das kann man in C erreichen indem man halt mit 0x7F00FFFF ANDet. anders wuesste ich nicht wie man den 1. Teil eines long ANDen soll, aber das komplette long zuweist.
Um es grafisch darzustellen:

Quellcode:

|                  rr2                  |
|         r2        |         r3        |
|0111 1111 0000 0000 1111 1111 1111 1111|

Da sich r3 nicht aendert, macht der Optimizer daraus ein 0x7f00 nur mit r2 - die zuweisung erfolgt aber dann nach dem AND aber mit dem kompletten 32bit register.
das 1. Bit bekomme ich durch shiften weg - klar - die Bits in der Mitte aber eben nicht

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

Dieser Beitrag wurde am 14.06.2008 um 17:53 Uhr von Olli editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

032
14.06.2008, 19:42 Uhr
Tom Nachdenk

Geht das vielleicht mit einem Union? Einmal halt ein 32 Bit Wert und einmal 2 16 Bit Werte?

Das würde dann evtl. durch einen 2. Typen den Compiler dazu bewegen noch ein Register mehr zu benutzen. Gibts denn keinen passenden Quellcode im Netz der mit einer segmentierten Architektur arbeitet? Für den i286 vielleicht? Wobei von dem tatsächlichen oder eingebildeten Rechteinhaber bislang nur *NIX bis V7 freigegeben wurde. Was vielleicht auch ein Grunde dafür ist das da nix mehr vorhanden sein soll. Zumindest bis ein Jahrhundertprozess zu Ende ist

Dieser Beitrag wurde am 14.06.2008 um 19:51 Uhr von Tom Nachdenk editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

033
14.06.2008, 22:47 Uhr
Olli

So einen union gibt es in sys/param.h - saddr_t ein union aus einem char * und einem struct bestehend aus 2 unsigned - aber selbst da - wie willst du den 1. struct Wert aendern aber den char * Wert zuweisen?
--
P8000 adventures: http://pofo.de/blog/?/categories/1-P8000

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]