Groups | Search | Server Info | Login | Register
Groups > de.comp.lang.assembler > #1205
| 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> |
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 | 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