Hallo, wenn man in/out in einem einzigen Befehl zusammenfassen könnte, wäre das ein Vorteil für die Architektur?
Alexander schrieb: > Hallo, > > wenn man in/out in einem einzigen Befehl zusammenfassen könnte, wäre das > ein Vorteil für die Architektur? Beim Bau von Hochhäuser wird das doch schon länger so gemacht.
Alexander schrieb: > wenn man in/out in einem einzigen Befehl zusammenfassen könnte, wäre das > ein Vorteil für die Architektur? Nö. Wozu auch? Falls Du aber read-modify-write Befehle meinst, die gibt es. Z.B beim 8051 kann man schreiben: xrl p1, #055h
Igori schrieb: > Beim Bau von Hochhäuser wird das doch schon länger so gemacht. Für jemanden, der sich damit beschäftigt oder sich dafür interessiert, sollte die Frage klar sein. An sinnlosen Kommentaren besitze ich wirklich kein Interesse und bitte solche auch zu vermeiden.
Alexander schrieb: > wenn man in/out in einem einzigen Befehl zusammenfassen könnte, wäre das > ein Vorteil für die Architektur? anders gefragt: was versprichst du dir davon?
Alexander schrieb: > Igori schrieb: >> Beim Bau von Hochhäuser wird das doch schon länger so gemacht. > > Für jemanden, der sich damit beschäftigt oder sich dafür interessiert, > sollte die Frage klar sein. > > An sinnlosen Kommentaren besitze ich wirklich kein Interesse und bitte > solche auch zu vermeiden. Die "Entitlement Generation" spricht.
Peter D. schrieb: > Nö. > Wozu auch? In Hochsprache habe ich einen enormen Geschwindigkeitszuwachs (Praxiserfahrung) was das Programmieren betrifft. Momentan stehe ich an dem Punkt daß ich nicht entscheiden kann ob das auch auf unterster Ebene (sprich: Prozessor-Befehlssatz) noch Gültigkeit besitzt. > Falls Du aber read-modify-write Befehle meinst, die gibt es. > Z.B beim 8051 kann man schreiben: > xrl p1, #055h Ich meinte schon direkt die Befehle "in" und "out". So daß mit einem statt zweier Befehle geschrieben oder gelesen werden kann. Karl H. schrieb: > anders gefragt: > was versprichst du dir davon? In Hochsprache bringt das Geschwindigkeitsvorteile beim Programmieren. Und meine Frage wäre konkret die, ob dies vielleicht direkt auf Prozessorebene übertragbar wäre.
Alexander schrieb: > Peter D. schrieb: >> Nö. >> Wozu auch? > > In Hochsprache habe ich einen enormen Geschwindigkeitszuwachs > (Praxiserfahrung) was das Programmieren betrifft. Mach mal ein Beispiel. Im Moment (wenn ich überhaupt richtig verstanden habe, was deine Frage ist) sehe ich nicht, wie du da einen Zuwachs kriegen könntest, ausser in ein paar Sonderfällen. Es kommt zwar vor, dass man direkt von einem Port auf einen anderen Port umkopieren möchte, aber so oft gibt es diesen Fall dann auch wieder nicht. > Momentan stehe ich an dem Punkt daß ich nicht entscheiden kann ob das > auch auf unterster Ebene (sprich: Prozessor-Befehlssatz) noch Gültigkeit > besitzt. Zunächst mal wird die Befehlsdecodierung aufwändiger. Und wenn es wirklich orthogonal sein soll, dann musst du mit dieser Transferoperation zb nicht nur von Port zu Register (in) und von Register zu Port (out) einen Transfer anleiern können, sondern natürlich auch von Port zu Port. Was dann unmittelbar das Problem auswirft, dass du die Dinge auch adressieren können musst. Das verkpmpliziert schon wieder die Befehlsabarbeitung, weil jetzt alle möglichen Datenpfade geschaltet werden können müssen.
Alexander schrieb: > In Hochsprache habe ich einen enormen Geschwindigkeitszuwachs > (Praxiserfahrung) was das Programmieren betrifft. Dann zeig dochmal, wie das aussehen soll. Alexander schrieb: > Ich meinte schon direkt die Befehle "in" und "out". > So daß mit einem statt zweier Befehle geschrieben oder gelesen werden > kann. Ich hab absolut keine Vorstellung, was Du damit meinst. Meinst Du vielleicht den XCH-Befehl?
Peter D. schrieb: > Alexander schrieb: >> In Hochsprache habe ich einen enormen Geschwindigkeitszuwachs >> (Praxiserfahrung) was das Programmieren betrifft. > > Dann zeig dochmal, wie das aussehen soll. Mir schwant da etwas. Ich will mich zwar noch nicht aus dem Fenster lehnen, aber ich denke mit Geschwindigkeitszuwachs meint er 'Zeit bei der Erstellung des Programms'. Klar. Wenn ich nicht gross darüber nachdenken muss, ob ich jetzt einen IN oder einen OUT brauche, sondern einfach nur zuweise, dann ist das einfacher. Auf der anderen Seite: genau dafür gibts ja Compiler, dass sie sich um diesen Kleinkram kümmern - auch wenn einige das nie verstehen werden.
Ich sehe im Text der Fragestellung keinen eigentlich gültigen Vergleich zwischen der (unbekannten) Hochsprache und der Maschinensprache. Irgendwie sei eine Hochsprache schneller bei der Erstellung des Programmtextes als Maschinensprache. Dabei könnte man durch detaillierte Betrachtung doch ein paar Schlüsse ziehen: 1. In einer Hochsprache (ich nehme hier mal C) wird In und Out durch die Stellung der Operatoren festgelegt. Auch das muss man sich merken, dass der Datenfluss da von rechts nach links geht. Es kann nicht beliebig geschrieben werden. 2. In einer Maschinensprache lauten die Mnemonics unterschiedlich. Wie auch immer. Es gibt einen semantischen Unterschied zwischen In und Out, in jeder Sprache die denkbar ist. (Behaupte ich jetzt mal). Sie muss auch stringent bleiben. Es kommt mir so vor, als wenn hier jemand mit relativ viel Praxis in C vergessen hat, dass er zu Anfang auch mal grübeln musste, wo denn nun die Adresse des Port-Registers hinkommt um zu lesen oder zu schreiben und ob es nun PIN oder PORT (AVR) heisst. Das wird ganz natürlich und unbewusst, hat aber einen ganz harte, festgelegten syntaktische Regel in der Hochsprache. Auf dieser unbewussten Handlung folgt dann die These, dass es doch ganz unbewusst irgendwie auch in Assembler gehen sollte. Und das ist eben ein Irrtum.
Man könnte den Unterschied noch ein wenig anders beschreiben und vielleicht dadurch klarer machen, woher die These kommt. In C, wird die Operation In oder Out durch die Stellung der Operanden gekennzeichnet - deren Abfolge in einem Ausdruck. Im Vergleich, nicht durch zwei verschiedene Literale (mal abgesehen von den zwei verschiedenen Literalen für die Port-Register z.B. beim AVR - da gibt es Gegenbeispiele von anderen uCs und uPs). In Maschinensprache wir der Unterschied durch zwei verschieden syntaktische Elemente (Literale) gekennzeichnet. Im Vergleich also nicht durch ihre Position im Programmtext in Beziehung zu anderen Elementen ('='-Operator).
Karl H. schrieb: > Alexander schrieb: >> Peter D. schrieb: >>> Nö. >>> Wozu auch? >> >> In Hochsprache habe ich einen enormen Geschwindigkeitszuwachs >> (Praxiserfahrung) was das Programmieren betrifft. > > Mach mal ein Beispiel. > Im Moment (wenn ich überhaupt richtig verstanden habe, was deine Frage > ist) sehe ich nicht, wie du da einen Zuwachs kriegen könntest, ausser in > ein paar Sonderfällen. Es kommt zwar vor, dass man direkt von einem Port > auf einen anderen Port umkopieren möchte, aber so oft gibt es diesen > Fall dann auch wieder nicht. In Hochsprache hab ich mir ein Framework für folgenden Befehl zusammengebaut: ON register [SET data] Dieser funktioniert folgendermaßen: Um Daten zu lesen lasse ich den SET-Teil weg und definiere nur das Register aus dem gelesen werden soll. Um Daten zu schreiben wird zusätzlich zur Register-Angabe der SET-Teil definiert. Sprich durch Parameterkonfiguration lassen sich zwei getrennte Befehle (in/out) auf Einen reduzieren. Der Befehl ist in Hochsprache noch etwas umfangreicher. Allerdings ist meines Wissens nach nur dieser Teil auf Prozessorebene denkbar. >> Momentan stehe ich an dem Punkt daß ich nicht entscheiden kann ob das >> auch auf unterster Ebene (sprich: Prozessor-Befehlssatz) noch Gültigkeit >> besitzt. > > Zunächst mal wird die Befehlsdecodierung aufwändiger. Und wenn es > wirklich orthogonal sein soll, dann musst du mit dieser > Transferoperation zb nicht nur von Port zu Register (in) und von > Register zu Port (out) einen Transfer anleiern können, sondern natürlich > auch von Port zu Port. > Das verkpmpliziert schon wieder die Befehlsabarbeitung, weil jetzt alle > möglichen Datenpfade geschaltet werden können müssen. Reicht das obige Beispiel aus um entsprechende Rückschlüsse zu ziehen?
Alexander schrieb: > In Hochsprache hab ich mir ein Framework für folgenden Befehl > zusammengebaut: In welcher Hochsprache? > ON register [SET data] > > Sprich durch Parameterkonfiguration lassen sich zwei getrennte Befehle > (in/out) auf Einen reduzieren. Hm. Ob man das als "Parameter" bezeichnet oder als syntaktische Struktur ist (meiner Meinung nach) durchaus entscheidbar. Zunächst haben funktionale Sprachen Parameter resp. Argumente. Ist Deine Hochsprache eine? Ist, was Du da beschreibst ein Funktionsaufruf? Oder ist es ein Ausdruck? Oder etwas Drittes?
Ich bin zunächst nur neugierig; ich denke aber dass es helfen könnte etwas über Deinen Hintergrund zu wissen: Entwirfst Du eine eigene Sprache? Wieviel Erfahrung im Compilerbau resp. Sprachdefinition hast Du? Wieviel Erfahrung in der Programmierung? Bist Du Student? Oder Profi? Es ist zwar nicht an sich negativ, aber Deine Ausdrucksweise kommt mir nicht ganz stringent vor. Das kann vorkommen, und ist in gewissem Maß akzeptabel. Aber es wirft halt (für mich) die obigen Fragen auf.
Alexander schrieb: > Sprich durch Parameterkonfiguration lassen sich zwei getrennte Befehle > (in/out) auf Einen reduzieren. Ich habe da ein grundsätzliches Verständnisproblem. Wenn ich lese, mache ich einen In. Wenn ich schreibe, mache ich einen Out. Das ist nur jeweils ein Befehl. Warum brauchst Du da zwei? Willst Du etwa gleichzeitig mit einem Befehl lesen und schreiben? Bei welcher Hardware bzw. Schnittstelle wäre das sinnvoll?
Alexander schrieb: > In Hochsprache hab ich mir ein Framework für folgenden Befehl > zusammengebaut: > > ON register [SET data] > > Dieser funktioniert folgendermaßen: > > Um Daten zu lesen lasse ich den SET-Teil weg und definiere nur das > Register aus dem gelesen werden soll. Sehr merkwürdig. Wenn ich in deiner "Programmiersprache" also irgendwelche Daten lesen wollen würde, dann müßte ich dazu
1 | ON datenquelle |
schreiben? Und wohin werden die Daten dann gelesen? Wie kann ich die weiterverarbeiten? Liegt das nun an mir oder ergibt das auch für andere überhaupt keinen Sinn?
Alexander schrieb: > wenn man in/out in einem einzigen Befehl zusammenfassen könnte, wäre das > ein Vorteil für die Architektur? Eher nicht. Wenn man Speicher (LD, MOV) und I/O (IN, OUT) zusammenfasst hat das einen Flexibilitätsvorteil, beispielsweise kann ein und dasselbe Programm
1 | char *port = 0x1234; |
2 | *port='A'; |
dann entweder mit echter Peripherie (wenn 1234 ein I/O Adresse im von Neumann Adressraum ist) oder mit simulierter Peripherie (wenn 1234 eine Speicheradresse ist, z.B. bedient von einem Interrupt-gesteuerten Routine den port per USB simuliert) zusammenarbeiten, je nach (ggf. konfigurierter, also gar nicht im Programm stehender) Adresse. Allerdings müsste man für grösstmögliche Implementierungsflexibilitäöt und -Effizienz trotzdem einen Interrupt auslösen können beim beschreiben der Speicherstelle, da kann man gleich eine Instruction-Trap beim schreiben auf nicht vorhandenes I/O verwenden. Aber die Richtung, ob IN oder OUT, ist vorgebenen. Wenn man also schon Speicher und I/O trennt (Harvard/Neumann) dann hat man keinen Vorteil von einem INOUT Befehl, man kann sogar LD und MOV verwenden von zum Speicher ins Register und vom Register zum Speicher.
Axel S. schrieb: > Alexander schrieb: >> In Hochsprache hab ich mir ein Framework für folgenden Befehl >> zusammengebaut: >> >> ON register [SET data] >> ache" also irgendwelche Daten lesen > wollen würde, dann müßte ich dazu > > >
1 | > ON datenquelle |
2 | > |
> > schreiben? Und wohin werden die Daten dann gelesen? Wie kann ich die > weiterverarbeiten? Liegt das nun an mir oder ergibt das auch für andere > überhaupt keinen Sinn? Ich könnte mir schon denken, dass er entweder selbst eine Sprache entwirft oder eine Sprache verwendet, die solche Definitionen erlaubt - als einfaches Beispiel FORTH oder ähnliches.
Irgendwie passt Ausdrucksweise, Lakonie und das Ziel - schnelles erstellen von Programmtexten - sowie die Fragestellung nicht zusammen. Aber das mag an der Kürze der Kommunikation bis jetzt liegen. Offen gesagt, mag ein oller Fortran- oder Pascal-Programmierer wohl mal an der "Geschwätzigkeit" seiner Sprache herummäkeln, aber das man versucht "schnell zu programmieren" ist mir irgendwie noch nie untergekommen. Aber gut. Es gibt immer wieder was Neues.
Ich hab jetzt den gesamten Thread durchgelesen und habe immer noch keine Ahnung wovon der TE hier redet und was er wie wo wann warum genau möchte. Evtl. wäre es günstig deutlich konkreter zu werden? Was genau ist ein "in"? Was genau ist ein "out"? Was genau ist ein "Befehl"? Auf welcher Hardware-Architektur genau (Mikrocontroller xyz, Intel x86, IBM Mainframe) oder Software-Ebene (x86 Microcode, x86 Assembler, C, C++, Python) oder Protokoll-Ebene (TCP/IP-Stack? USB-Protokoll? CAN-Bus?) oder sonstigem unbekannten Zeug soll hier was genau gemacht werden? Was genau ist mit Architektur gemeint? Und Architektur von was (Mikrocontroller Hardware-Architektur? x86 Microcode-Architektur? Architektur eines unbekannten C Programms? Architektur eines Compilers/Interpreters? Architektur eines verteilten Systems? Architektur eines Feldbusses mit In und Out Befehlen? Architektur eines Protokolls?)? Was genau sieht der TE als "Vorteil" bei so einer (nicht näher definierten) Architektur? Was genau ist ein "enormer Geschwindigkeitszuwachs"? Compile-Zeit? Laufzeit? Übertragungsrate? Unter welchen Umständen? Bei welcher Art Operation? Zeit die ein Entwickler braucht ein Programm zu designen? Zu implementieren? Zu warten? Zu verstehen? Die Liste könnte man beliebig weiterführen, da nun wirklich gar nichts spezifiert wurde.
Frank M. schrieb: > Willst Du etwa gleichzeitig mit einem Befehl lesen und schreiben? Bei > welcher Hardware bzw. Schnittstelle wäre das sinnvoll? Bei SPI zum Beispiel ist das sowohl sinnvoll als auch auch mehr oder weniger unvermeidlich. Ich bezweifle aber das der TE darauf hinaus wollte, aber wer weiss das schon...
Alexander schrieb: > In Hochsprache hab ich mir ein Framework für folgenden Befehl > zusammengebaut: > > ON register [SET data] > > Dieser funktioniert folgendermaßen: > > Um Daten zu lesen lasse ich den SET-Teil weg und definiere nur das > Register aus dem gelesen werden soll. > > Um Daten zu schreiben wird zusätzlich zur Register-Angabe der SET-Teil > definiert. > > Sprich durch Parameterkonfiguration lassen sich zwei getrennte Befehle > (in/out) auf Einen reduzieren. > > Der Befehl ist in Hochsprache noch etwas umfangreicher. Allerdings ist > meines Wissens nach nur dieser Teil auf Prozessorebene denkbar. Ich denke immer noch, du wirfst du jetzt Äpfel mit Birnen in einen Korb. Was du da beschreibst, das ist eine Möglichkeit, wie du dir in deiner Hochsprache das Leben leichter machst. Das ist legitim aber letzten Endes eine reine Komfort-Frage. Klar, auch auf Assembler-Eben kann man sich das Leben leichter machen. Das nennt man dann normalerweise Makros. Aber was hat das jetzt mit der Architektur zu tun, und ob die auf Prozessorebene verschiedene Instruktionen für IN und OUT hat, oder ob sie beides in einer MOVE Instruktion zusammenfasst? Denn letzten Endes muss ja auch dein Hochsprachenkonstrukt wieder irgendwann in IN und OUT aufgedröselt werden. Bei dir macht das der Compiler (oder Interpreter), in einem Makro Assembler ist es dann eben der Makro-Meschanismus aber letzten Endes ist für die Prozessorarchitektur nur das wesentlich, was in allen Fällen letzten Endes an Prozessor Instruktionen übrig bleibt. Ich werde das Gefühl nicht los, dass du da jetzt ganz einfach verschiedene Ebenen komplett durcheinanderwirfst. Das eine sind die Möglichkeiten, wie man in einer Programmiersprache Dinge ausdrückt bzw. wie man sich mit höheren Konstrukten Komfort schaffen kann und das andere ist das nackte Silizium, welche vorgegebene Befehle abarbeitet. In einem gewissen Sinne ist das wie in einer Textverarbeitung, die aus diversen Angaben Serienbriefe produzieren kann und dem Drucker, der sie ausdruckt. Dem Drucker ist das völlig wurscht, wie ein einzelner Brief entstanden ist, egal wie komfortabel es in der Textverarbeitung ist, einen Serienbrief zu erstellen. Der Drucker hat deswegen auch nicht mehr oder weniger Arbeit, die einzelnen Pixel aufs Papier zu bringen. Und umgekehrt beeinflusst die Drucker-Architektur nicht, wie komfortabel du Serienbriefe erstellen kannst. Das eine ist vom anderen recht unabhängig.
Karl H. schrieb: > Aber was hat das jetzt mit der Architektur zu tun, und ob die auf > Prozessorebene verschiedene Instruktionen für IN und OUT hat, oder ob > sie beides in einer MOVE Instruktion zusammenfasst? Jetzt wo du es erwähnst: der Z8 hat 256 "Speicherstellen" die man wahlweise als RAM oder als Registerbank betrachten kann und in die auch die IO-Ports und SFRs gemapt sind. Und da der Befehlssatz keinen Akku kennt, kann jedes Register als Ziel oder als Quelle einer Operation dienen. Man kann dann also in einem Programm tatsächlich
1 | LD PORTA, PORTB |
schreiben, was einem IN von Port B und einem OUT auf Port A entspricht. Allerdings scheint das so gar nicht das zu sein was dem TE vorschwebt.
Michael B. schrieb: > Alexander schrieb: >> wenn man in/out in einem einzigen Befehl zusammenfassen könnte, wäre das >> ein Vorteil für die Architektur? > > Eher nicht. > > Wenn man Speicher (LD, MOV) und I/O (IN, OUT) zusammenfasst hat das > einen Flexibilitätsvorteil, > > > Aber die Richtung, ob IN oder OUT, ist vorgebenen. Wenn man also schon > Speicher und I/O trennt (Harvard/Neumann) dann hat man keinen Vorteil > von einem INOUT Befehl, man kann sogar LD und MOV verwenden von zum > Speicher ins Register und vom Register zum Speicher. Vielen Dank, Michael. Die Richtung ist vorgegeben. Das ist der springende Punkt.
Alexander schrieb: > Michael B. schrieb: >> Alexander schrieb: >>> wenn man in/out in einem einzigen Befehl zusammenfassen könnte, wäre das >>> ein Vorteil für die Architektur? >> >> Eher nicht. >> >> Wenn man Speicher (LD, MOV) und I/O (IN, OUT) zusammenfasst hat das >> einen Flexibilitätsvorteil, >> >> >> Aber die Richtung, ob IN oder OUT, ist vorgebenen. Wenn man also schon >> Speicher und I/O trennt (Harvard/Neumann) dann hat man keinen Vorteil >> von einem INOUT Befehl, man kann sogar LD und MOV verwenden von zum >> Speicher ins Register und vom Register zum Speicher. > > Vielen Dank, Michael. > Die Richtung ist vorgegeben. Das ist der springende Punkt. Hä? Ich muss wohl unterzuckert sein. Der Unterschied zwischen Harvard und Neumann ist die Trennung von Programm- und Datenspeicher und nicht der von I/O und Speicher. Da redet man von Memory-Mapped-IO. Aber Michael B.s Beiträge lese ich schon lange nicht mehr. Zunächst einmal muss grundsätzlich eine Universal-Maschine in beide Richtungen Daten schicken können. Dann muss der Programmierer durch welche Ausdrucksmittel auch immer, diese Richtung bestimmen, benennen, festlegen, beschreiben können. Das ist nicht vorgegeben, sondern ergibt sich aus der Zweckbestimmung des Apparates. So muss seine Konstruktion sein. Ich bin raus und suche nach Zucker. Wohl doch nur Wochenendzirkus. Mahlzeit.
Alexander schrieb: > Vielen Dank, Michael. > Die Richtung ist vorgegeben. Das ist der springende Punkt. Die Richtung ist IMMER irgendwie vorgegeben. Wie das genau passiert ist doch gar nicht so wesentlich und macht auch nicht den grossen Zeitunterschied in der Programmierung aus. Auf der einen Seite will man nicht zu viele Memnonics haben, weil man sich die ja auch merken muss, auf der anderen Seite ist es aber auch sinnvoll hewisse Redundanzen in die Programmiersprache einzubauen, weil sie eine Konsistenzprüfung erlauben und dabei so manchen Fehler abfangen.
Alexander schrieb: > wenn man in/out in einem einzigen Befehl zusammenfassen könnte, Bei meiner CPU gibt es den IO-Befehl H, der sowohl für Ausgabe als auch für Eingabe einsetzbar ist, auch gleichzeitig. http://www.mikrocontroller.net/articles/8bit-CPU:_bo8
Zur Funktionsweise des IO-Befehls H bei meiner CPU: Es wird das Doppelregister AB auf dem Adressbus ausgegeben und der Datenbus nach A eingelesen. (A und B sind je 8bit breit.) Die Wirkung hängt ab von der peripheren Hardware. Typischerweise fungiert B, also die unteren 8 Bit des Adressbus, als Port-Adresse oder Kommando, und er alte Wert von A, also die oberen 8 Bit des Adressbus, als Ausgabedaten. Die Ausgabedaten oder der nach A eingelesene Input werden gegf. ignoriert.
Rufus Τ. F. schrieb: > Das war zu befürchten. Scheisse. Jetzt musste ich doch fett grinsen. :-))))))))
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.