X86 mit der Segmenteinteilung.

Die Segmentierung beim x86 ist doch easy. Wenn es nur um eine Adresse 
geht ist das Segmentregister Adresse/10h. In das normale Register kommen 
die letzten vier Bits der Adresse. Also als Beispiel Adresse 12345h, 
dann ist bei DS:SI DS=1234h und SI=0005h. Die gleiche Adresse wäre auch 
DS=1000h und SI=2345h, je nachdem was man übersichtlicher findet.

Kurz gesagt 0000:0010 ist die gleiche Adresse wie 0001:0000.

DOS z.B. läd .COM-Dateien immer an eine Adresse xxxx:0100. Die xxxx sind 
alle Segmentregister und die 0100h ist die Einsprungadresse in den Code. 
0000h-0100h enthält die Umgebungsinformationen, z.B. die Kommandozeile. 
Daher können .COM-Dateien maximal 64k-0100h Bytes groß sein und DOS 
kümmert sich quasi um gar nichts.

.EXE-Dateien werden an CS:0000 geladen und die Datenregister DS und ES 
sind um 10h niedriger initialisiert als CS. Dadurch findet man die 
Umgebungsvariablen direkt ab DS:0000. DOS kann dabei mehr Code als 
64kByte laden, den den Stack (SS:SP) passend setzen und eine beliebige 
Einsprungadresse (CS:IP) anspringen. Diese Informationen finden sich im 
Header der .EXE-Datei. Wenn Dein Code größer als 64kByte ist, mußt Du 
Dich aber trotzdem selbst um die Codesegment-Anpassung kümmern, z.B. 
durch far jumps oder far calls, die über das komplette erste Megabyte 
reichen.

Der Prozessor und DOS verfügt dabei über keine Rechte und keinen 
Speicherschutz. Du kannst Code z.B. direkt im Bildschirmspeichersegment 
ausführen, das sorgt für die erste Überraschung wenn jemand Dein 
Programm tracen möchte.

Nachtrag weil zu spät für Edith:

Oder Du machst Dir das einfacher und gehst gleich zu Win32 und protected 
mode über. Dann kannst Du alle Segmentregister vergessen und alle 
32-Bit-Register (EIP, ESI, EDI, ESP, EAX etc.) reichen über den 
kompletten adressierbaren 4GB-Speicherblock. Die Segmentregister werden 
dabei automatisch so initialisiert, daß alle Datenblöcke (Code, Daten, 
Stack) bei 0h beginnen. Du kannst dann aber z.B. ESI/EDI megabyteweise 
so weit hochzählen wie Du brauchst (bzw. bis Du das zugewiesene 
Datensegment verlässt, ein Byte weiter gibts einen Ausnahmefehler) ohne 
Dich um die Segmentierung zu kümmern.

> Ich möchte bitte den X86 ASM kennenlernen.

> Bei ARM: Die 32bits der Adresse kommen in ein 32bit Register. Fertig.
Super Einwurf. Sechs, setzen!

@TE: Edith wollte noch sagen, Du kannst auch gleich zu Win64 
durchmarschieren, dann sind es nicht mehr EAX, ESI, EDI, EIP etc.
sondern RAX, RSI, RDI und natürlich RIP. Außerdem sind dabei die 
Befehlssatzerweiterungen wie SSE, AVX usw. nutzbar.

Heul leise!

Ja, damals waren NS32000 und der 68000 er technologisch besser. Aber die 
Lieferanten und Hersteller wahrscheinlich etwas zickiger. Man brauchte 
damals, heute ueberigens auch noch, kein ausgefeiltes Marketing wenn die 
anderen zickig tun.

Bedeutet .. wie ist der Support, gibt es ein Dev-Kit, was kostet der 
ASM, was kostet der Compiler, usw.

Ich habe mir auch einen x86 zusammengebaut, weil ich vom 8085 her kam. 
Den PC gab's damals noch nicht.
Ich habe mir also die Chips bestellt. Damals gab es noch support 
ingenieure, die das konnten. Ich konnte mich also eine halbe Stunde per 
Telephon mit so einem Supprt Ingenieur fuer die Intel Familie ueber ein 
Registerfeature des 8059 Interrupt Controller unterhalten. Ebenso ueber 
den DRAM Controller, wenn etwas nicht lief wie ich mir das vorstellte.
Als dann diese ausgenutzt wurden, also Support beanspruchen und dann 
ueber einen Broker bestellen, wurden sie durch Sachbearbeiterinnen 
ersetzt, welche nur noch die Artikelnummer und die anzahl wissen 
wollten.

Das 2.5cm dicke iAPX86 Manual wurde gratis geschickt. So machte man eben 
damals das Geschaeft. Ich blieb diesen Produkten treu.

Anders zB auch gute Controller, die Analog Devices Blackfin DSP. Der 
Compiler beginnt ab 5000 Euro. Ist ein No-go zum Reinschauen fuer 
Absolventen.

Oder TI - TMS320 - ich hab den Namen vergessen, die IDE total schlecht 
und ueberteuert, auch wenn die chips eigentlich gut waren.

OldMan schrieb:
> NS32k oder M68k waren damals ihrer Zeit voraus.

Nö, denn danach kamen die RISC, keine Komplexitätsmonster. Besonders 
wenn man NS32K betrachtet, und dessen Steigerung, NECs V60/70. Diese 
Dinger standen nämlich voll in der VAX Tradition, den Prozessor intern 
so kompliziert zu machen, dass man ihn ohne Blick in die Fehlerliste 
nicht verwenden konnte, und eine Beschleunigung kaum möglich ist.

Es war kein Zufall, dass Motorola irgendwann den Versuch aufgab, die 
hochkomplexe 68020 Architektur zu beschleunigen und auf 88000 setzte. 
Wie auch DEC ebendeshalb die VAX Architektur aufgab und übergangsweise 
erst MIPS, dann Alpha verwendete.

Oha, komplexes Thema.

Im Grunde hängt das von Deinem Programm und der Art der Unterfunkion ab.

Interrupt-Funktionen (z.B. von TSR-Programmen) müssen grundsätzliche 
alle Register und das Flag-Register sichern, da unbestimmt ist wann sie 
aufgerufen werden. Wenn man da einen Fehler macht, hat man quasi sofort 
einen Crash. Es muß quasi alles so hinterlassen werden, wie man es beim 
Einsprung vorgefunden hat.

Also z.B. für 16 Bit Interrupt-Routine:

begin: PUSHA
       PUSH  DS (falls man die Segmentregister braucht)
       PUSH  ES
       MOV   AX,CS
       MOV   DS,AX
       MOV   ES,AX
       [..]     (Programm)
       POP   ES
       POP   DS
       POPA
       IRET

Und ein bißchen Vorsicht mit der Verwendung des Stacks, die 
Interruptroutine verwendet den Stack des Programms, welches gerade 
unterbrochen wurde und darf diesen nicht überfüllen. Das gibt sonst 
einen sogenannten stack overflow, dabei werden meistens die Daten und in 
extremen Fällen der Code des unterbrochenen Programms zerstört.

---

Bei Deinen eigenen Unterfunktionen musst Du nur das sichern, was für 
Dich wichtig ist. Wenn Deinem Programm nach dem Aufruf einer Funktion 
egal ist, wie die Register aussehen (etwa weil Du sie sowieso gleich 
alle neu lädst) brauchst Du auch nichts sichern. Das böse Erwachen kommt 
dann, wenn Du diese Funktion irgendwann an einer Stelle aufrufst, wo das 
nicht egal ist. Außerdem brauchst Du die Flags normalerweise nicht zu 
sichern, da Du normalerweise keine Funktion zwischen einem Vergleich und 
den nachfolgenden bedingten Sprüngen ausführen wirst (was bei einer 
Interruptfunktion jederzeit passieren kann).

AX wird bei sowas meistens nie gesichert, da dort oft Rückgabewerte 
abgelegt werden. Dagegen wird der Zähler CX sehr oft gesichert.

begin: PUSH  BX
       PUSH  CX
       [..]     (Programm im eigenen 64K Codesegment)

ok:    MOV   AX,0
       JMP   SHORT exit

fail:  MOV   AX,1

exit:  POP   CX
       POP   BX
       RET

Bei sehr vielen gesicherten Registern kann man auch PUSHA/POPA 
verwenden, muß Rückgabewerte dann aber direkt auf dem Stack verändern 
damit diese durch das POPA nicht überschrieben werden.

PittyJ schrieb:
> Aber der krankeste Assembler war 8086.

Dann fehlt dir der 1802. ;-)

udok schrieb:
> Die setzt du normalerweise einmal, und das wars.

Nur wenn das Programm klein genug war.

> Wenn die so schlecht wäre, dann gäbe es sie heute nicht mehr.

Es war nicht die Qualität der Architektur, die 8086 am Leben hielt, 
sondern IBM und deren PC. Und es war auch nicht der Qualität der ISA, 
die hinter IBMs Entscheidung stand. Sondern der Mangel an Alternativen, 
bei denen IBM zum Zeitpunkt der Entscheidung davon ausgehen konnte, dass 
sie zum Zeitpunkt der Markteinführung stabil und gut verfügbar wären. 
Das war bei der 68000 nicht der Fall.

Die Problematik von Daten jenseits von 64kB dürfte damals nicht akut 
erschienen sein. Als Entscheidung fürs Jahrhundert war das ja nicht 
gedacht. Auch Intel hatte 8086 nur als kurzen Zwischenschritt zu 432 
gesehen.

Späteren waren dann die schiere Masse und die daraus folgende geforderte 
Kompatibilität das wichtigste Kriterium.

Ich verstehe eure Probleme nicht. Die wenigsten Assembler-Programme 
damals waren größer als 64kB Code. Meine DOS-Viren z.B. waren um die 
70kB Quelltext, aber "nur" 6..7kB Code oder so, einschließlich 
initialisierter Daten. Die Dinger hatten keine Schadfunktion, aber dafür 
COM/EXE Stealth mit polymorpher Verschlüsselung. Die konnten viel um 
sich zu verstecken, das alles zu erklären würde hier den Rahmen sprengen 
- und das mit nur 6..7kB Code. Und nein, ich hab sie nicht auf die 
Menschheit losgelassen oder in der Schule getestet etc. bevor 
irgendjemand fragt. Aber das waren so ziemlich die größten 
Assembler-Programme, die ich geschrieben habe und selbst die waren weit 
von der "kritischen" 64kB Code Marke entfernt.

Selbst wenn man nur einmal zwischen Hauptprogramm und Funktionen 
aufteilt, erhält man schon 128kB maximale Code-Größe. Man könnte CS auch 
für jede Funktion neu setzen. Gefühlt hat das jede Hochsprache gemacht, 
wenn man sich sowas im Disassembler angeschaut hat, war da alles voll 
mit far calls.

Es nervt noch nicht mal bei großen Datenmengen, da man sich Offsets 
größer 65535 sowieso in zwei 16-Bit-Worten merken muß. Das obere Wort 
multipliziert man mit 1000h und addiert die Anfangsadresse des 
Datenblocks, fertig ist der Wert für's Datensegment. Unter DOS gibts 
sowieso nur 640kB Speicher, das ist weit weniger als auf eine Diskette 
passt. Für Assembler-Programme ist das echt viel, für Daten manchmal 
viel zu wenig. Da fangen dann die Spielereien mit HIMEM oder 
DOS-Extendern (DOS4GW z.B.) an.

Naja ist sowieso lange vorbei, die Geschichte. Heute braucht man das 
nicht mehr, läuft sowieso alles im protected mode. Ein einzelnes 
Codesegment wird für sein DOS-Lernvorhaben ausreichend sein.

udok schrieb:
> Selbt in Supercomputern, wo Geld keine grosse Rolle spielt,
> läuft fast nur x64.

Da läuft fast nur x64, weil diese Prozessoren dank Masseneinsatz in PCs 
sowohl leistungsfähig als auch günstig sind. Zudem werden die 
mittlerweile oft von GPUs begleitet, die die eigentliche Aufgabe 
bearbeiten und genauso von dem Masseneinsatz in PCs profitieren.

Mit der Qualität der 8086 ISA hat das wenig zu tun. Segmentregister 
spielen in x64 ohnehin nur eine Nischenrolle.

> Da kannst du deinen Asm Code von damals unverändert laufen lassen.

Auf den GPUs? ;-)

udok schrieb:
> Sagt aber komischerweise keiner, daher ist die x64 ISA wohl doch sehr
> gut.

Mit etwas Glück kann Torben dir mittlerweile den Unterschied zwischen 
Befehlssatz und Implementierung nahe bringen. ;-)

udok schrieb:
> Irgendwelche Ideen, wo ich den kaufen kann?

https://www.raptorcs.com/content/base/products.html