Vorstellung

Stellt Euch der DOS-Forum Community vor!
wobo
DOS-Guru
Beiträge: 613
Registriert: So 17. Okt 2010, 14:40

Re: Vorstellung

Beitrag von wobo »

@DosFeratu:

Puuuh, da drückt man sich einmal zusammengefasst aus und schon muss man nachbessern: Also, natürlich muß ich in den PMode schalten, um den 4g-Real-Mode anzuschalten. Ich hatte mich damals in den 90ern durch die Artikelserie über PMode gekämpft. Die Listings waren zeilenweise beschrieben, weshalb mir das überhaupt möglich war. Deswegen weiß ich heute auch, dass meine Init-Routine in den PMode schaltet und dann gs, ggf. auch ds oder was-für-ein-Segment-Register auch immer auf 4G-Segment-Grenzen oder auf 64k-Grenzen (wie ich es halt brauche) setzt. Mehr kapiere ich heute (20 Jahre später, einschließlich einer 10-jährigen PC-Abstinenz) einfach nicht mehr. Ich bin mit normalen RealMode schon überfordert. Bei dieser Gelegenheit kündige ich bereits jetzt an, dass ich Dich einmal fragen werde, wie ich _bestimmte_ 386er-Assembler-Befehle in den Inline-Assembler "eingebytet" bekomme ;->>

Ansonsten bleibe ich eben für 386er-Asm-Code bei TASM. Macht den Pascal-Code auch übersichtlicher...

(Sorry freecrac, daß wir in Deiner Vorstellung diskutieren. Ist aber die Folge, wenn man bei mir den UnrealMode/RM4G anspricht, der mir gerade vollen, direkten und schnellen Zugriff auf die 6 MB meines 386sx16 bringt!)

wobo
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Vorstellung

Beitrag von DOSferatu »

Entschuldigung, die Protected Mode betreffende Anmerkung sollte keinesfalls klugscheißerisch rüberkommen. Ich selber programmiere nur im 16bit Mode (mit 16/32bit Registern und FS/GS), nicht einmal im 4G Mode, geschweige denn im Protected Mode. Ich weiß es halt nur zufällig trotzdem (daß man um die Segmentgrenzen zu ändern, in den Protected Mode muß).
Und die Bytes, die man einfügt... naja. Für die dem 286er (und darunter) unbekannten Befehle (also erst ab 386er) kann man die Befehlsbytes aus irgendwelchen Listen holen oder aus der ASM86FAQ.TXT
(Vielleicht bau ich mir mal irgendwann einen Inline-Assembler, den in meine Pascal-Sourcen jage ... dann kann ich die Befehle direkt eingeben und er macht selber die Bytes draus....)
Und wenn es um die Parameterbytes der Befehle geht (also das Mod-R/M Byte).... Ja, da hab ich mich halt ... schlau gemacht, wie die aufgebaut sind und funktionieren.
Bytes einfügen im Assembler vom Pascal geht mit db Byte,Byte,Byte...
Man kann auch Words (mit dw) oder DWords (mit dd) einbauen.
Ich selber neige bei Assembler (genau wie in Pascal) dazu, mehrere Befehle auf eine Zeile zu schreiben. Der Grund ist, daß ich so mehr Übersicht über das Gesamtprogramm habe (sonst ja nur immer so 21 Zeilen gleichzeitig oder so). D.h. meine Sourcen sind sehr "kompakt" und Kommentare setze ich nur ein, wo es nötig ist. (Bestimmte Dinge, die ich immer wieder auf dieselbe Art mache, kommentiere ich irgendwann nicht mehr.)
Ich schätze, meine Sourcen zu lesen und zu verstehen, ist für jemand anders erstmal ein totaler Pain in the Ass. Aber ich habe keine Lust, soviel Zeit und Mühe darauf zu verschwenden, meine Sourcen "schick" zu machen. Den Compiler (und Assembler) interessierts nicht, wie die aussehen - und mich auch nicht...
Ich neige auch (bedingt durch den chronischen Registermangel der x86 CPUs) oft zu so Dingen, die als "unsaubere Programmierung" gelten - wie z.B. selbstmodifizierenden Code. Wenn ich dafür mehr Performance rausholen kann, ist mir quasi jedes Mittel recht. (Will sagen: Für mich ist NICHT die einzige Möglichkeit, ein Programm schneller zu kriegen, mir 'n schnelleren Rechner zu besorgen.)
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Vorstellung

Beitrag von freecrac »

wobo hat geschrieben:Hallo freecrac (und alle anderen!),

Du benutzt ja den Unreal-Mode und hast ihn auch schon hier
http://www.dosforum.de/viewtopic.php?f=15&t=2921
ausführlich diskutiert und vorgestellt.

Da der Unreal Mode eigentlich nicht Thema des vorgenannten Topics war, stelle ich einfach meine Fragen hier bei Dir direkt, weil Du ihn auch im Rahmen Deiner Vorstellung angesprochen hattest...

1. Ich stelle den Unreal-Mode immer noch so ein, wie ich ihn erstmals 1990 in der Zeitschrift DOS International (Martin Althaus, "4 Gbyte im Real-Mode") kennengelernt habe. Dabei wird nur das Segment-Register GS auf 4 Gbyte ausgedehnt. Aussage damals in diesem Artikel und in der anderen Literatur bis 1995 war, dass man das Standard-Register DS nicht auf 4 Gbyte ausdehnen solle, weil es Software gäbe, die die 64k-Beschränkung voraussetzte.
Ich kann es mir micht denken das eine Software ein 32 Bit-Adressregister benutzt und erwartet das nach 64KB ein Überlauf erfolgt. Aber möglich ist das allerdings schon.
Ich habe jetzt festgetellt, dass die Benützung des DS Registers auf meinem 386sx16 einen spürbaren Performanceschub bringt, wohl, weil die Benützung des DS - Registers die Intel-Befehle kürzer macht (nix genaues weiß ich nicht). Ich habe nun probeweise den Unreal-Mode über das DS-Register eingestellt und meine Software auf verschiedenen anderen PC und in der Dosbox getestet. Probleme hatte ich keine.

Da ich gelesen habe, dass Du den Unreal über das Register DS initialisierst, meine Frage: Hattest Du jemals Probleme, die Du darauf führtest, dass ein Programm einen 64k-Überlauf (o.ä.) beim DS-Register benötigte?
Ich selber hatte noch nie Probleme damit.
2. Beim Beenden Deines Programms stellst Du wieder die 64k-Beschränkung her? Ich habe jahrelang dies nicht getan (bei Verwendung des GS-Registers allerdings), d.h. nach Verlassen meines Programms blieb die 4 GByte-Erweiterung eingestellt. Probleme hatte ich bisher deswegen nie bemerkt, auch dann nicht, als in den 90ern mein PC stundenlang lief...

wobo
Bisher habe ich den Unrealmode nicht wieder verlassen und lasse ihn einfach auch nach dem Ende des Programms eingeschaltet. Falls es Probleme damit gibt könnte man ihn jedoch auch wieder abschalten.
Ohne vorangestelltes Segment-Prefix beziehen sich alle Offfsetregister (bis auch ebp und esp) auf DS und so braucht man dort kein Segment-Prefix und das verkürzt den verwendeten Code.

Ich habe gelesen das es mache Steckkarten(SCSII-Controller) geben soll, die in ihrem Bios selber in den PM schalten und den Unrealmode so in die Quere kommen können. Solche Hardwre habe ich selber bisher noch nicht verwendet.

Dirk
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Vorstellung

Beitrag von freecrac »

DOSferatu hat geschrieben:Ich kann erklären, woher das kommt.
FS und GS werden von reinen 16bit Programmen (für 286er und darunter) nicht benutzt, da nicht vorhanden.
DS ist das STandard-Datenregister, das immer benutzt wird. Weil es als Standard-Datenregister benutzt wird, braucht man im Maschinencode vor die Befehle kein Register-Override-Präfix-Byte setzen, wenn man DS benutzen will (außer bei Befehlen, deren indirekte Adressierung das Register BP enthalten, da ist das StandardSegmentregister nämlich SS). Weil das fehlende Präfixbyte die BEfehle kürzer macht, ist es auf einigen Rechnern dann schneller (die noch pro Befehlsbyte Zyklen brauchen)
Ja genau.
Daß man auf 64k Segmentgröße zurücksetzt, kann wichtig sein, weil 16bit Programme davon ausgehen, daß die Adressen bei 16bit "wraparounded" werden und daher...
Wenn die 16bit Programme nur 16 Bit-Register benutzen, dann wird es mit dem Unrealmode auch dabei kein Problem geben.
Wenn man zB im 4G Mode die oberen 16bits der Register EBX, EBP, ESI oder EDI auf etwas anderes als 0 setzt und dann im 16bit mit diesen auf etwas indirekt adressiert (davon ausgehend, daß nur die unteren 16 Bit (BX, BP, SI, DI) benutzt werden, dann landet man irgendwo anders, nämlich an der gewünschen Adresse plus 65536*obere16bit.
Beim Starten einer Anwendung werden alle Register auf null gesetzt und wenn eine Anwendung dort in den oberen 16 Bit eines 32 Bit-Registers etwas hineinlegt, dann muss es halt vorher diese oberen 16 Bit löschen bevor das 32 Bit-Register als Adressregister verwendet wird und nur die unter 16 Bit berücksichtigt werden sollen. Das sollte eigentlich völlig normal sein.
Auch im RealMode kann man übrigens seit 386er die Register in 32bit-Breite benutzen (und setzen etc) und ebenfalls die SegmentRegister FS und GS. Also sollte man IMMER, nachdem man den 4G Mode benutzt hat, sicherheitshalber wieder alles auf die Ausgangssituation setzen.
Meine Programme (obwohl 16Bit) beispielsweise, benutzen die 32bit Register und auch FS und GS. Die würden sich z.B. in die Hose machen, wenn eins der SegmentRegister auf 32-Bit-Address-Mode gesetzt wäre.
Ähm, ich verstehe was du meinst. Du meinst die Adresslänge und nicht den verwendeten Address-Mode.

Zur Errinnerung, ich verwende im Unrealmode ebenfalls den 16-Bit-Address-Mode und damit die Verwendung der Operandsize- Adresssize- und Registersize-Prefixe wie im Realmode. Ob bei der Adressbildung die oberen 16 Bit eines 32
Bit-Adressregisters verwendet wird oder nicht, hat nur etwas mit der verwendeten Segmentlänge zu tun, nicht jedoch mit dem verwendeten Adressmode, der uns nur darüber Auskunft gibt wie der Code mit oder ohne Size-Prefixe von der CPU verarbeitet wird.

Dirk
Zuletzt geändert von freecrac am So 24. Okt 2010, 12:21, insgesamt 1-mal geändert.
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Vorstellung

Beitrag von freecrac »

wobo hat geschrieben:@DosFeratu:

Puuuh, da drückt man sich einmal zusammengefasst aus und schon muss man nachbessern: Also, natürlich muß ich in den PMode schalten, um den 4g-Real-Mode anzuschalten. Ich hatte mich damals in den 90ern durch die Artikelserie über PMode gekämpft. Die Listings waren zeilenweise beschrieben, weshalb mir das überhaupt möglich war. Deswegen weiß ich heute auch, dass meine Init-Routine in den PMode schaltet und dann gs, ggf. auch ds oder was-für-ein-Segment-Register auch immer auf 4G-Segment-Grenzen oder auf 64k-Grenzen (wie ich es halt brauche) setzt. Mehr kapiere ich heute (20 Jahre später, einschließlich einer 10-jährigen PC-Abstinenz) einfach nicht mehr. Ich bin mit normalen RealMode schon überfordert. Bei dieser Gelegenheit kündige ich bereits jetzt an, dass ich Dich einmal fragen werde, wie ich _bestimmte_ 386er-Assembler-Befehle in den Inline-Assembler "eingebytet" bekomme ;->>

Ansonsten bleibe ich eben für 386er-Asm-Code bei TASM. Macht den Pascal-Code auch übersichtlicher...

(Sorry freecrac, daß wir in Deiner Vorstellung diskutieren. Ist aber die Folge, wenn man bei mir den UnrealMode/RM4G anspricht, der mir gerade vollen, direkten und schnellen Zugriff auf die 6 MB meines 386sx16 bringt!)

wobo
Wir helfen gerne.
Dumm ist es nur wenn man gar nicht fragt.

Dirk
freecrac
DOS-Guru
Beiträge: 861
Registriert: Mi 21. Apr 2010, 11:44
Wohnort: Hamburg Horn

Re: Vorstellung

Beitrag von freecrac »

DOSferatu hat geschrieben:Entschuldigung, die Protected Mode betreffende Anmerkung sollte keinesfalls klugscheißerisch rüberkommen. Ich selber programmiere nur im 16bit Mode (mit 16/32bit Registern und FS/GS), nicht einmal im 4G Mode, geschweige denn im Protected Mode. Ich weiß es halt nur zufällig trotzdem (daß man um die Segmentgrenzen zu ändern, in den Protected Mode muß).
Und die Bytes, die man einfügt... naja. Für die dem 286er (und darunter) unbekannten Befehle (also erst ab 386er) kann man die Befehlsbytes aus irgendwelchen Listen holen oder aus der ASM86FAQ.TXT
(Vielleicht bau ich mir mal irgendwann einen Inline-Assembler, den in meine Pascal-Sourcen jage ... dann kann ich die Befehle direkt eingeben und er macht selber die Bytes draus....)
Und wenn es um die Parameterbytes der Befehle geht (also das Mod-R/M Byte).... Ja, da hab ich mich halt ... schlau gemacht, wie die aufgebaut sind und funktionieren.
Das "Mod-R/M Byte" wird auch als Postbyte bezeichnet.

Format of Postbyte(aus Intel-Doku):

Code: Alles auswählen

MM RRR MMM

MM  - Memeory addressing mode
RRR - Register operand address
MMM - Memoy operand address

RRR Register Names
Filds  8bit  16bit  32bit
000    AL     AX     EAX
001    CL     CX     ECX
010    DL     DX     EDX
011    Bl     BX     EBX
100    AH     SP     ESP
101    CH     BP     EBP
110    DH     SI     ESI
111    BH     DI     EDI

---

16bit memory (No 32 bit memory address prefix)
MMM   Default MM Field
Field Sreg     00        01          10             11=MMM is reg
000   DS       [BX+SI]   [BX+SI+o8]  [BX+SI+o16]
001   DS       [BX+DI]   [BX+DI+o8]  [BX+DI+o16]
010   SS       [BP+SI]   [BP+SI+o8]  [BP+SI+o16]
011   SS       [BP+DI]   [BP+DI+o8]  [BP+DI+o16]
100   DS       [SI]      [SI+o8]     [SI+o16]
101   DS       [DI]      [DI+o8]     [SI+o16]
110   SS       [o16]     [BP+o8]     [BP+o16]
111   DS       [BX]      [BX+o8]     [BX+o16]
Note: MMM=110,MM=0 Default Sreg is DS !!!!

32bit memory (Has 67h 32 bit memory address prefix)
MMM   Default MM Field
Field Sreg     00        01          10             11=MMM is reg
000   DS       [EAX]     [EAX+o8]    [EAX+o32]
001   DS       [ECX]     [ECX+o8]    [ECX+o32]
010   DS       [EDX]     [EDX+o8]    [EDX+o32]
011   DS       [EBX]     [EBX+o8]    [EBX+o32]
100   SIB      [SIB]     [SIB+o8]    [SIB+o32]
101   SS       [o32]     [EBP+o8]    [EBP+o32]
110   DS       [ESI]     [ESI+o8]    [ESI+o32]
111   DS       [EDI]     [EDI+o8]    [EDI+o32]
Note: MMM=110,MM=0 Default Sreg is DS !!!!

---

SIB is (Scale/Base/Index)
SS BBB III
Note: SIB address calculated as:
<sib address>=<Base>+<Index>*(2^(Scale))

Fild   Default Base
BBB    Sreg    Register   Note
000    DS      EAX
001    DS      ECX
010    DS      EDX
011    DS      EBX
100    SS      ESP
101    DS      o32        if MM=00 (Postbyte)
       SS      EBP        if MM<>00 (Postbyte)
110    SS      ESI
111    DS      EDI

Fild  Index
III   register   Note
000   EAX
001   ECX
010   EDX
011   EBX
100              never Index SS can be 00
101   EBP
110   ESI
111   EDI

Fild Scale coefficient
SS   =2^(SS)
00   1
01   2
10   4
11   8
o8 = 8 Bit Displacement
o16 = 16 Bit Offset, oder 16 Bit Displacement
o32 = 32 Bit Offset, oder 32 Bit Displacement

Zum Anfang empfand ich diese Tabellen auch etwas verwirrend, daher erkläre ich mal kurz wie man hier vorgeht.
Zuerst lokalisiert man die beiden Bits aus dem MM-Field aus den jeweiligen Spalten entweder aus der Tabelle für 16bit memory, oder aus der Tabelle für 32bit memory.
Nun können wir In der jeweiligen Zeile die drei Bits aus dem MMM-Field finden.

...

Ein Prozessorbefehl setzt sich wie folgt zusammen:

Code: Alles auswählen

   Instruction Prefix                0 oder 1 Byte
   Address-Size Prefix               0 oder 1 Byte
   Operand-Size Prefix               0 oder 1 Byte
   Register-Size Prefix              0 oder 1 Byte
   Segment Prefix                    0 oder 1 Byte
   Opcode                            1 oder 2 Byte
   Mod R/M                           0 oder 1 Byte
   SIB, Scale Index Base (386+)      0 oder 1 Byte
   Displacement                      0, 1, 2 oder 4 Byte (4 nur 386+)
   Immediate                         0, 1, 2 oder 4 Byte (4 nur 386+)
...

Zum Protectmode/Unrealmode wäre noch anzumerken das es verschiedene Methoden gibt die 21. Adressleitung freizuschalten.
http://aodfaq.wikispaces.com/a20

...

Why use assembly answered by Betov<http://rosasm.org>:
The price of freedom, so to say, and one of the reasons i am used to say that Assembly is an anarchist Language, whereas C (typicaly) is a fascist Language.

...
Ich neige auch (bedingt durch den chronischen Registermangel der x86 CPUs) oft zu so Dingen, die als "unsaubere Programmierung" gelten - wie z.B. selbstmodifizierenden Code. Wenn ich dafür mehr Performance rausholen kann, ist mir quasi jedes Mittel recht.
Die Debugregister dr1 - dr4 habe ich auch schon mal zweckentfremdet. Der Zugriff darauf ist wahrscheinlich etwas langsamer als auf andere Register, aber bestimmt schneller als aufs RAM.

Dirk
Antworten