Groups | Search | Server Info | Login | Register


Groups > de.comp.lang.assembler > #1205

Re: Image deflaten

From Stefan Reuther <stefan.news@arcor.de>
Newsgroups de.comp.lang.assembler
Subject Re: Image deflaten
Date 2020-06-26 18:30 +0200
Message-ID <rd5erm.148.1@stefan.msgid.phost.de> (permalink)
References (5 earlier) <rctnc9$l0o$1@dont-email.me> <rd0336.450.1@stefan.msgid.phost.de> <rd0cnv$hlp$1@dont-email.me> <rd2qg0.4so.1@stefan.msgid.phost.de> <rd4fhk$lac$1@dont-email.me>

Show all headers | View raw


Am 26.06.2020 um 11:35 schrieb Bernhard Schornak:
> Stefan Reuther schrieb:
>>>> 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.
> 
> Ach? Schiebebefehl visuell anschaulich dargestellt:

Der Schiebebefehl ist an der Adressgenerierung nicht beteiligt.

> Dokumentation der Prozessorhersteller (nicht ganz so anschaulich):
> 
> http://developer.amd.com/wordpress/media/2008/10/24594_APM_v3.pdf
> 
> => Seite 306 - SAL/SHL

Da steht, dass der Befehl zwei Dinge tut: "Shifts the bits...",
"...discards bits shifted out...". Das verwerfen der rausgeschobenen
Bits ist also kein intrinsisches Verhalten der Operation "shift".

>> Intels Definition der Adressgenerierung im Real Mode hingegen ist:
>>
>> # 14.1  Physical Address Formation
>> #
>> # The 80386
> 
> Ist kein 8086. Das hier
> 
> https://edge.edx.org/c4x/BITSPilani/EEE231/asset/8086_family_Users_Manual_1_.pdf
> 
> ist ein 8086. Passend zum Thema: Seiten 2-7 ff.
> 
> Bild 2-18 auf Seite 2-13 ist wohl die Ursache für die später entstandene
> Missdeutung, dass die Segmentregister "nach Links geschoben" würden.

"shift left 4 bits" ist ziemlich eindeutig.

> Die linke Seite zeigt das interne Register, in dem alle
> Adressen generiert werden, die rechte Seite Offset- und Segmentregister.
> Dieses versetzte Kopieren war damals hardwaremäßig wesentlich schneller,
> als die langsame Bitschieberei: Der 8086 benötigte m. W. pro geschobenem
> Bit einen vollen Taktzyklus, für vier Bit wären also 4 Takte "verbraten"
> worden. Abgesehen davon (wie bereits im letzten Post erwähnt!) existiert
> kein Schiebebefehl für Segmentregister. Außer MOV, PUSH und POP ist kein
> einziger "general purpose" Befehl für Segmentregister zulässig.

Du haust immer wieder "die mathematische Operation 'shift'" und "den
Prozessorbefehl 'shift'" durcheinander. Warum soll ich, wenn ich ein
Stück Silizium baue, händisch irgendwelche Daten durch eine ALU fummeln,
wenn ich einfach ein paar Drähte schief anlöten kann?

[weitere Verkomplizierungen gelöscht]

>> Man muss es ja nun nicht schwerer machen als es ist. Effektive Adresse =
>> 16*Segment + Offset. Fertig.
> 
> Und worin unterscheidet sich das nun von meiner am 23.06.2020 geposteten
> Aussage "Adresse = SegmentRegister * 16 + Offset"? ;)
> 
> Um es noch einmal deutlich zu machen: Es geht mir *einzig und allein* um
> die Formalie, dass man in 16-Bit-Registern 20 Bit breite Daten weder ab-
> legen noch manipulieren kann.

Das hat ja auch niemand außer dir behauptet.

>  Das von iNTEL fälschlicherweise angeführte
> "shift left 4 bits" führt zwar - ebenso wie eine Vielzahl anderer Wege -
> zum korrekten Ergebnis, ist aber nicht das, was sich auf *Hardwareebene*
> tatsächlich abspielt.

"Ein Geisterfahrer? Hunderte!"

> Mag sein, dass sich das nur Leuten erschließt, die mit TTL und CMOS groß
> geworden sind...

Also wenn ich einen Wert vor dem Addieren um 4 Stellen nach links
shiften will, bau ich keinen Shifter ein, sondern löte die Drähte
passend an den Addierer.

Das gleiche macht(e) Intel in ihrem Prozessor. Und deswegen haben sie
auch kein Problem damit, dass das mit einem 'shl'-Befehl in einem
16-Bit-Register nicht funktionieren würde.


  Stefan

Back to de.comp.lang.assembler | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

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