![]() |
Status-/Flagregister auf Hardwareebene?
Hallo zusammen,
ich hab mal wieder eine Frage zum 8086er... Folgendes: Ich habe in meinem Assembler-Buch und im Internet (Wikipedia, ![]() Nun meine Frage: Was ist denn richtig? Alternativ: Wie komme ich an einen Bauplan eines 8086ers? Gruß Mr_G |
Re: Status-/Flagregister auf Hardwareebene?
Ich kenne mich mit Hardwarearchitektur wirklich nicht aus, aber mit dem Befehl pushf ist es möglich, alle Flags als DWord auf dem Stack abzulegen. Außerdem wird auch beim Speichern des CPU-Kontexts in einem Task-State Segment (TSS) diese Form verwendet. EFLAGS wird in den Handbüchern als Register-Name gebraucht. Das spricht durchaus dafür, dass die Flags zusammen abgelegt sind.
|
Re: Status-/Flagregister auf Hardwareebene?
Also soweit ich weiß, gibt es Befehle, das ganze Statusregister zu "retten", was ja auch sinnvoll und notwendig ist für Multiprocessing-/threading und Ausnahmen-/Unterbrechungsbehandlung. Daher wäre eine Gruppierung auch auf Hardwareebene schon sinnvoll, ansonsten wäre es natürlich sinnvoller, die arithmetischen Register bei der ALU und den Rest da, wo er gebraucht wird, unterzubringen. Aber wie gesagt, aufgrund der Rettungsbefehle und weil die meisten Flags sowieso arithmetisch sind, müsste das schon zusammen in einem Register sein, irgendwo in der Nähe der ALU.
|
Re: Status-/Flagregister auf Hardwareebene?
Zitat:
das ist barer Unsinn - es ist völlig wurscht, ob die Statusbits in einem Register nebeneinander angeordnet sind oder sonstwo in der Hardware (wer sollte das denn feststellen - in den Masken danach suchen???). Die Frage ist lediglich, ob man die fraglichen Bits auch als Register am Stück lesen und ev. auch schreiben kann. Das geht aber auch, wenn die Bits aus Status usw. erst im Moment des Lesens auf den Bus zusammengefasst werden, das sagt also auch nichts über den physikalischen Speicherort aus. Wie gesagt, der ist ja auch völlig egal. Besonders Embedded Prozessoren sind voll von solchen (Pseudo-)Registern, z.B. 8051, da gibt es Register für die Einausgänge ebenso wie für alle Steuerbits, Clock-Teiler, Interrupt-Enables, usw. usw. alles zusammengefasst in einem SFR-File, z.B. 128 Special Function Register. Das steuert die gesamte Hardware. Niemand wird dir oder deinem Lehrer verraten, was wo gespeichert ist. Gruss Reinhard Nachtrag: es ist auch für die Funktion völlig egal. Es gibt unzählige Abkömmlinge vom 8051, da ist das sicher auch unterschiedlich gelöst. Und inzwischen bekommst du auch einen 8051 (oder Z80 oder oder) als IP, d.h. als logische Beschreibung, die du selbst in dein FPGA hineincompilieren kannst. |
Re: Status-/Flagregister auf Hardwareebene?
Zitat:
|
Re: Status-/Flagregister auf Hardwareebene?
Danke erstmal für die Antworten!
Zitat:
@generic: Danke für den Tipp. Habe bis dato aber noch nichts gefunden. @3_of_8 & Apollonius: Das mit dem "retten" und laden der Flags via pushf und popf ist mir auch schon aufgefallen. Das ist natürlich leider nicht aussagekräftig wie Reinhard anmerkte: Zitat:
|
Re: Status-/Flagregister auf Hardwareebene?
Hi,
hm ich bin zwar keiner der sich auf der dieser Hardwareebene auskennt, aber theoretisch gesehen müssen die Bits bei einem normalen Register wie EAX auch nicht direkt "nebeneinander" liegen, auch wenn man davon ausgehen kann ;) So gut wie fast jeder Befehl greift auf Register wie EAX zu und kann diese lesen und verändert. Wieso sollte das Statusregister (wenn es von Intel schon Register genannt wurde) nicht auch sich so verhalten wie ein normales Register? Auch auf dieses Statusregister kann jeder Befehl zugreifen und gegebenenfalls ein oder mehrere Flags verändern. Eine Trennung der Bits auf Hardwareebene würde nur Sinn machen, wenn nur eine kleine Befehlsgruppe darauf zugreift, aber es gibt Flags im Statusregister, die von einer ganzen Reihe unterschiedlicher Befehle verändert werden können. Auch denke ich dass das Trennen der Bits deutlich mehr Aufwand nach sich zieht, um das zu implementieren. Grüsse, Stefan |
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz