Thema: ASMler gesucht

[n3Ro]

Tja, wie gesagt, wenn man was "neues" machen will (in meinem Fall ein HobbyOS nur auf 64bit ausgelegt), ist fuer mich die Frage nach dem warum beantwortet. Wenn man das warum nicht ausreichend klaeren kann, passiert es allzuoft, das etwas mit der Zeit im Abgrund verschwindet (schau dir V2OS an, am Anfang wussten die warum die was machen und wo es hingehen soll, dann wurde es schwammig und ziellos, und dann war es in der Bedeutungslosigkeit ertrunken und von der Bildflaeche verschwunden, "lost" sozusagen ).
Aber Java ist ein gutes Stichwort, denn sehr schoene Sprache und OS-Programmierung ist damit auch noch nicht richtig erforscht. So sichere Sprachen sind in sowas sowieso duenn besiedelt (JNode, Singularity, Unununium fallen mir nur als ernshafte ein). Das waere also auch Grund genug da was zu machen.
Dies ist allerdings meine persoenliche Meinung und ich moechte auch niemanden damit auf den Schlips treten

[Osbios]

Natürlich ist es mir aufgefallen, ich arbeite ja intensiv mit NASM aber es geht um etwas ganz anderes: NASM unterstützt nur x86-CPUs aber eine Unterstützung für Motorola 68000 oder für die PIC-Microcontroller, um einige zu nennen, wäre auf jeden Fall auch wünschenswert.

Hmm... mit einem Macroassembler wäre es möglich.
Ein "Assembler" der im Grunde nur zur Erzeugung von Binärdaten auf grundlage von Adressberechnugen und Macros mit inlinebinäri basiert.
Das kann man zwar nicht mehr direkt als Asm bezeichnen aber Prozessorunabhängig wäre es schon.

[Legend]

Hmm ... interessant!

[Osbios]

Wollt ja noch was zur Optimierung sagen. Das hat jetzt aber nichts mit JIT und so zu tun... Also...
bestimmt wissen einige der hier lesenden Leute mit Asmkentnissen was Pipelineoptimierung ist. Wer sich tiefer mit der Materie beschäftigte, kennt die enorme Leistungssteigerung (positiv) und den enormen Verbrauch an Menschenjahren (nicht so positiv).
Außerdem sind diese Optimierungen sehr Modelabhängig, was sogar dazu führen kann, dass Optimierungen für ein Model bei einem anderem Model zu Performanceverlust führt. Und führ jedes Model eigene Optimierungen schreiben, würde nur bedeuten = Menschenjahre*Anzahl möglicher Modelle.  

Bei Hochsprachen wird meist schon in gewissem Grade Pipelineoptimiert, aber der Output ist meistens schon so schlecht das man sowieso nix mehr retten kann.

Und hier meine Frage: Warum gibt es keine automatisierte Pipelineoptimierung für Assembler?

Ich habe mir schon eine Möglichkeit ausgedacht, bin jetzt aber zu müde um noch weiterzuschreiben.  

[Osbios]

Ok, weiter gehts...

Eine mögliche Optimierung, die ich bei Assemblern sehe, ist das Umsortieren von Befehlen.
Dabei kann ein Befehl belibig verschoben werden, solange alle Abhängigkeiten in der selben Reihenfolge bleiben.

Ich möchte das mal genauer erleutern:

In der Regel wird ein Befehl durch bestimmte Register beeinflusst. (Eingabe)
Der Befehl selbst wiederum verändert Register. (Ausgabe)
Während der Ausführung des Befehles werden bestimmte Bereiche der CPU belegt. (Ressourcen)

Die Beachtung der Ein- und Ausgabe ist zur Erhaltung der Reihenfolge nötig.

Über das Umsortieren der Befehle soll erreicht werten, dass alle Ressourcen der CPU ausgelastet werden

mal ein einfaches Beispiel in Assembler:

Code: [Auswählen]

mov eax,[0xDEADBEEF]
add eax,0xABC
add ebx,ecx
In diesem Beispiel würde die CPU (meines aktuellen Wissens nach) vor dem zweiten Befehl warten bis eax mit dem Speicherwert geladen wurde. (Arbeitsspeicher ist aus sicht des Assemblerprogrammierers eher langsamm)


Zur Optimierung würde man den letzten Befehl einfach zwischen die ersten beiden schieben.

Code: [Auswählen]

mov eax,[0xDEADBEEF]
add ebx,ecx
add eax,0xABC

Das Rumschieben kann ich in diesem Beispiel sehr einfach machen, weil der Befehl add ebx,ecx nicht in direkter Verbindung zu den beiden anderen Befehlen steht.
Man könnte jedoch keinen Befehl zwischenschieben der eax beeinflusst!

Code: [Auswählen]

mov eax,[0xDEADBEEF]
<--Bereich ist für alle Befehle frei, die eax nicht beeinflussen
add eax,0xABC

Hoffe das wurde soweit verstanden.

[DDR-RAM]

Du musst aber aufpassen, das du nicht in Teufelküche kommst, falls du Befehle dazwischen schreibst, die den Speicher beeinflussen

Code: [Auswählen]


mov eax, [0xDEADBEEF]
add eax, [ecx]
mov [ebx], edx


falls ecx = esp und das kann schonmal passieren ist eine vertauschung von 2. und 3. Befehl grob fahrlässig.
Wollte es nur erwähnt wissen
(auch wenn ich mir nicht sicher bin, ob ich pipelining richtig beherrsche, denke eher nicht, code zu selten in asm)

MfG
DDR-RAM

[Osbios]

Aber das Grundprinzip bleibt gleich. Denn ESP ist nur eine Eingabe für jeden Befehl, der den Speicher anspricht!

Um es nochmal deutlich zu machen:
Alles was einen Befehl Beeinflusst darf nicht verändert werden. Dass betrifft alle Register, so unter anderem natürlich auch das Statusregister (flags).

[DDR-RAM]

ich meinte auch ecx=ebx, hatte vorher esp verwendet, dachte mir dann aber das mit esp das Beispiel schlechter wäre

Alles was einen Befehl Beeinflusst darf nicht verändert werden. Dass betrifft alle Register, so unter anderem natürlich auch das Statusregister (flags).

Und auch den Arbeitsspeicher. Wenn nur leseoperationen dazwischen geschoben werden, ist es ja egal, wenn aber schreiboperationen dazwischen platzen, dann müsste der Optimierer entweder genau wissen, das diese zu schreibende Speicherstelle den nächsten Befehl nicht beeinflusst oder er könnte das so nicht optimieren.
(nur falls der nächste befehl auf den arbeitsspeicher zugreift, da fällt mir noch ein spezialfall ein, aber ihr werdet das eh selbst merken)

Aber automatische Pipeline-Optimierung für bestimmte Prozessortypen ist schon was feines.

MfG
DDR-RAM

[Osbios]

ich meinte auch ecx=ebx, hatte vorher esp verwendet, dachte mir dann aber das mit esp das Beispiel schlechter wäre

Dann hätten wir diesen Anfangszustand:

Code: [Auswählen]

mov eax, [0xDEADBEEF]
add eax, [ebx]
mov [ebx], edx
Ohne mich jetzt schon groß mit den Möglichkeiten der Optimierungen bei Speicheradressen beschäftigt zu haben, kann ich sagen, dass der Speicher als eine Eingabeeinheit behandelt werden kann. Es wird allso im zweiten Befehl etwas aus dem Speicher gelesen und im dritten Befehl etwas in den Speicher geschrieben. (Abhängigkeit des zweiten Befehles mit einem vorherigem Befehl der in den Speicher geschrieben hal)

Und auch den Arbeitsspeicher. Wenn nur leseoperationen dazwischen geschoben werden, ist es ja egal, wenn aber schreiboperationen dazwischen platzen, dann müsste der Optimierer entweder genau wissen, das diese zu schreibende Speicherstelle den nächsten Befehl nicht beeinflusst oder er könnte das so nicht optimieren.
(nur falls der nächste befehl auf den arbeitsspeicher zugreift, da fällt mir noch ein spezialfall ein, aber ihr werdet das eh selbst merken)

Dabei kann halt nicht alles optimiert werden. Aber was man optimiert kann, sollte auch optimiert werden.

Aber automatische Pipeline-Optimierung für bestimmte Prozessortypen ist schon was feines.

Mein Traum ist es HT auszuhebeln, indem keine einzige Pipeline mehr frei ist während mein Programm läuft. ^^

[bscreator]

Hi, ich bin auch sehr interessiert daran, wie man einen Assembler baut.
Leider hab ich keine Kenntnisse über Assemblerbau, die ich mit in eure Gruppe einbringen könnte.

Jedoch kann ich einigermaßen Assembler programmieren.
Wär nett, wenn ich in die Gruppe mit rein dürfte (um was zu lernen [LowLevel - Einstieg in den Assemblerbau].

Habt ihr vielleicht ein paar Seiten auf denen erklärt wird, wie man mit der Programmierung anfängt, bzw. wo ?

Danke für alles und noch ein wundervolles neues Jahr euch allen,
bsc

[XanClic]

Das Problem ist nur, dass die Gruppe aus meiner Sicht so ziemlich tot aussieht, denn sonst hätte es in vier Jahren bestimmt mal ein Release gegeben, oder?

(EDIT: Jahr korrigiert, stimmt, ist ja schon 2010 - thx, bluecode )

[bluecode]

Der Thread ist 3,5Jahre alt.
Ansonsten würde ich aber mit den Intel Manuals (va. Instruction Set Reference) anfangen. Ansonsten musst du dich halt mit Parserbau anfreunden, also erstmal Tokens bauen (Keyword, Identifier, Operatoren und Sonderzeichen [zB : bei Labels], Zahl, String dürften wohl die wichtigsten sein), anschließend einen Syntaxbaum (das ist für die Basissachen bestimmt sehr einfach und ohne Theorie zu machen) bauen. Das waren wohl so die Stichworte für wikipedia und google.

[erik.vikinger]

Hallo bscreator ,


also ich schreibe zur Zeit einen Assembler, allerdings nicht für x86. Dazu muss ich dann auch noch einen Linker schreiben. Eigentlich entwickle ich eine komplette Plattform und dazu alles was man so braucht.
Über Hilfe würde ich mich schon freuen.

Hi, ich bin auch sehr interessiert daran, wie man einen Assembler baut.

Ich will nicht sagen das ich voll den Durchblick hab, aber ich denke das ich einen guten Plan hab und der auch sicher ganz gut funktionieren wird.

Leider hab ich keine Kenntnisse über Assemblerbau, die ich mit in eure Gruppe einbringen könnte.

Was kannst Du denn ansonsten einbringen?

Jedoch kann ich einigermaßen Assembler programmieren.

Für welche CPUs?

Wär nett, wenn ich in die Gruppe mit rein dürfte

Wie könntest Du Dir denn eine Zusammenarbeit vorstellen?

(um was zu lernen [LowLevel - Einstieg in den Assemblerbau].

Der Assembler selber brauch eher Wissen über Parser, Tokenizer und ähnliche Sachen. Mit LowLevel hat das nicht wirklich was zu tun.


Aber sei gewarnt, meine Plattform ist doch ziemlich anders als alles andere was es sonst so gibt.
Ich schreibe diese Tools übrigens alle in C++.


Grüße
Erik

[bscreator]

Hi erik.vikinger,
das ist ne gute Idee, dass es jetzt mit C++ machst.
Das blöde ist, dass ich nur Wissen über Compilerbau hab und das ist auch schon ein paar Jährchen her...

Ich schreib meine Programme immer in MS Visual C++. Aber hauptsächlich eigentlich in C Syntax. Mit C++ hab ich nicht so viel am Hut.

Alle Programme waren bisher für den x86. Meine OS hab ich auch nur für den Prozessor programmiert.

Ich werd mich jetzt mal über Parser und Tokenizer im Internet informieren.
Wenn der Assembler und die gesamte Oberfläche fertig ist, wird es ja kein großes Problem darstellen, das ganze auf den x86 zu portieren.

Eine Zusammenarbeit?
Du kannst ja mal den Assembler in deiner Zielsprache und Oberfläche schreiben und ich werd dann mal versuchen, das ganze in ANSI C für den x86 zu schreiben.

[erik.vikinger]

Hallo,

Das blöde ist, dass ich nur Wissen über Compilerbau hab

Dann hast Du doch schon alles wichtige beinander.
sieh mal hier http://www.c-plusplus.de/forum/viewtopic-var-t-is-249255.html
Ein Assembler besteht im wesentlichen aus 2 Teilen: zum einen den Assembler-Text einlesen, auf syntaktische Fehler prüfen und in eine interne Repräsentation (für die nutze ich C++-Klassen, eine Liste reicht ein Baum ist nicht nötig) überführen und zum zweiten diese interne Repräsentation in Binär-Code überführen also Labels auflösen u.ä.

Wenn der Assembler und die gesamte Oberfläche fertig ist, wird es ja kein großes Problem darstellen, das ganze auf den x86 zu portieren.

Ich weiß zwar nicht was Du mit "Oberfläche" meinst aber meinen Assembler auf x86, unter einem normalen OS, umzustellen dürfte nahezu unmöglich sein. Segmentierung ist schon was völlig anderes als Flat-Memory. Okay x86 im PM kann zwar auch Segmentierung aber das nutzt keiner (mehr).


Grüße
Erik

[erik.vikinger]

Hallo,


ich hab noch ein bisschen übelegt.

Ein Assembler sollte die interne Repräsentation, zwischen den 2 von mir schon genannten Haupt-Schritten, sicher auch noch auf logische Fehler prüfen, sowas wie alle benutzten Labels vorhanden und alle Befehle an sich korrekt also keine unerlaubten Register-Kombinationen usw. und ob der Befehl in der gewünschten CPU-Generation überhaupt zur Verfügung steht. Das erspart dem eigentlichen Code-Generator im zweiten Hauptschritt die Mühe vernünftige (menschenverwertbare) Fehlermeldungen auszugeben. Die Gültigkeit der Befehle könnte aber auch schon im ersten Hauptschritt geprüft werden.
Das Problem das ich im Portieren eines Assemblers auf eine andere CPU-Architektur sehe ist das ein Großteil des gesamten Codes eben in den 2 Hauptschritten steckt und die sind beide sehr abhängig von der CPU-Architektur (z.B. die Decodierung von Speicheroperationen hängt davon ab welche Adressierungsmodi eine CPU-Architektur bietet), so das man kaum mehr als das Basis-Gerüst (Listen-Verwaltung u.ä.) und eventuell einige Teile des Parser und Tokenizers wiederverwenden kann (falls die Syntax nicht zu verschieden ist). Ein guter Kandidat für die Wiederverwendung währe wahrscheinlich der Parser für Litterals. Ein "Label1 + (123 * 0x10) + 0x08" muss man immer vernünftig auflösen können, hier ist auch der einzigste Punkt wo ich doch einen Baum einsetze wegen den Klammer-Ebenen und Vorrangregeln.


Grüße
Erik