Groups | Search | Server Info | Login | Register
Groups > de.comp.lang.assembler > #1202
| From | Stefan Reuther <stefan.news@arcor.de> |
|---|---|
| Newsgroups | de.comp.lang.assembler |
| Subject | Re: Image deflaten |
| Date | 2020-06-25 18:30 +0200 |
| Message-ID | <rd2qg0.4so.1@stefan.msgid.phost.de> (permalink) |
| References | (3 earlier) <rcfpjs$gh2$1@dont-email.me> <slrnrf3j05.fjc.hjp-usenet3@trintignant.hjp.at> <rctnc9$l0o$1@dont-email.me> <rd0336.450.1@stefan.msgid.phost.de> <rd0cnv$hlp$1@dont-email.me> |
Am 24.06.2020 um 22:23 schrieb Bernhard Schornak:
> Stefan Reuther schrieb:
>> Am 23.06.2020 um 22:06 schrieb Bernhard Schornak:
>>> Peter J. Holzer schrieb:
>>>> Nein, das Segment-Register wird um 4 Positionen nach links geshiftet
>>>> und
>>>> dann addiert. Hier macht das keinen Unterschied, weil die unteren 12
>>>> Bits 0 sind:
>>>>
>>>> 1000:0000 = 10000 + 0000 = 10000
>>>
>>> CS, DS, ES und SS sind (auch in modernen Prozessoren!) 16 Bit breite
>>> Register - wenn man 0x1000 in einem 16-Bit breiten Register vier Bit
>>> nach links schiebt, bleibt Null übrig, und das Überlaufbit wird u.U.
>>> gesetzt.
>>
>> Nur dann, wenn man nur 16 Bit hat...
>>
>>> Die Segmentregister selektieren jeweils einen der 65536 Paragraphen,
>>> das sind 16-Byte große "Scheibchen" des Speichers. Das vermeintliche
>>> "Schieben nach links" ist Unfug, da die Segmentregister zur internen
>>> Adressberechnung einfach von Bit 4 bis Bit 19 eingesetzt werden, und
>>> danach das Offset dazuaddiert wird:
>>>
>>> Adresse = SegmentRegister * 16 + Offset
>>
>> ...dann kann man aber auch nicht mit 16 multiplizieren, denn dabei
>> fallen auch die überlaufenden Bits weg.
>
> Verstehendes Lesen hilft hier gewiss weiter... ;)
Das Kompliment geb ich zurück.
>> Denn "4 Bits nach links schieben" und "mit 16 multiplizieren" ist das
>> gleiche.
>
> Nein. Das oberste Nibble eines 16-Bit-Registers um n Bit nach
> links schieben heisst, diese n Bit aus dem Register schieben.
Das ist deine und nur deine Definition.
Intels Definition der Adressgenerierung im Real Mode hingegen ist:
# 14.1 Physical Address Formation
#
# The 80386 provides a one Mbyte + 64 Kbyte memory space for an 8086
# program. Segment relocation is performed as in the 8086: the 16-bit
# value in a segment selector is shifted left by four bits to form the
^^^^^^^^^^^^^^^^^^^^^^^^^
# base address of a segment. The effective address is extended with four
# high order zeros and added to the base to form a linear address as
# Figure 14-1 illustrates.
("INTEL 80386 PROGRAMMER'S REFERENCE MANUAL 1986", z.B. hier erhältlich:
<http://download.xskernel.org/docs/processors/intel/386/386intel.txt>)
Intel geht dabei sogar ganz selbstverständlich davon aus, dass die
Addition zweier 20-Bit-Werte einen 21-Bit-Wert ergibt.
>> Nicht korrekt ist aber etwas wie "Segmentregister enthalten immer das 5.
>> Digit der Adresse". 9F00:9000 = A8000, das 'A' kommt in keinem der
>> Register vor.
>
> Ich habe nirgendwo geschrieben, dass das fünfte Digit (= Bits
> 16 bis 19) -identisch- mit dem obersten Nibble der effektiven
> Adresse sein muss.
Du hast wörtlich geschrieben: "Segmentregister enthalten immer das 5.
Digit der Adresse". Wie man das anders interpretieren kann als "das
fünfte Digit ist identisch mit dem obersten Nibble der Adresse" ist mir
ein Rätsel.
Man muss es ja nun nicht schwerer machen als es ist. Effektive Adresse =
16*Segment + Offset. Fertig.
Stefan
Back to de.comp.lang.assembler | Previous | Next — Previous in thread | Next in thread | Find similar
Image deflaten Jens Kallup <kallup.jens@web.de> - 2020-06-17 14:59 +0200
Re: Image deflaten Stefan Reuther <stefan.news@arcor.de> - 2020-06-17 18:18 +0200
Re: Image deflaten Jens Kallup <kallup.jens@web.de> - 2020-06-17 18:46 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-06-18 15:17 +0200
Re: Image deflaten "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2020-06-23 11:31 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-06-23 22:06 +0200
Re: Image deflaten Jens Kallup <kallup.jens@web.de> - 2020-06-24 01:38 +0200
Re: Image deflaten Jens Kallup <kallup.jens@web.de> - 2020-06-24 01:46 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-06-24 14:33 +0200
Re: Image deflaten Stefan Reuther <stefan.news@arcor.de> - 2020-06-24 17:38 +0200
Re: Image deflaten Jens Kallup <kallup.jens@web.de> - 2020-06-24 18:46 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-06-24 22:23 +0200
Re: Image deflaten Stefan Reuther <stefan.news@arcor.de> - 2020-06-25 18:30 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-06-26 11:35 +0200
Re: Image deflaten Stefan Reuther <stefan.news@arcor.de> - 2020-06-26 18:30 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-08-06 09:28 +0200
Re: Image deflaten "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2020-06-26 18:39 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-08-06 09:29 +0200
Re: Image deflaten Stefan Reuther <stefan.news@arcor.de> - 2020-06-18 17:59 +0200
Re: Image deflaten Jens Kallup <kallup.jens@web.de> - 2020-06-18 19:26 +0200
Re: Image deflaten Bernhard Schornak <schornak@web.de> - 2020-06-18 19:59 +0200
csiph-web