Hallo, Josef G. schrieb: > Das ist Geschmackssache, ob man einen Registerzugriff > und einen Speicherzugriff, mit unterschiedlicher Dauer, > als gleiche Operation empfindet oder nicht. mich interessiert, daß Wert x aus Quelle y in Register z landet. Mich interessiert nicht, wielange das jeweils dauert. Ich habe auf dem C64 (6510) Takte gezählt, um die VIC-Register passend umzuschalten, damit die Ränder aus sind. Ich habe manchmal in einer ISR Takte gezählt, um sicher zu sein, daß mir auch im ungünstigsten Fall noch genug Rechenzeit für den Rest bleibt. Wann sonst sollte ich wissen wollen oder müssen, wielange eine Befehlsausführung braucht? PS: ich habe mich mal durch den Thread Beitrag "8bit-Computing mit FPGA" gewühlt. Ich habe auch hier fast alles mitgelesen. Du bist vermutlich wirklich eine etwas mißglückte Inkarnation von ELIZA. Weizenbaum hätte an den Threads vermutlich seine Freude oder wäre noch entsetzter als damals. Gruß aus Berlin Michael
:
Bearbeitet durch User
Josef G. schrieb: > Befehlssatz der bo8-CPU - was ist gut, was ist schlecht Fazit: Also die Doku ist schlecht, die Mnemonics zumindest extrem ungewohnt. Schlecht im Sinne von: für 99,995% der Nutzer nicht ausreichend. Da nun verschiedene Leute die eine oder andere Diagnose zur Ignoranz der Argumente geliefert haben, meine Frage an die Psychologen: Wie geht man mit Josef um? 1. Mehr Aufmerksamkeit verschaffen, indem man tatsächlich Programme für das Ding schreibt? Oder 2. wie mit einen Troll: ignorieren? oder 3. ... Gerald
@ Gerald (Gast) >Wie geht man mit Josef um? DAS ist mal eine sinnvolle Frage. >1. Mehr Aufmerksamkeit verschaffen, indem man tatsächlich Programme für >das Ding schreibt? Oder Bis du Masochist? Oder leidest du am Samariter-Komplex? >2. wie mit einen Troll: ignorieren? oder Sinnvoll und pragmatisch. >3. ... Man kann es auch als Belustigung betrachten. Aber auf KEINEN Fall ernst nehmen und mit der Illusion diskutieren, daß Josef auch nur ANSATZWEISE was versteht oder gar einsieht, daß er in seinem Projekt mehrere Fehler bzw. totalen Mist drin hat.
Josef G. schrieb: > Rufus Τ. F. schrieb: >> Die Operation ist immer die gleiche: >> >> move > > Das ist Geschmackssache, ob man einen Registerzugriff > und einen Speicherzugriff, mit unterschiedlicher Dauer, > als gleiche Operation empfindet oder nicht. Aus Sicht auf das logische Modell einer CPU schon. Es geht darum, Daten von A nach B zu bekommen. Ob A und B nun Register sind oder Speicher oder IO-Ports, das ist aus logischer Sicht unerheblich. Wenn ich etwas auszusetzen hätte, dann am Wort "move". Denn umgangs- sprachlich hat es die Bedeutung, etwas zu verschieben. Nach dem Verschieben befindet es sich im Ziel und nicht mehr in der Quelle. Aus sprachlicher Sicht ist die Operation eher "copy" - es wird eine Kopie der Daten am Ziel angelegt. Auch "transport" würde passen. Oder eben "load" - was für mich außerdem den Charme hat, daß ich damit aufgewachsen bin (Z80). Details über die Art der Operanden (Register, Immediate oder Speicher auf die eine oder andere Art adressiert) schreibt man sinnvollerweise an den Operanden, so wie Rufus das oben gezeigt hat. Und wenn man das jetzt auch für die Operanden anderer Befehlsgruppen so macht (z.B. ALU- Operationen) dann kriegt man am Ende einen hübsch orthogonalen und leicht lernbaren Befehlssatz.
Moin, jetz hab ich den Thread doch wieder angeklickt, da Geralds Frage doch eine recht gute ist. Die Frage muss sich der Forenbetreiber schlussendlich stellen. Mein Fazit ist, dass die Qualität der hiesigen Beiträge in den letzten Jahren massiv in den Keller gegangen ist. Das hat u.a. mit vielen Usern zu tun, die man als "Störer" betrachten könnte. Diese halten zwar die Netiquette oberflächlich ein, aber stören mit Beiträgen, die dem allgemeinen Konsens entgegenlaufen oder völlig bezugsfrei dazu sind. Leider kann man da kaum noch Argumente hinzufügen, sondern: es nervt. Wie irgendwann eben ELIZA: User: "Schwarz ist nicht weiss" Eliza: Warum ist schwarz nicht weiss? Wir hatten es mal in einer Physik-Diskussionsgruppe mit einem zu tun, der die Drehimpulserhaltung widerlegt haben wollte, und davon mehr überzeugt zu sein schien, als Einstein mit seiner Speziellen RT. Das Ende vom Lied war, dass die NNTP-Admins (ach, ist das lange her) den Nutzer schliesslich sperrten, um weitere üble Flamewars zu verhindern. Das erschien aus mehreren Gründen legitim: - Manchmal muss man Nutzer vor sich selbst (und Mobbing durch andere) schützen - Forenbetreiber sollten auch einer beitragenden Community (die einen gewissen "Standard" erwartet) gegenüber eine gewisse Sorgfaltspflicht walten lassen Die einfachste Variante für mich persönlich ist natürlich, mich einfach auszuklinken und von weiterem Knowhow-Austausch komplett abzusehen. Damit überlässt man schlussendlich das Feld den Thread-Messies. Ob das so soll....darüber kann man sich streiten :-) Grüsse, - Strubi
Gerald schrieb: > 3. ... > > Gerald Man könnte im ersten Schritt den ganzen Thread ins Offtopic verfrachten. Das eigentliche Thema ist hinreichend durchgekaut und das PingPong-Spiel zwischen bome und dem Rest hat mit dem Thema nicht mehr viel gemein.
:
Wiederhergestellt durch Moderator
Josef G. schrieb: > Was möchtest du lieber hundertmal schreiben müssen, > GTMX oder move a,(X) ? Zweiteres. Das ist lesbar. Ersteres hat etwa so viel Aussage wie 7§k@%. Mit copy-paste auch genau so viel Aufwand. Und wenn ich wirklich unbedingt solchen Spaghetticode produzieren müsste, dann würde ich vermutlich ein Makro machen. Und das würde dann ehr 'max' heißen. Gruß Jobst
Josef G. schrieb: > Ich sehe da eine große Ähnlichkeit. Man muss eb begriffen haben, um unterscheiden zu können. Gruß Jobst
Falk B. schrieb: > Oder leidest du am Samariter-Komplex? Machen das nicht alle, die hier (sinnvoll) auf eine Frage antworten? > Man kann es auch als Belustigung betrachten. Das hilft im Leben auch an anderen Stellen öfter mal weiter. BTDT. :-) Martin S. schrieb: > Mein Fazit ist, dass die Qualität der hiesigen Beiträge in den letzten > Jahren massiv in den Keller gegangen ist. Das hat u.a. mit vielen Usern > zu tun, die man als "Störer" betrachten könnte. Diese halten zwar die > Netiquette oberflächlich ein, aber stören mit Beiträgen, die dem > allgemeinen Konsens entgegenlaufen oder völlig bezugsfrei dazu sind. Nunja, das 'Problem' gab es ja schonmal: https://de.wikipedia.org/wiki/Eternal_September Je einfacher der Zugang ist, und je mehr Leute dabei sind, um so mehr hat das (gefühlt) negative Auswirkungen auf's Niveau. Ich denke aber, daß nur ein sehr geringer Teil bewusst provozieren will. Der große Anteil fragt und antwortet 'so gut' wie er eben kann. Insofern ist Deine Beobachtung zur Qualität in meinen Augen ein ganz normaler Vorgang. Außerdem kommt ja noch hinzu, das das eigene Wissen stetig wächst (wenn man was dafür tut). Als Studi habe ich mich immer über die geforderten xx Jahre Berufserfahrung in Stellenanzeigen lustig gemacht. So langsam bekomme ich inzwischen eine Ahnung von der Bedeutung der Erfahrung... Автомат К. schrieb: > Man könnte im ersten Schritt den ganzen Thread ins Offtopic verfrachten. Das wäre tatsächlich eine Maßnahme. Gibt es hier nicht auch ein Bewertungssystem, für die angemeldeten Teilnehmer? Wo steht denn der Thread momentan? Gab es da nicht auch mal ein Usenet-Law, von wegen je länger der Beitrag, desto mehr Off-Topic? Andererseits gibt es ja auch immer noch Beiträge mit Verbesserungsvorschlägen zu den Mnemnonics. Für diese Beiträge gilt (leider) Falks Aussage: > Aber auf KEINEN Fall ernst > nehmen und mit der Illusion diskutieren, daß Josef auch nur ANSATZWEISE > was versteht oder gar einsieht, daß er in seinem Projekt mehrere Fehler > bzw. totalen Mist drin hat. Gerald
Josef G. schrieb: > Gilt entsprechend auch bei mir. > Gilt auch bei mir. > Wenn man sich an sie gewöhnt hat. Und das gilt auch bei mir. > Ich sehe da eine große Ähnlichkeit. Dass Du diesen Thread eröffnet hast und speziell die Wahl der Topic "was ist gut, was ist schlecht" zeugt von Heuchelei. Wenn man den Thread beobachtet, gibt's viele User die kritisieren und vorschlagen und einen User "Bome", der sein schwachsinniges Softwarekonstrukt verteidigt. Da ist nichts zu erkennen von einem Verstehen, von Einsicht und vom Willen die Argumente und Kritik aufzugreifen und zu verarbeiten. Es findet nur eine laufende Abwehr jeglicher Ratschläge statt. Und genau da ist die Ursache für den von Dir produzierten Murks: Du bist geistig versteinert und gefangen in Deinem kleinen Gefängnis aus Einbildung, Sturheit und verirrten Annahmen. Sicher darf man an ein Ziel glauben und dies nachdrücklich verfolgen, dies auch gegen Widerstände. Aber man sollte dabei lernen und verbessern, immer wieder, eben das was Evolution ausmacht. Unsinniger Stolz und Borniertheit hat in der Evolution auch nichts zu suchen. Das ist das, was Du nicht kannst, Du bist nicht bereit zu lernen und Ratschläge anzunehen. Und deswegen ist das Ding hier so eine Krücke trotz der enormen Arbeitsleistung, die Du reingesteckt hast, das wird auch nichts mehr. Vom eigenen Anspruch, Kleincomputer für jedermann, bist Du doch soweit entfernt, wie es nur irgend möglich ist. Und so ist alles, was Du erreichst oder aus diesem Thread erhältst, ein wenig Aufmerksamkeit. Dann solltest Du im nächsten Thread auch den Titel so wählen, schreib' dann einfach: "Bome braucht Aufmerksamkeit, bitte keine Ratschläge". So ein Titel wäre dann wenigstens ehrlich und nicht so geheuchelt, wie dieser hier.
Da die Standpunkte ausgetauscht, die Meinungen bekannt und alles westliche gesagt wurde (nur noch nicht von jedem), wäre es IMHO angebracht, diesen Thread zu schließen. @Mods: Wäre dies möglich?
Martin S. schrieb: > Nutzer schliesslich sperrten, um weitere üble Flamewars zu verhindern. > Das erschien aus mehreren Gründen legitim: > - Manchmal muss man Nutzer vor sich selbst (und Mobbing durch andere) > schützen > - Forenbetreiber sollten auch einer beitragenden Community (die einen > gewissen "Standard" erwartet) gegenüber eine gewisse Sorgfaltspflicht > walten lassen In wie vielen Threads schreibt Josef G.? Wie viele neue Threads macht er pro Woche auf? In wie vielen Threads schiebt er bis zum Umfallen Off-topic und persönliche Diffamierung dazu und stört Threads immer wieder? Die waren Neurotiker sind ja wohl mehr als offensichtlich andere! > Die einfachste Variante für mich persönlich ist natürlich, mich einfach > auszuklinken und von weiterem Knowhow-Austausch komplett abzusehen. > Damit überlässt man schlussendlich das Feld den Thread-Messies. Ob das > so soll....darüber kann man sich streiten :-) Deine Ansichten sind wertgeschätzt. Aber es ist nun wirklich kein großer Verlust, wenn Du in diesen 2 Threads nichts mehr schreibst. > jetz hab ich den Thread doch wieder angeklickt, da Geralds Frage doch > eine recht gute ist. Eben. Scheinbar gar nicht so einfach, diesen einen Thread von Hunderten einfach NICHT anzuklicken und durchzulesen, nur um sich dann (wieder) darüber aufzuregen. Also: Weils die Neurotiker nicht schaffen, den Thread NICHT anzuklicken, soll er geschlossen werden? Und wenn nicht, dann wird der Thread einfach so lang weiter zugemüllt: Auf jeden Beitrag von Josef G. 5x BS-Antworten, die dem Informationsaustausch (noch) weniger dienlich sind als Josefs Uneinsichtigkeit. Solang, bis die Mods den Threads endlich dicht machen! Tolle Demokratie. Grüße Lars
Lars R. schrieb: > Auf jeden Beitrag von Josef G. 5x > BS-Antworten, die dem Informationsaustausch (noch) weniger dienlich sind > als Josefs Uneinsichtigkeit. Solang, bis die Mods den Threads endlich > dicht machen! Tolle Demokratie. Du hast ja (zum Großteil) Recht, aber was bringt der Thread noch Neues, außer off-topic Gelaber? Mein Wunsch nach Schließung war eher ein pragmatischer Ansatz. Klar, ich könnte auch einfach den Thread (oder gleich das ganze Forum) ignorieren...
Lars R. schrieb: > Auf jeden Beitrag von Josef G. 5x BS-Antworten, Meinst Du solch' eine Antwort eines Englisch-Legasthenikers? Lars R. schrieb: >> GT: GET (erhalte), passt optisch gut zu ST > > Englisch. > ... >> L: LESSEN vermindere zweiten Operanden um A (Ergebnis in A) > > Deutsch Da hätte ich an Stelle des TE auch nicht mehr gewusst, was darauf zu antworten wäre. > Also: Weils die Neurotiker nicht schaffen Du solltest versuchen, die Bedeutung von Dir verwendeter Worte wie "Neurotiker" zu verstehen, dann würdest Du evtl. weniger abwertend über andere Threadteilnehmer schreiben. Andererseits, es könnte auch Selbstreflektion sein. ;D > Tolle Demokratie. Ein Forum ist keine Demokratie.
MWS schrieb: > Lars R. schrieb: >> Auf jeden Beitrag von Josef G. 5x BS-Antworten, > > Meinst Du solch' eine Antwort eines Englisch-Legasthenikers? Für Korrektur bin ich dankbar. Hier ist mir unklar, was gemeint ist. "Englisch" wird im Deutschen mit "sch" geschrieben. > Lars R. schrieb: >>> GT: GET (erhalte), passt optisch gut zu ST >> >> Englisch. >> > ... >>> L: LESSEN vermindere zweiten Operanden um A (Ergebnis in A) >> >> Deutsch > > Da hätte ich an Stelle des TE auch nicht mehr gewusst, was darauf zu > antworten wäre. Mein Hinweis war für Josefs Antwort auf eine bestimmte Frage. Vielleicht hat er es verstanden. Erklärung hatte ich explizit angeboten. Danach hast du dann nicht gefragt und jetzt auch nicht. Interessiert Dich gar nicht. Edit: Jetzt habe ich es verstanden. Mein ursprünglicher Einwand an dieser Stelle war unberechtigt. Habe den Text bestimmt 5x angeschaut und vielleicht auch aufgrund der anderen Beschreibungen immer wieder so interpretiert: L: LESEN; (und ebenso) vermindere zweiten Operanden um A >> Also: Weils die Neurotiker nicht schaffen > > Du solltest versuchen, die Bedeutung von Dir verwendeter Worte wie > "Neurotiker" zu verstehen, dann würdest Du evtl. weniger abwertend über > andere Threadteilnehmer schreiben. Andererseits, es könnte auch > Selbstreflektion sein. ;D In Josefs Threads habe ich nicht alles gelesen. An den von mir gelesenen Stellen ist mir kein logischer Fehler in Josefs Argumentation aufgefallen. Fast immer ist das Ende eines Diskussionsstranges eine nicht konsensfähige Ansicht, gegen die nicht weiter argumentiert wurde, bzw. gegen die man nicht mehr weiter logisch argumentieren konnte. In diesem Thread wollte Josef auf meine Äußerungen nicht erwidern. Das hätte auch anders herum sein können. Oft genug habe ich schon in anderen Threads nicht weitergeschrieben. Um so bemerkenswerter, dass dies einigen anderen, die ebenso auch schon in anderen Threads einfach nicht weiter geschrieben haben, hier nur schwerlich oder mit unpassenden Vorschlägen (User löschen, Thread löschen) gelingt. Ganz im Sinne von "Josef gefährdet die öffentliche Denkordnung" ...mit einem einzigen aktiven Thread! Oder sinngemäß: "Wegen einem aktiven Thread von Josef könne man das ganze Forum nur schwerlich ertragen, könnte ggf. das ganze Forum ignorieren" (mehrfach geäußert). Ich bin bzgl. der Klassifizierung von Verhalten kein Experte. Mir fällt neben der Zwangsneurose spontan nur eine andere Möglichkeit ein: Es handelt sich (teilweise) um "Gutmenschen", die anders Denkenden "helfen", die Dinge richtig zu verstehen. Wenn diese Hilfe beim anders Denkenden jedoch nicht erfolgreich ist, so wird er bekämpft, weil die andere Ansicht nicht tollieriert werden kann. Schließlich hat man sich so sehr Mühe gegeben... Ich habe eine Bezeichnung dafür, aber ich schreib sie hier nicht hin. Glaube auch nicht, dass das (auf alle) hier zutrifft. Dennoch: Die Hemmschwelle sinkt, wenn man als Gruppe auf Einzelne losgeht. Das trifft auch ohne Internet zu. Hier im Forum wird häufig der Anspruch erhoben, als Entwickler und Ingenieure besonders vertraut mit dem rationalen Denken und Handeln zu sein. Vor diesem Hintergrund finde ich die Abläufe schade. Dann braucht man sich über andere Vorgänge im Land nicht wundern und eigentlich auch nicht ständig beschweren, wenn es hier keinen Deut besser abläuft.
:
Bearbeitet durch User
Lars R. schrieb: > In Josefs Threads habe ich nicht alles gelesen. An den von mir gelesenen > Stellen ist mir kein logischer Fehler in Josefs Argumentation > aufgefallen. Aussagen wie "dies ist meine Meinung, und die solltet ihr teilen" sind weder logisch noch unlogisch, egal auf welcher Seite davon man steht. Es ist keine Frage der Logik, Meinungen zu kritisieren. > handelt sich (teilweise) um "Gutmenschen", die anders Denkenden > "helfen", die Dinge richtig zu verstehen. Wenn diese Hilfe beim anders > Denkenden jedoch nicht erfolgreich ist, so wird er bekämpft Ich bin halt lieber Gut- als Bösmensch. Ich versuche, ihm zu helfen, bevor ich ihm eine reinhaue. Andere sparen sich die Mühe des ersten Schritts. Apropos: Wie nennt man eigentlich die dritte Kategorie, also die Schweizer bei Asterix, die erst eine überziehen und danach verarzten? ;-) Einrechnen sollte man freilich, dass er sich vorsätzlich dieser Diskussion stellte. Er wollte die Reaktionen darauf wissen. Nur waren es nicht jene, die er sich erhoffte. > Hier im Forum wird häufig der Anspruch erhoben, als Entwickler und > Ingenieure besonders vertraut mit dem rationalen Denken und Handeln zu > sein. Können und tun sind zwei paar Stiefel. Die Vorstellung, dass man über seinen Emotionen steht, ist üblicherweise eine Illusion.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Die Operation ist immer die gleiche: > > move Habe den Beitrag von Rufus nochmal in Ruhe gelesen. Ich muss zugeben, dass das Konzept der Trennung von Schlüsselwort und Operanden eine klare Struktur hat. Es ist aber doch wohl so, dass dieses Konzept eingeführt wurde für Prozessoren mit einer großen Zahl von Operanden. Meine CPU hat aber keine große Zahl von Operanden. Es ist problemlos möglich, die paar Operanden ins Schlüsselwort zu integrieren. Warum also soll ich das nicht tun? ======== Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" Weil darauf inhaltlich keine Antwort kam noch ein Versuch Zu den Repeat-Befehlen mit Adresse-Inkrementieren/Dekrementieren Beispiel Blockverschiebung:
1 | S.RP setze Schleifenstartadresse auf den GTMX-Befehl |
2 | GTMX lade Memory(X) nach A |
3 | STMY speichere A in Memory(Y) |
4 | IX0 inkrementiere X |
5 | R.IY dekrementiere Schleifenzähler, inkrementiere Y |
6 | und springe zu GTMX, falls Zähler nicht Null. |
R.IY dauert nicht länger als einfaches Inkrementieren IY0. Bei Realisierung der Schleife mit separatem Rückwärtssprung bestünde ein Anreiz, zur Beschleunigung den Schleifeninhalt
1 | GTMX |
2 | STMY |
3 | IX0 |
4 | IY0 |
zweimal hinzuschreiben. Das entfällt durch den R.IY -Befehl. Das ist jetzt aber doch eine positive Eigenschaft meiner CPU, oder etwa nicht? ======== Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" In dem Beitrag wurde der auf PC laufende Cross-Assembler erwähnt. Vielleicht hat ihn jemand ausprobiert und war enttäuscht. Ich habe ihn überarbeitet, vielleicht mag ihn nochmal jemand testen ...
Josef G. schrieb: > Meine CPU hat aber keine große Zahl von Operanden. Es ist > problemlos möglich, die paar Operanden ins Schlüsselwort > zu integrieren. Warum also soll ich das nicht tun? Natürlich gibt es kein Gesetz, das das verbietet. Allerdings würde ich, wenn ich einen neuen Befehlssatz (quasi eine neue "Sprache") entwerfen würde, als Autor auf eine Zukunftssicherheit Wert legen. Heißt konkret: Wenn Du nun irgendwann eine bo16-/bo32-CPU entwerfen möchtest, die naturgemäß eine komplexere Registerstruktur umfasst (oder auch "nur" eine Version 2 der bo8, die diverse Verbesserungen/Erweiterungen mit sich bringt), ist es extrem vorteilhaft, wenn die Befehlssätze konsistent sind - die Nutzer müssen nicht noch eine weitere Sprache für eine architekturell ähnliche CPU lernen, und die Tools sind u. U. wiederverwendbar bzw. können kompatibel gestaltet werden und müssen nicht von Grund auf neu entwickelt werden.
Horst G. schrieb: > die naturgemäß eine komplexere Registerstruktur umfasst Wieso eigentlich? Was bei 8 Bits richtig ist kann bei 32 Bits nicht falsch sein, oder? Eine 32-Bit Akkumulator-Architektur wäre derzeit wohl ein Alleinstellungsmerkmal. Die letzte dieser Art könnte die Z380 gewesen sein, eine 32-Bit Z80, die hat aber nie gross abgehoben.
:
Bearbeitet durch User
A. K. schrieb: > 32-Bit Akkumulator-Architektur Die leider nie offiziell dokumentierten Erweiterungen der CMOS-Version des 6809 von Hitachi (HD6309) waren auch eine, wenngleich dank des 8-Bit-Daten- und 16-Bit-Adressbus leider von vornherein zum Scheitern verurteilte. https://en.wikipedia.org/wiki/Hitachi_6309#/media/File:6309programmingmodel.png Zu den Akkus A und B gesellten sich zwei weitere namens E und F, die zu einem 16-Bit-Akku W zusammengefasst werdem konnten. Der aus A und B gebildete 16-Bit-Akku D wiederum konnte mit diesem zu einem 32-Bit-Akku Q zusammengefasst werden. Dieser bestand dann aus den vier 8-Bit-Akkus A, B, E und F.
IMHO sind die Architekturen mit Akkumulator und nur wenigen zusätzlichen Registern ab dem Zeitpunkt immer mehr aus der Mode gekommen, als die CPU-Geschwindigkeit begann, schneller als die Speichergeschwindigkeit zu wachsen. Ein großer Satz an Datenregistern erlaubt es halt, längere Codeabschnitte ohne (Daten-)Speicherzugriffe auszuführen. Es könnte allenfalls sein, dass mit immer effektiver arbeitenden Datencaches Akkumulatorarchitekturen wieder interessanter werden. Die Frage ist aber, was der Vorteil einer solchen Architektur wäre. Kleinere Chipfläche? Die dürfte eine eher untergeordnete Rolle spielen, da bei schnellen CPUs heute der größte Teil der Chipfläche ohnehin mit Cache belegt ist.
Ich hab zwar nicht viel Ahnung von 16- und 32-Bit-CPUs, aber ich habe den Verdacht, dass der Grund für die große Zahl von Registern darin besteht, die durch die größere Wortbreite bedingte große Zahl möglicher OpCodes irgendwie sinnvoll nutzen zu wollen.
Josef G. schrieb: > aber ich habe den Verdacht Aha. Wenn Du das ernst meinst, erklärt das natürlich vieles.
Rufus Τ. F. schrieb: > Josef G. schrieb: >> aber ich habe den Verdacht > > Aha. Wenn Du das ernst meinst, erklärt das natürlich vieles. Versteh ich nicht. War mein Beitrag Unsinn?
Josef G. schrieb: > Versteh ich nicht. War mein Beitrag Unsinn? Ich vermute ja. Ich kann mir nicht vorstellen, dass ein CPU-Entwickler erst eine Liste mit Op-Codes entwickelt und dann den passenden Prozessor darum baut...
Josef G. schrieb: > Versteh ich nicht. Wenn Du den Nutzen von mehr Prozessorregistern nicht erkennen kannst ... scheinst Du eine sehr, sagen wir mal im positiven Sinne "ressourcensparende" Art der Programmierung zu verfolgen, die aber auch die Komplexität des damit erzielbaren in sehr überschaubaren Bahnen hält.
Außerdem orientiert sich die Länge der Befehle nicht immer an der Wortbreite der CPU. Das ist bei 8- und 16-Bit-Prozessoren zwar oft der Fall, bei 32- und 64-Bit-Prozessoren gibt es aber viele Gegenbeispiele. Der Intel Core i7, vor dem ich gerade sitze, kennt bspw. Befehle mit den Längen 1, 2, 3, 4, 5, 6 und 7 Byte. Kein Befehl nutzt die vollen 64 Bit und nur ein relativ kleiner Anteil davon genau ein halbes CPU-Wort, also 32 Bit. Wenn die CPU-Entwickler viele Register in ihre CPUs packen, könnte das also noch andere Gründe haben. Einen habe ich oben schon genannt.
Yalu X. schrieb: > IMHO sind die Architekturen mit Akkumulator und nur wenigen zusätzlichen > Registern ab dem Zeitpunkt immer mehr aus der Mode gekommen, als die > CPU-Geschwindigkeit begann, schneller als die Speichergeschwindigkeit zu > wachsen. Einerseits dies. Andererseits kann auf Register recht einfach über mehrere Ports gleichzeitig zugegriffen werden. Bei Speicher ist der Aufwand dafür erheblich höher. Dazu kommen Pipeline-Effekte. Egal wie man eine Pipeline baut, man kriegt immer irgendwelche Stalls, wenn der Folgebefehl unweigerlich die gleichen Ressourcen verwenden muss (Akku/Index). Erst durch Verzahnung unabhängiger Operationen lassen sich die vermeiden. Siehe Delay-Slot beim LOAD der ersten RISC CPUs. > Die Frage ist aber, was der Vorteil einer solchen Architektur wäre. Keiner. Der von mir verwendete Begriff "Alleinstellungsmerkmal" lässt sich nicht nur positiv verstehen. ;-)
Josef G. schrieb: > Ich hab zwar nicht viel Ahnung von 16- und 32-Bit-CPUs, > aber ich habe den Verdacht, dass der Grund für die große > Zahl von Registern darin besteht, die durch die größere > Wortbreite bedingte große Zahl möglicher OpCodes > irgendwie sinnvoll nutzen zu wollen. Nein. Wenn man Operationen der Art a := b + c so ausführen will, dass man pro Takt ein Ergebnis erhält, dann setzt das Register voraus, oder einen arg hohen Aufwand im Speicherzugriff. Wenn man dann auch noch mehrere davon pro Takt ausführen will, dann wird das noch viel krasser (Cortex M7). Es gibt keinen Zusammenhang zwischen Wortbreite der Maschine und Breite der Opcodes, ausser dass es irgendwie zusammenpassen muss (oder auch nicht - iAPX432, mit krass ineffizienter Bitstream-Codierung). Der Opcode-Stream der VAX war byteweise aufgebaut. Einfache Befehle ohne Registerangabe waren 1 Byte lang. Die 60-Bit CDC6600 (Mitte 1960er) hatte 3 Sätze zu je 8 Registern. Die Opcodes waren 15 und 30 Bits breit.
:
Bearbeitet durch User
Yalu X. schrieb: > Der Intel Core i7, vor dem ich gerade sitze, kennt bspw. Befehle mit den > Längen 1, 2, 3, 4, 5, 6 und 7 Byte. Es sind 1-15 Bytes. Theoretisch ginge auch mehr, aber so ist es definiert, damit der Fetch/Decode Mechanismus nicht noch komplizierter wird, als er sowieso schon ist. Der Aufwand, bei 4 pro Takt gleichzeitig dekodierten Befehlen rauszukriegen, wo welcher davon anfängt und wo der letzte aufhört, ist nicht eben klein. Weshalb es eine Obergrenze für die kumulierte Länge aller in einem Takt decodierbarer Befehle gibt.
:
Bearbeitet durch User
A. K. schrieb: > Dazu kommen Pipeline-Effekte. Egal wie man eine Pipeline baut, man > kriegt immer irgendwelche Stalls, wenn der Folgebefehl unweigerlich die > gleichen Ressourcen verwenden muss (Akku/Index). Erst durch Verzahnung > unabhängiger Operationen lassen sich die vermeiden. Siehe Delay-Slot > beim LOAD der ersten RISC CPUs. Bevor irgendwer solche Kleinigkeiten für neumodische Probleme hält: Die erwähnte CDC6600 hatte etliche parallel arbeitende Ausführungseinheiten (und Multithreading ;-), im Nachfolger CDC7600 waren diese Einheiten gepipelined, und eine IBM 360 verwendete bereits Out-of-Order Execution mit Renaming um den Konsequenzen zu entkommen. Alles 60er Jahre.
:
Bearbeitet durch User
A. K. schrieb: > Es sind 1-15 Bytes. Stimmt, die 7 sind noch lange nicht das Maximum. Das zeigt aber noch deutlicher, dass die Befehlsworte in keinem Zusammenhang mit den Datenworten oder der Busbreite stehen, eine Sache die man von 8-Bit-CPUs so nicht kennt. Oder gibt es vielleicht irgendeine exotische 8-Bit-CPU, bei der bspw. zwei 12-Bit-Befehlsworte in drei Bytes untergerbracht sind? Mich würde das nicht einmal allzu sehr wundern ;-)
A. K. schrieb: > Bevor irgendwer solche Kleinigkeiten für neumodische Probleme hält: Die > erwähnte CDC6600 hatte etliche parallel arbeitende Ausführungseinheiten > (und Multithreading ;-), im Nachfolger CDC7600 waren diese Einheiten > gepipelined, und eine IBM 360 verwendete bereits Out-of-Order Execution > mit Renaming um den Konsequenzen zu entkommen. Alles 60er Jahre. Das klingt aber für Leute, die zum Jahrtausendwechsel noch im Kindergarten waren, wie "Opa erzählt vom Krieg". Das auf einer solchen 360er Virtuelle Maschinen liefen, die teils Hunderte User "betreuten", ist ja eigentlich gar nicht möglich, denn das wurde alles doch "erst gestern" erfunden.
Carl D. schrieb: > Das auf einer solchen 360er Virtuelle Maschinen liefen, die teils > Hunderte User "betreuten", ist ja eigentlich gar nicht möglich, denn > das wurde alles doch "erst gestern" erfunden. Ja, auch die Abkürzung "VM" gab es damals schon als Name für ein Betriebssystem von IBM. Diese VMs konnten damals mehr als heute. Oder finde mal eine "moderne" VM, die sogar den Lochkartenstanzer und -leser virtualisiert ;-)
Yalu X. schrieb: > Oder gibt es vielleicht irgendeine exotische 8-Bit-CPU, > bei der bspw. zwei 12-Bit-Befehlsworte in drei Bytes untergerbracht > sind? Mich würde das nicht einmal allzu sehr wundern ;-) Gibt es. Die PIC10/12. ;-)
Horst G. schrieb: > Wenn Du nun irgendwann eine bo16-/bo32-CPU entwerfen > möchtest Oh Herr, bitte verschone uns! A. K. schrieb: > Gibt es. Die PIC10/12. ;-) In drei Bytes aber doch nicht ... Dort ist der Speicher 12 Bit breit. Gruß Jobst
Jobst M. schrieb: > In drei Bytes aber doch nicht ... Wenn man ein Byte weiterhin als 8 Bit definiert, hat er schon recht. Aber da das natürlich nicht ganz das ist, was ich meinte, und er wusste, was ich meinte, hat er genau dies, ohne viel Worte zu verschwenden, mit einem Smiley kundgetan :)
Yalu X. schrieb:1 | > CP.V V wird V xor U |
> > Hier wird aus dem V-Flag (was normalerweise C heißt) mit Hilfe > des U-Flags (was normalerweise N heißt) ein Overflow-Flag gemacht > (was normalerweise V heißt. Damit trägt das V-Flag nach Ausführung > dieses Befehls erstmals sein Kürzel zurecht. Ich meine, das ist nicht richtig, wenn hier das Rechnen mit Zweierkomplement-Zahlen gemeint ist. Das Overflow-Flag würde sich errechnen als V xor (Eingangs-Carry zu Bit7). Es ist aber richtig, wenn man mit Offset-Zahlen rechnet, wobei eine Offset-Zahl aus einer Zweierkomplement-Zahl entsteht durch Negation des Vorzeichenbits.
Strubi schrieb: > Spät des Abends, crasht die Kiste > Der Fehler liegt an der Netzliste, > Schuld hat a-synchrone Logik, > wie auch Schleifen-Komb'natorik, Wer das liest, wird denken, solche Fehler seien bei meiner CPU schon mal aufgetreten. Sind sie aber nicht.
Michael U. schrieb: > Wenn ich das jetzt also ernst mehmen wollte, müßte ich > mir ein offenbar zeimlich teures FPGA-Board beschaffen, Altera DE0-Board (ohne nano), dazu eine D-Sub-Buchse für RS232, unter 100 Euro. QuartusII 13.0-Sp1 kostenlos. > zusehen, wie ich die CPU da drauf bekomme und dann könnte > ich mehr oder weniger erfolgreich mein "Hello World" > oder die blinkende LED zustande bekommen? Immerhin: Conway's Game of Life.
Josef G. schrieb: >> zusehen, wie ich die CPU da drauf bekomme und dann könnte >> ich mehr oder weniger erfolgreich mein "Hello World" >> oder die blinkende LED zustande bekommen? > > Immerhin: Conway's Game of Life. Sag aber bitte fairerweise dazu dass es dein Game of Life nicht in Source-Form gibt sondern nur als Hexcode als Teil der Firmware irgendeiner Steckkarte. Beitrag "Re: 8bit-Computing mit FPGA" Beitrag "Re: 8bit-Computing mit FPGA" Für Einsteiger (deine erklärte Zielgruppe) also wieder nix.
Le X. schrieb: > dass es dein Game of Life nicht in > Source-Form gibt sondern nur als Hexcode auch als Disassembler-Listing. Beitrag "Re: 8bit-Computing mit FPGA"
Josef G. schrieb: > auch als Disassembler-Listing. > Beitrag "Re: 8bit-Computing mit FPGA" Ich nehme meine Kritik zurück, du hast natürlich recht. Das Listing habe ich glatt übersehen. Damit ist nun auch Anfängern endlich geholfen! https://www.mikrocontroller.net/attachment/301903/GOLcod.txt
Le X. schrieb: > Damit ist nun auch Anfängern endlich geholfen! > https://www.mikrocontroller.net/attachment/301903/GOLcod.txt Eindeutig. Das liest sich fast so gut wie ein ... vom chinesischen ins Georgische übersetzter Busfahrplan.
Wolfgang R. schrieb: > Ab 3fe8 hab ich den Faden verloren... Ist halt nicht nur der eigentliche Iterations-Vorgang, sondern auch das vorbereitende Löschen des Bildschirms und Setzen einer Randmarkierung, die Kommunikation mit dem Benutzer zur Auswahl der Spielfeldgröße, das Importieren des Startbildes, der Iterationsvorgang in zweifacher Ausführung für zwei verschiedene Auflösungen, das Anhalten und Weiterlaufenlassen, das Scrollen des Bildes mit den Cursortasten, ..., da kommt schon einiges zusammen.
Dann wären aber Kommentare und aussagekräftige Sprungmarken angebracht. Dann wäre auch sofort ersichtlich welche Befehle deiner CPU im Verbund welche Funktionalität bewirken. Ich weiß, das ist ein Disassembly. Jo mei, wenn man alles von hinten durch die Brust ins Auge machen muss...
:
Bearbeitet durch User
Josef G. schrieb: > Wolfgang R. schrieb: >> Ab 3fe8 hab ich den Faden verloren... > > Ist halt nicht nur der eigentliche Iterations-Vorgang, > sondern auch das vorbereitende Löschen des Bildschirms und > Setzen einer Randmarkierung, die Kommunikation mit dem Benutzer > zur Auswahl der Spielfeldgröße, das Importieren des Startbildes, > der Iterationsvorgang in zweifacher Ausführung für zwei verschiedene > Auflösungen, das Anhalten und Weiterlaufenlassen, das Scrollen des > Bildes mit den Cursortasten, ..., da kommt schon einiges zusammen. Du hast gemerkt, dass das ein Scherz von mir war? Mal im Fast-Ernst: diese Form des disassemblierten Listings ist für Leute ohne Asperger-Syndrom incl. Inselbegabung nicht verarbeitbar, sorry.
Josef G. schrieb: > Yalu X. schrieb: > CP.V V wird V xor U >> >> Hier wird aus dem V-Flag (was normalerweise C heißt) mit Hilfe >> des U-Flags (was normalerweise N heißt) ein Overflow-Flag gemacht >> (was normalerweise V heißt. Damit trägt das V-Flag nach Ausführung >> dieses Befehls erstmals sein Kürzel zurecht. > > Ich meine, das ist nicht richtig, wenn hier das Rechnen mit > Zweierkomplement-Zahlen gemeint ist. Das Overflow-Flag würde > sich errechnen als V xor (Eingangs-Carry zu Bit7). Du hast völlig recht. Ich habe da ein paar Dinge durcheinandergebracht.
Josef G. schrieb: > Es ist aber richtig, wenn man mit Offset-Zahlen rechnet, > wobei eine Offset-Zahl aus einer Zweierkomplement-Zahl > entsteht durch Negation des Vorzeichenbits. Zum fehlenden Overflow-Flag und zum Rechnen mit Offset-Zahlen Bei 1-Byte-Offsetzahlen gilt [P] = P-80. Dabei sei P der positive Wert, wie er im Speicher steht, und [P] sei die Zahl, welche gemeint ist. V ist das Carry-Flag, U ist Bit7 des Akku. Addition : [A]+[B] = (A-80)+(B-80) = (A+B-80)-80 Damit kein Overflow vorliegt, muss A+B-80 im Bereich 00 .. ff liegen, und es gilt dann [A]+[B]=[A+B-80]. A+B muss also im Bereich 80 .. 17f liegen. Das ist genau dann der Fall, wenn nach Addition A+B gilt (V xor U = 1). Nach der Addition A+B erhält man das Endergebnis A+B-80 durch Negation von U. Subtraktion : [A]-[B] = (A-80)-(B-80) = (A-B+80)-80 Damit kein Overflow vorliegt, muss A-B+80 im Bereich 00 .. ff liegen, und es gilt dann [A]-[B]=[A-B+80]. A-B muss also im Bereich -80 .. +7f liegen. Das ist genau dann der Fall, wenn nach Subtraktion A-B gilt (V xor U = 0). Letzteres sieht man aus folgendem: X sei der positiv interpretierte Wert, welcher nach der Subtraktion A-B im Akku steht. Falls V=0 ist, dann gilt A-B = X X muss also im Bereich 00 .. 7f liegen, dh. U muss 0 sein. Falls V=1 ist, dann gilt A-B = X-100 X muss also im Bereich 80 .. ff liegen, dh. U muss 1 sein. Nach der Subtraktion A-B erhält man das Endergebnis A-B+80 durch Negation von U. ----------- Wenn man also mit Offset-Zahlen statt mit Zweierkomplement- Zahlen rechnet, dann braucht man kein Overflow-Flag. So hatte ich mir das überlegt, und deshalb das Overflow-Flag weggelassen. Oder steckt in meiner Rechnung irgendwo ein Fehler?
Geht das nicht auch einfach mit Bit7 xor Bit8 ?
Lars R. schrieb: > Geht das nicht auch einfach mit Bit7 xor Bit8 ? Was ist das ? Falls damit gemeint ist zu testen ob Overflow vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich U und V genannt habe, dann ist es ja genau das, was ich geschrieben habe.
Josef G. schrieb: > Lars R. schrieb: >> Geht das nicht auch einfach mit Bit7 xor Bit8 ? > > Was ist das ? Falls damit gemeint ist zu testen ob Overflow > vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich > U und V genannt habe, dann ist es ja genau das, was ich > geschrieben habe. Mit dem Unterschied, daß Lars Variant mit inhärenter Verständlichkeit gesegnet ist.
Josef G. schrieb: > Lars R. schrieb: >> Geht das nicht auch einfach mit Bit7 xor Bit8 ? > > Was ist das ? Falls damit gemeint ist zu testen ob Overflow > vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich > U und V genannt habe, dann ist es ja genau das, was ich > geschrieben habe. Overflow ist gemeint, aber: Josef G. schrieb: > Wenn man also mit Offset-Zahlen statt mit Zweierkomplement- > Zahlen rechnet, dann braucht man kein Overflow-Flag. So hatte > ich mir das überlegt, und deshalb das Overflow-Flag weggelassen. Mit meiner Frage meinte ich: Ohne Erzeugen von "Offset", Rechnen in "Offset" und anschließender Negation. Einfach nur Bit7 xor Bit8.
Carl D. schrieb: > Josef G. schrieb: >> Lars R. schrieb: >>> Geht das nicht auch einfach mit Bit7 xor Bit8 ? >> >> Was ist das ? Falls damit gemeint ist zu testen ob Overflow >> vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich >> U und V genannt habe, dann ist es ja genau das, was ich >> geschrieben habe. > > Mit dem Unterschied, daß Lars Variant mit inhärenter Verständlichkeit > gesegnet ist. Meiner Ansicht nach ist bereits der Sprachgebrauch ungewöhnlich und grenzwertig. Beides zusammen führt dazu, dass ich beim Lesen der Aussagen einen anderen, falschen Sinn verstehe. Dann verstehe ich nach einiger Zeit den wahren Sinn und bin der Ansicht, dass die Aussage falsch ist. Anschließend schaue ich die Aussage an und überlege, mit welcher Interpretation sie doch korrekt sein könnte. Hinzu kommt, dass für eine prägnante, verständliche Beschreibung immer das am Genauesten passende Wort oder Zeichen gewählt wird. Das ist meiner Ansicht nach sehr häufig nicht der Fall, weshalb die Beschreibungen nicht prägnant und auch nicht verständlich sind. Weiterhin kommt hinzu, dass für seit Jahrzehnten etablierte Begriffe neue Bezeichner eingeführt werden. Dafür sollte man immer sehr gute Gründe haben und mir persönlich reicht die gebotene Begründung "das spart 2 Zeichen tippen" nicht, um die daraus folgende schlechtere Verständlichkeit zu rechtfertigen. Dies alles zusammen bringt mich immer wieder durcheinander (siehe oben) und es macht es beliebig schwer, überhaupt zu dem Punkt zu gelangen, an dem man Schwächen im Konzept erkennen und diskutieren kann. Beispiel: > Nach der Subtraktion A-B erhält man das > Endergebnis A-B+80 durch Negation von U. Erstes Lesen: -U = A-B+80 Zweites Lesen nochmal von oben: Not(U) = A-B+80, denn U ist ein Bit. Besser wäre "Invertieren von U". "Negation" ist nich falsch. Drittes Lesen: "V ist das Carry-Flag, U ist Bit7 des Akku." Ergebnis = A-B+80, U ist ein Bit, U ist ein Bit von Ergebnis U ist das 7. Bit U ist MSB. Die Aussage lautet demnach: "Nach der Subtraktion A-B erhält man das Endergebnis A-B+80 durch Invertieren des MSB." "MSB" ist bekannt und eindeutig. "Negation von MSB" wäre dann auch sofort verständlich. Alternativ lässt sich der Sachverhalt in Prosa in dieser Kürze eben nicht korrekt ausdrücken. Dh, mehr Worte für die Beschreibung oder eine verständliche Gleichung. Gut, weiter: Viertes Lesen: 80 ist HEX, positiv, 8 Bit; also 80h Fünftes Lesen: "Endergebnis A-B+80"? Als Endergebnis der Subtraktion A-B möchte ich doch A-B haben, oder? Achso... A und B sind Offsetzahlen und [A] und [B] sind die tatsächlichen, gemeinten Zahlen. Gut, die Zeichensetzung hier ist begrenzt. Trotzdem ist die Verwendung hier wieder dem Sprachgebrauch entgegen. Eine 20-Cent-Münze definiere ich zunächst nicht über ihre Legierung, sondern über die aufgeprägte Zahl. Also, dies alles im Kopf behalten. Nun nur nicht versehentlich wohlwollend gedanklich etwas verdrehen, was mal nicht "verdreht" gemeint war, und: Post nochmal lesen, um zu schauen, was es mit den Offset auf sich hat. An der Stelle habe ich (eigentlich schon viel zu spät) abgebrochen, kurz überlegt, wie man Overflow erkennt und als Frage hingeschrieben...
:
Bearbeitet durch User
Das Problem hast aber nur du weil du durch jahrzehntelange Erfahrungen vorbelastet bist. Du bist aber nicht die Zielgruppe. Für einen Einsteiger ist das alles sehr leicht verständlich ;-)
Josef, was sagt diese Skizze aus?
1 | P Q R S X Y Z K V Bezeichnung: A7 = U |
2 | | | | | | | | |A AB = K |
3 | | | | | | | | |B |
In der Beschreibung zur CPU ist die Bedeutung für jeden Buchstaben angegeben. Aber die Skizze wird kommentarlos geboten. Mir fallen in der Skizze folgende Dinge auf: . Eine Leerspalte zwischen P und Q. . Eine Leerspalte zwischen S und X. . Zwei Leerspalten zwischen Z und K sowie 4 oder 5 zwischen K und V. . Horizontalstriche nicht unter V. . V ist in der Skizze, U nicht, aber K trotzdem. . A7 = U (Und ich dachte schon, U = A7, dh. U = MSB von A) . Unter dem K stehen A und B; A und B stehen nicht oben. Zu jedem aufgezählten Punkt: Warum?
:
Bearbeitet durch User
Josef G. schrieb: > Meine CPU hat aber keine große Zahl von Operanden. Es ist > problemlos möglich, die paar Operanden ins Schlüsselwort > zu integrieren. Warum also soll ich das nicht tun? Weil nicht alles, was möglich ist, auch sinnvoll ist. Deine Zielgruppe sind Anfänger, für die ist eine klare Struktur sinnvoll und notwendig. Anders ausgedrückt: Verständlichkeit trumpft Effizienz.
Thema des Threads ist zwar die CPU, aber das Emulationsprogramm wurde bereits erwähnt, und ich möchte darauf zurückkommen. Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" Ich habe auf der Seite Emul die Anleitung zum Emulationsprogramm und zu den Beispieltexten überarbeitet. Vielleicht mag nochmal jemand sich die Sache anschauen ...
Hallo, Josef G. schrieb: > Ich habe auf der Seite Emul die Anleitung zum Emulationsprogramm > und zu den Beispieltexten überarbeitet. Vielleicht mag nochmal > jemand sich die Sache anschauen ... und warum dann ein Link in einen anderen Foren-Thread und nicht zu genau zur Emul Webseite??? Gruß aus Berlin Michael
Michael U. schrieb: > und warum dann ein Link in einen anderen Foren-Thread > und nicht zu genau zur Emul Webseite??? Kein anderer Thread, sondern eine anderer Beitrag in diesem Thread. Aber bitte, hier der gewünschte Link: http://www.bomerenzprojekt.de/Website/Emul.html
Geschafft!!! Ich kann jetzt tatsächlich mit deinem Demo-Programm zwei Zahlen addieren, subtrahieren, multiplizieren und dividieren :) Diese Information, die du in deiner Dokumentation ergänzt hast, hat noch gefehlt:
1 | Bei OPA ist stets das Vorzeichen anzugeben, OPB ist ohne Vorzeichen. |
In meiner Naivität hatte ich in früheren Versuchen für den ersten Operanden (OPA) einfach eine Zahl eingegeben, bin aber nicht auf die Idee gekommen, dass man da noch ein Vorzeichen (auch für positive Zahlen) angeben muss. Gewundert haben mich dann nur noch die (scheinbar) falschen Ergebnisse bei der Multiplikation und Division. Den Grund dafür habe ich aber schon erraten, bevor ich den nächsten Satz deiner Dokumentation las, denn
1 | Bei MUL und DIV ist Multiplikator bzw. Divisor = OPB+1. |
Bekomme ich jetzt einen Preis? Ich bin ja vermutlich der Erste, der dein Hackerspiel geschafft hat. Zwar nur den ersten Level und den auch nur mit ein paar Hints von dir, aber immerhin. Der Schwierigkeitsgrad war wirklich nicht ganz ohne, und ich habe garantiert nirgends gecheatet ;-)
Yalu X. schrieb: > Der Schwierigkeitsgrad war wirklich nicht ganz ohne, und > ich habe garantiert nirgends gecheatet ;-) Naja, für Anfänger halt ;-)) Gruß Jobst
Falls jemand Schwierigkeiten hat, beim Testen zwischen dem Konsolenfenster, in welchem das Emulationsprogramm läuft, und der Anleitung auf der Website hin- und herzuschalten: Vielleicht hilft es, die Anleitung mit der Maus zu kopieren und in einer Textdatei zu sichern, und die Textdatei neben dem Konsolenfenster anzuzeigen.
:
Bearbeitet durch User
Yalu X. schrieb: > Josef G. schrieb: >> ... >> Ausser IXs gibt es auch IXL nn : Inkrementiere X, lange Distanz. >> Würde man hier nicht um nn+1 inkrementieren, müsste man gesondert >> festlegen: 00 entspricht 100. > > Nein. Der Wertebereich geht von 1 bis 256 (hex 01 bis 100). Dann möchte > ich den Wert auch genauso hinschreiben. Darum, wie diese Werte dann im > erzeugten Binärcode dargestellt werden, sollte sich der Programmierer > nicht kümmern müssen. ... Inkrementieren und Dekrementieren mit langer Distanz
1 | IXL nn inkrementiert X um nn+1 |
2 | DXL nn dekrementiert X um nn+1 |
Diese Befehle sind vor allem dazu da, dass man innerhalb eines 256-Byte-Bereichs jedes Byte direkt erreichen kann. Beim Z80 gab es dafür die Adressierungsart IX+d und IY+d. Ich habe nun den Assembler überarbeitet. Man kann jetzt Startposition und Zielposition innerhalb eines 256-Byte- Bereichs angeben, die Differenz berechnet der Assembler.
1 | IXL 3c.8c ergibt IXL 4f |
2 | DXL 8c.3c ergibt DXL 4f |
3 | |
4 | IXL 8c.3c ergibt IXL af (Start=008c Ziel=013c) |
5 | DXL 3c.8c ergibt DXL af (Start=013c Ziel=008c) |
Gleicher Wert für Start und Ziel ergibt IXL/DXL ff. =============================================================== Die Seite bomerenzprojekt.de existiert nicht mehr. Neue Website ist http://www.bo8h.de Es wurde mir vorgeworfen, dass man alle Dateien einzeln herunterladen und entpacken muss. Auf der neuen Website kann man jetzt das gesamte Projekt in einer einzigen zip-Datei herunterladen. Informationen zum Assembler sind zu finden in der Datei SYS-doku ziemlich am Ende (Kommandos =MASS,=EASS,=CASS), und zur PC-Version in der Datei Emul.
Josef G. schrieb: > Informationen zum Assembler sind zu finden Glaubst du echt, das jemand wirklich sucht?
Ich zitiere mal von der Startseite: > Die CPU hat einen vollständigen Befehlssatz mit 256 OpCodes. > Sie kann eine unbestimmte Anzahl 64KByte-Seiten adressieren > und ist auf Einfachheit optimiert. Eine "unbestimmte Anzahl 64 KB-Seiten" heißt, dass du unendlich viele Adressbits hast. Das glaube ich dir nicht. > Sie hat keine Interrupts. Die Berechnung der Dauer > von Befehlsfolgen durch Zählen von Zyklen ist einfach. Das gilt nur für deterministische, datenunabhängige Befehlsfolgen. Schon für einen verkürzten Bubblesort kannst du keine exakte Laufzeit angeben, für das Traversieren einer Liste oder das Balancieren eines Baumes ebenfalls nicht. Was du schreibst, ist nicht "einfach", sondern in der angegebenen Allgemeinheit schlicht gelogen.
Aufgrund des exorbitanten Sinnlosigkeitsfaktors wäre das sicher eine gute CPU für Kurt Bindl...
Wolfgang R. schrieb: > Aufgrund des exorbitanten Sinnlosigkeitsfaktors wäre das sicher eine > gute CPU für Kurt Bindl... Die Parallelen zwischen den beiden wurden ja schon öfter erkannt. Wobei diese garnicht so eindeutig sind. Josef G. hat nämlich eigentlich schon Ahnung von dem was er tut und ist technisch richtig fit. Leider fehlen ihm andere Fähigkeiten, z.B. die Fähigkeit zur Erkenntnis, dass er sich in einer Sackgasse verrandt hat oder der Pragmatismus, mal einen Schritt zurück zu treten und die Situation neu zu beurteilen und gegebenenfalls bestehnde Lösungen wegzuwerfen und neu anzufangen. Kurt B. dagegen ist einfach nur dumm, menschlich und fachlich.
S. R. schrieb: > Eine "unbestimmte Anzahl 64 KB-Seiten" heißt, dass du unendlich viele > Adressbits hast. Das glaube ich dir nicht. Es handelt sich um einen beliebten Irrtum, "unbestimmt" oder "unbegrenzt" mit "unendlich" gleichzusetzen. Vielmehr bezeichnen diese Begriffe eine beliebig große endliche Zahl. Das ist mathematisch gesehen ein gewaltiger Unterschied, da daraus auch folgt, dass z.B. Algorithmen, die auf Objekten mit solch einer Eigenschaft arbeiten, grundsätzlich auch terminieren können. Wenn Du also versuchst, hier Haarspalterei zu betreiben, solltest Du wenigstens selbst einigermaßen korrekte Begrifflichkeiten verwenden und Schlussfolgerungen betreiben. Nichtsdestotrotz ist Josefs CPU außer für ihn selbst als Hobby nicht allzu sinnvoll bzw. brauchbar.
Le X. schrieb: > Die Parallelen zwischen den beiden wurden ja schon öfter erkannt. > Wobei diese garnicht so eindeutig sind. Da stimme ich durchaus zu. Allerdings hat Wolfgang R. schon völlig korrekt geschrieben: "eine gute CPU für Kurt Bindl", und nicht etwa: "eine CPU wie von Kurt Bindl". Josef ist zwar etwas verbohrt, aber ungefährlich. Bei Kurt hingegen kann ich mir schon gut vorstellen, dass er irgendwann die BRD GmbH infragestellen uns als Reichsbürger durch die Welt rennen wird, weil er so seine eigenen Naturgesetze erlassen kann. Es ist übrigens ziemlich erschreckend, wie viele (eher einfach gestrikte...) Juristen der Meinung sind, die Naturgesetze seien durch ein Gesetzgebungsverfahren oder per Dekret geschaffen worden und könnten daher auch beliebig geändert werden. Man schaue sich als Auswuchs dieser Ansicht das "Indiana Pi Bill" von 1897 an, ein Gesetz zur Festlegung des Wertes von Pi, welches das Repräsentatenhaus ohne Gegenstimme passierte und dessen Verabschiedung vom Senat nur verschoben, aber nicht eingestellt wurde.
Andreas S. schrieb: > Es handelt sich um einen beliebten Irrtum, "unbestimmt" oder > "unbegrenzt" mit "unendlich" gleichzusetzen. Vielmehr bezeichnen diese > Begriffe eine beliebig große endliche Zahl. Das ist mathematisch gesehen > ein gewaltiger Unterschied, Ja. Aber es ist in der Praxis, also beim Schreiben eines Assembler-Programms, kein Unterschied. Es macht keinen Sinn, die Anzahl adressierbarer Seiten als "unbestimmt" anzugeben. Nicht bei einer realen CPU.
Andreas S. schrieb: > Es handelt sich um einen beliebten Irrtum, "unbestimmt" oder > "unbegrenzt" mit "unendlich" gleichzusetzen. In der realen Welt ist der Unterschied zwischen "endlich, aber zu groß" und "unendlich" ziemlich egal. Auch 100000 Pages á 64 KB würde ich ihm ohne Weiteres nicht ab.
War die letzte CPU ohne Interrupt nicht Intels 4004? Selbst der Nachfolger I4040 hatte bereits eine Interruptfunktion, weil es einfach sinnvoll ist...
Wolfgang R. schrieb: > War die letzte CPU ohne Interrupt nicht Intels 4004? Manche kleine PICs haben keinen Interrupt.
Eine Ansammlung von Lachnummern: http://www.bo8h.de/Argumente/ Das sind Argumente aus Sicht eines Kopfrechners - aber Computer sind dazu entwickelt worden, das Kopfrechnen oder das Rechnen mit Papier und Bleistift einem Esel anzuvertrauen, der alles hinnimmt, was man ihm aufträgt. Da ist ein gordischer Knoten in den Hirnwindungen. Wer schlägt ihn durch?
Seine Vorliebe für das Hexadezimalsystem fand in den 60ern eine gewisse Entsprechung im Fliesskommaformat von IBMs 360er Architektur. Und da die heute noch fortlebt, gibt es das immer noch. Es wird Josef aber wahrscheinlich nicht freuen, dass diese Rechner mittlerweile auch binäres IEEE-Format und dezimale Fliesskommarechnung beherrschen.
A. K. schrieb: > kleine PICs das sind Microcontroller... nicht eigentlich CPUs... Aber da kann bestimmt trefflich darüber gestritten werden.
Cyblord -. schrieb: > Es macht keinen Sinn, die Anzahl > adressierbarer Seiten als "unbestimmt" anzugeben. Die CPU zeigt auf den Steuerleitungen an, von welchem der Adressregister P,X,Y,Z eine ausgegebene Adresse kommt. Dadurch kann eine externe Logik jedem Adressregister eine eigene Speicherseite zuordnen. Ausserdem kann die CPU vier verschiedene Steuersignale ausgeben, welche die externe Logik zu einer Seitenumschaltung für eines der Adressregister veranlassen sollen. Beim Programmzähler P geschieht das gleichzeitig mit einem Sprungbefehl, so dass Sprünge in eine andere Seite möglich sind. Die Register der externen Logik, welche eine Speicherseite auswählen (genauer: ihre nicht aktiven Schattenregister), erhalten ihre Werte über IO-Befehle von der CPU. Die Breite dieser Register hängt ab von der externen Logik und ist nicht Teil der Definition der CPU, insofern ist die Zahl der Speicherseiten unbestimmt.
Wolfgang R. schrieb: >> kleine PICs > > das sind Microcontroller... nicht eigentlich CPUs... Microcontroller sind keine CPUs, haben aber mindestens eine CPU.
A. K. schrieb: > Wolfgang R. schrieb: >>> kleine PICs >> >> das sind Microcontroller... nicht eigentlich CPUs... > > Microcontroller sind keine CPUs, haben aber mindestens eine CPU. Und unter CPU versteht man einfach landläufig etwas, das für ein "echtes" Computersystem gedacht ist und nicht Embedded eingesetzt wird. Gegenbeispiele lassen sich da sicher finden, aber ich denke so verstehen es die meisten die von CPU sprechen.
Josef G. schrieb: > Die CPU zeigt auf den Steuerleitungen an, von welchem > der Adressregister P,X,Y,Z eine ausgegebene Adresse kommt. > Dadurch kann eine externe Logik jedem Adressregister eine > eigene Speicherseite zuordnen. Ausserdem kann die CPU > vier verschiedene Steuersignale ausgeben, welche die > externe Logik zu einer Seitenumschaltung für eines der > Adressregister veranlassen sollen. Beim Programmzähler P > geschieht das gleichzeitig mit einem Sprungbefehl, > so dass Sprünge in eine andere Seite möglich sind. . > Die Register der externen Logik, welche eine Speicherseite > auswählen (genauer: ihre nicht aktiven Schattenregister), > erhalten ihre Werte über IO-Befehle von der CPU. Die Breite > dieser Register hängt ab von der externen Logik und ist > nicht Teil der Definition der CPU, insofern ist die Zahl > der Speicherseiten unbestimmt. Ich hab noch eine Z8001 CPU rumliegen, die ist auch so gebaut und hat sich bekanntermaßen gegen Intel durchgesetzt ;-)
Angehängte Dateien:
-
8051.png
92 KB
Cyblord -. schrieb: > Und unter CPU versteht man einfach landläufig etwas, das für ein > "echtes" Computersystem gedacht ist und nicht Embedded eingesetzt wird. Diese Definition passt zum Mikroprozessor, nicht aber zur CPU. Wobei "embedded" auch mit einem reinen Mikroprozessor arbeiten kann. Das ist heute aufgrund der Integrationsdichte nur relativ selten geworden. Adaptecs SCSI Controller für ISA hatte einen 8085 an Bord, etliche Cisco Router der 90er 68020 oder 68030.
:
Bearbeitet durch User
A. K. schrieb: > Wobei "embedded" auch mit einem reinen Mikroprozessor arbeiten kann. Das > ist heute aufgrund der Integrationsdichte nur relativ selten geworden. Langfristig werden die klassischen Mikroprozessoren wohl aussterben. Bei den PC-Prozessoren müssen eigentlich nur die peripheren Chips im Prozessor verschwinden, dann ist es passiert. Gibt es eigentlich noch Bitslice-Prozessoren? Vor dem Hintergrund könnte es aber auch eine geschickte Strategie von Josef sein, sich einen Platz im Museum der Zuspätgekommenen zu reservieren...
A. K. schrieb: > Es wird Josef aber wahrscheinlich nicht freuen, dass > diese Rechner mittlerweile auch binäres IEEE-Format Versteh ich nicht. Was sollte ich dagegen haben?
Du prognostiziert Hex als die Zukunft. Und bei IBM ist es statt dessen die Vergangenheit, während die Zukunft binär und dezimal ist.
Ich versteh nicht den Gegensatz zwischen hex und binär. Binär ist das, was der Rechner intern macht. Hex ist die menschliche Sprechweise darüber. Da gibt es keinen Gegensatz.
:
Bearbeitet durch User
A. K. schrieb: > Seine Vorliebe für das Hexadezimalsystem fand in den 60ern eine > gewisse Entsprechung im Fliesskommaformat von IBMs 360er Architektur. Hab's mir jetzt angeschaut: https://de.wikipedia.org/wiki/System/360 Da steht: > Die wichtigsten Designkriterien waren: > 32- oder 64-Bit-Gleitkommaworte mit hexadezimaler Basis. Offenbar haben diese Rechner bei Gleitpunktzahlen einen Exponenten zur Basis 16(dez) verwendet. Etwas derartiges habe aber ich nie befürwortet. Die Basis 2 für den Exponenten bei Gleitpunktzahlen habe ich nie infrage gestellt.
Wenn das allgemein verwendete Zahlensystem auf Basis 16 arbeitet, wie du es prognostiziert, dann wäre es nur logisch, dass dies auch bei Fliesskommadarstellung erfolgt. Die Werte wären unmittelbar ohne Konvertierung lesbar. Der Grund damals dürfte aber banaler gewesen sein. Der Barrel-Shifter für die Operandenanpassung bei Addition und Subtraktion muss nicht bitwise arbeiten, sondern nibbleweise. Das reduziert den Aufwand. Bei einem Rechner aus Einzeltransistoren durchaus ein Thema, heute aber uninteressant.
:
Bearbeitet durch User
Josef G. schrieb: > Etwas derartiges habe aber ich nie befürwortet. Die Basis 2 für > den Exponenten bei Gleitpunktzahlen habe ich nie infrage gestellt. Diese IBM-Fuzzies sind aber auch Ignoranten...
Uhu U. schrieb: > Josef G. schrieb: >> Etwas derartiges habe aber ich nie befürwortet. Die Basis 2 für >> den Exponenten bei Gleitpunktzahlen habe ich nie infrage gestellt. > > Diese IBM-Fuzzies sind aber auch Ignoranten... Versteh ich nicht. Was hat deine Aussage mit meinem Beitrag zu tun?
Josef G. schrieb: > Die Basis 2 für den Exponenten bei Gleitpunktzahlen > habe ich nie infrage gestellt. Gemeint war hier die interne Zahlendarstellung. Im Zahlenstring bei Eingabe und Ausgabe wird man natürlich den Exponenten zur Basis 16 verwenden. Die Konvertierung geht ohne Rundungsfehler.
Josef G. schrieb: > Ich sehe da eine große Ähnlichkeit. Das ist mir schon klar. Du bis ja auch, wie sag ich das jetzt politisch korrekt, "anders".
Was war noch mal das Problem, welches gelöst werden sollte?
Hier ist auch jemand mit dem Dezimalsystem unzufrieden: http://www.sueddeutsche.de/wissen/winkel-winkel-1.3676793 Allerdings will er nicht das Hexadezimalsystem...
:
Bearbeitet durch User
Auf meiner Website gibt es jetzt zum Download Informationen zum internen Aufbau der CPU. Und es gibt ein C-Programm, welches zu jeder Operation den internen Ablauf anzeigt. Damit sollte es möglich sein, den VHDL-Code nachzuvollziehen. Das Programm ist auf Linux-PC getestet, sollte aber auch unter Windows laufen. Siehe im Verzeichnis info die Datei CPU-arch.txt und im Verzeichnis soft die Datei steu.c.txt http://www.bo8h.de/Downloads/
:
Bearbeitet durch User
Ich habe gerade versucht, Deine sog. Dokumentation zu lesen, und es nach sehr kurzer Zeit sein lassen. Es ist die Mühe nicht wert, und Du wirst damit auch keine weiteren Anhänger für Deine CPU gewinnen können. Wir haben Dir schon Unmengen an Tipps für die Dokumentation und eine Überarbeitung der CPU gegeben, aber Du ignorierst sie komplett. Allmählich ist das ganze doch schon ziemlich pathologisch.
Beitrag #5179222 wurde von einem Moderator gelöscht.
Zur CPU wurde eh schon vor einigen Jahren alles gesagt, aber warum haben alle Dateien *.txt als Endung?
Alexander F. schrieb: > Zur CPU wurde eh schon vor einigen Jahren alles gesagt, Das neue an dem C-Programm ist, dass es durch seinen an den VHDL-Code angelehnten Quelltext den VHDL-Code nachvollziehbar machen soll und dadurch Vorbehalte bei Leuten abbauen soll, die dem VHDL-Code misstrauen. > aber warum haben alle Dateien *.txt als Endung? Mein Apple-Rechner, mit dem ich die Zip-Datei erstellt habe, kennt das Suffix .vhd nicht, deshalb habe ich .txt angehängt. Damit alles einheitlich ist, habe ich es auch bei den C-Texten so gemacht. Ich dachte halt, wenn alle Dateien .txt-Dateien sind, kann beim Komprimieren nichts schiefgehen.
Josef G. schrieb: > Damit alles einheitlich ist, habe ich es auch bei den C-Texten > so gemacht. Das Argument ist wirklich klasse... Warum ersetzt du nicht jeden von Leerzeichen verschiedenen Buchstaben in deiner "Dokumentation" durch ein X oder ein u? Dann wäre alles noch viel einheitlicher.
Uhu U. schrieb: > Das Argument ist wirklich klasse... Warum ersetzt du nicht jeden von > Leerzeichen verschiedenen Buchstaben in deiner "Dokumentation" durch ein > X oder ein u? Dann wäre alles noch viel einheitlicher. Deshalb gibts ja auch schon seit zig Jahren ein Betriebssystem, das keine verwirrenden Extensions braucht und vorne U und hinten X heisst.
A. K. schrieb: > Deshalb gibts ja auch schon seit zig Jahren ein Betriebssystem, das > keine verwirrenden Extensions braucht und vorne U und hinten X heisst. Ich meinte "die Dokumentation", also den Inhalt, nicht die Dateinamen...
Beitrag #5181717 wurde von einem Moderator gelöscht.
Der Thread hier ist zwar über die CPU, aber da auch mehrfach vom Emulationsprogramm die Rede war, möchte ich noch auf eine neue Version des Emulationsprogramms hinweisen: Beitrag "Re: 8bit-Computing mit FPGA"
Vielleicht solltest du zuerst mal ein Archiv erstellen, das nicht alle Dateien mit *.txt als Erweiterung enthält. Das hast du in den letzten 5 Jahren nicht geschafft.
Josef G. schrieb: > möchte ich noch auf > eine neue Version des Emulationsprogramms hinweisen: > Beitrag "Re: 8bit-Computing mit FPGA" Danke für den Link, hab schon lange auf ein Update gewartet
Alexander F. schrieb: > Vielleicht solltest du zuerst mal ein Archiv erstellen, > das nicht alle Dateien mit *.txt als Erweiterung enthält. Ich vermute mal ganz stark, dass Leute, denen solche Dinge wie die Dateiendungen wichtig sind, sich ohnehin nie für das Projekt interessieren würden.
Ich vermute mal ganz stark, dass Leute, denen solche Dinge wie die Dateiendungen nicht wichtig sind, sich ohnehin auch nie für das Projekt interessieren würden.
Sagen wir's mal so... wenn der Autor sich nicht die Mühe gibt, sein Projekt angemessen zu präsentieren - und dazu zähle ich gebrauchbare Dokumentation - dann gibt er sich höchstwahrscheinlich auch keine Mühe beim Inhalt. Damit ist das Projekt mit hoher Wahrscheinlichkeit wertlos. Aber gut, ich beurteile die Qualität von Quellcode unter anderem auch an eingestreuten Leerzeichen und Tabs am Zeilenende. Die sind ein Zeichen dafür, dass jemand die Zeile entweder zigmal bearbeitet oder in aller Hast hingeschrieben hat (also in beiden Fällen nicht sauber gearbeitet hat).
Wolfgang R. schrieb: > Aufgrund des exorbitanten Sinnlosigkeitsfaktors wäre das sicher eine > gute CPU für Kurt Bindl... LOL Ferner werden noch Freiwillige gesucht, die einen Brainfuck-Compiler für die bo8 CPU implementieren (vorzugsweise self-hosted)
Josef G. schrieb: > S. R. schrieb: >> Leerzeichen und Tabs am Zeilenende. > > Gibt es bei mir nicht. Doch, gibt es: soft/emul.c.txt soft/steu.c.txt vhdl/cpu.vhd.txt vhdl/fcpu.vhd.txt Dazu kommt noch die unglaublich hübsche Formatierung des C-Codes:
1 | if(st[0]=='s') { printf("\n(storno: #) save/ Dateikennbuchstabe: "); |
2 | scanf("%4s",sr); name[7]=sr[0]; if(name[7]>96 && name[7]<123) { |
3 | datei = fopen(name,"w"); if(datei) { for (n=0; n<256; n++) { |
4 | for(i=0; i<32; i++) { b=mem[1][0xa000+n*32+i]; h=((b>>4) & 15)+48; |
5 | if(h>57) h=h+39; b=(b & 15)+48; if(b>57) b=b+39; sr[2*i]= (char) h; |
6 | sr[2*i+1]= (char) b; } fprintf(datei,"%s\n",sr); } fclose(datei); }}} |
Das wurde aber auch schon vor 5 Jahren kritisiert, also erwarte ich nicht, dass sich das in Zukunft ändert. [Mod: C-Tags angepasst]
:
Bearbeitet durch Moderator
Alexander F. schrieb: > Doch, gibt es: > soft/emul.c.txt Wo? Welche Zeile? Bitte nur aktuelle Version von meiner Website. In älteren Versionen von cpu.vhd und fcpu.vhd hatte ich eine Stelle gefunden, ist inzwischen geändert.
Josef G. schrieb: > Alexander F. schrieb: >> Doch, gibt es: >> soft/emul.c.txt > > Wo? Welche Zeile? Bitte nur aktuelle Version von meiner Website. > > In älteren Versionen von cpu.vhd und fcpu.vhd hatte ich > eine Stelle gefunden, ist inzwischen geändert.
1 | grep -rno '[[:blank:]]$' . |
2 | ./info/SYS-doku.txt:807: |
3 | ./info/English/En-Hardware.txt:244: |
4 | ./info/English/En-CPU-docu.txt:52: |
5 | ./info/English/En-SYS-docu.txt:217: |
6 | ./info/English/En-SYS-docu.txt:755: |
7 | ./info/English/En-SYS-docu.txt:801: |
8 | ./info/Emul.txt:237: |
9 | ./soft/emul.c.txt:21: |
10 | ./soft/emul.c.txt:237: |
11 | ./soft/steu.c.txt:755: |
12 | ./soft/steu.c.txt:757: |
13 | ./soft/steu.c.txt:763: |
14 | ./vhdl/cpu.vhd.txt:394: |
15 | ./vhdl/cpu.vhd.txt:742: |
16 | ./vhdl/fcpu.vhd.txt:394: |
17 | ./vhdl/fcpu.vhd.txt:742: |
Alexander F. schrieb: > Dazu kommt noch die unglaublich hübsche Formatierung des C-Codes: Oh. Sag mal, Josef, ist das wirklich so von Dir geschrieben worden, oder hast Du das durch einen Obfuscator geschickt, damit das so "kompakt" ist?
Rufus Τ. F. schrieb: > Sag mal, Josef, ist das wirklich so von Dir geschrieben worden, oder > hast Du das durch einen Obfuscator geschickt, damit das so "kompakt" > ist? Ungefähr so sieht LF-separierter Code aus, wenn man ihn mit Notepad öffnet. Jedenfalls sehen die 2 *.c.txt Files, in die ich reinsah, zwar immer noch krass aus, aber nicht ganz so rechteckig.
1 | while(1) { |
2 | |
3 | printf("\n\n -------------------------------"); |
4 | printf("\n ########### (Ende:q) OpCode: "); |
5 | scanf("%3s",KEY); if(KEY[0]=='q') break; |
6 | if(KEY[0]>96) KEY[0]=KEY[0]-39; if(KEY[1]>96) KEY[1]=KEY[1]-39; |
7 | n=((KEY[0]-48)*16 +KEY[1]-48) & 255; printf("\n"); m=2; getchar(); |
8 | printf(" -------------------------------\n\n"); |
9 | |
10 | while(1) { x3=s[3][m][n]; x2=s[2][m][n]; x1=s[1][m][n]; x0=s[0][m][n]; |
11 | |
12 | printf(" "); if(n<16) printf("0"); |
13 | printf("%x= %s %s N3 N2 N1 N0\n %s %s %s %s\n\n", |
14 | n,mnem[n],phas[m],cond[x3],cond[x2],cond[x1],cond[x0]); |
15 | |
16 | for(k=4;k<98;k++) {if((k==12) || (!(m & 1) && (k==55)) || ((m & 1) && (k==88))) printf("\n"); |
17 | |
18 | x=s[k][m][n]; if(x) printf(" %s %s\n",cccc[x],steu[k]);} printf("\n\n"); |
19 | |
20 | if((s[97][m][n] & 1) || (m==7)) break; if((n==0) && (m==3)) m=0; else m++; |
21 | |
22 | printf(" -------------------------------\n"); getchar();}}} |
:
Bearbeitet durch User
Auch so formatiert wäre so etwas für mich ein Grund, jemandem dringend ein ganz anderes Betätigungsfeld nahezulegen.
Rufus Τ. F. schrieb: > Auch so formatiert wäre so etwas für mich ein Grund, jemandem dringend > ein ganz anderes Betätigungsfeld nahezulegen. Deshalb ja auch bola: https://www.mikrocontroller.net/articles/8bit-Computer:_bo8h#Die_Programmiersprache_bola
Das Listing von A.K. stammt aus steu.c Die Anleitung dazu steht in CPU-arch.txt
Vielleicht könnte mal ein Moderator in dem Beitrag Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" die Tags für den C-Code anpassen?
Wolfgang R. schrieb: > Soweit kommt's noch... War als höfliche Bitte gemeint, auch wenn's nicht so rüberkommt, wie mir nun nachträglich klar wird.
Josef G. schrieb: > Vielleicht könnte mal ein Moderator in dem Beitrag > Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" > die Tags für den C-Code anpassen? Ja, das habe ich leider übersehen. Mehr Farbe macht den Code sicher lesbarer. Vielleicht könntest du dein ganzes Projekt mal durch clang-format schicken.
Josef G. schrieb: > Vielleicht könnte mal ein Moderator in dem Beitrag > Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" > die Tags für den C-Code anpassen? Habe ich gerade gemacht. Jetzt ist der Zeichensalat nicht mehr schwarz, sondern bunt. :) Merke: C-Tags formatieren den Text nicht neu, sondern färben lediglich Schlüsselwörter, Strings etc. ein.
Josef G. schrieb: > Alexander F. schrieb: >> Doch, gibt es: >> soft/emul.c.txt > > Wo? Welche Zeile? Bitte nur aktuelle Version von meiner Website. > > In älteren Versionen von cpu.vhd und fcpu.vhd hatte ich > eine Stelle gefunden, ist inzwischen geändert. Josef, du bist wirklich ein Herzchen... Um Leerzeichen am Zeilenende reißt du dir schier ein Bein aus, aber deine chaotische Code-Formatierung und die apokalyptische Dokumentation geht dir völlig am Allerwertesten vorbei. Du hast wirklich einen sehr ausgeprägten Sinn für Nebensächlichkeiten, der aber auch - ich möchte es nicht verschweigen - eine sehr positive Seite hat: du häst damit alle nur halbwegs vernünftigen potentiellen Interessenten davon ab, sich länger, als zur Erlangung eines ersten Eindrucks mit deinem Zeugs auseinanderzusetzen. Wärst du Buchhalter, wärst du selbst unter Deinesgleichen als weltfremder Pedant verschrieen...
:
Bearbeitet durch User
Uhu U. schrieb: > Um Leerzeichen am Zeilenende reißt du dir schier ein Bein aus, Das Thema habe nicht ich angefangen, ich habe nur reagiert. Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
Josef G. schrieb: > Uhu U. schrieb: >> Um Leerzeichen am Zeilenende reißt du dir schier ein Bein aus, > > Das Thema habe nicht ich angefangen, ich habe nur reagiert. Oh Gott, oh Gott... Wie oft bist du im Kindergarten sitzen geblieben?
Alexander F. schrieb: > Dazu kommt noch die unglaublich hübsche Formatierung des C-Codes: > > if(st[0]=='s') { printf("\n(storno: #) save/ Dateikennbuchstabe: "); > scanf("%4s",sr); name[7]=sr[0]; if(name[7]>96 && name[7]<123) { > datei = fopen(name,"w"); if(datei) { for (n=0; n<256; n++) { > for(i=0; i<32; i++) { b=mem[1][0xa000+n*32+i]; h=((b>>4) & 15)+48; > if(h>57) h=h+39; b=(b & 15)+48; if(b>57) b=b+39; sr[2*i]= (char) h; > sr[2*i+1]= (char) b; } fprintf(datei,"%s\n",sr); } fclose(datei); }}} Ja, der Code enthält viel zu viele Leerzeichen und anderes unnützes Zeug. Am hässlichsten ist aber der rechte Flatterrand. So sieht optimierter und sauber formatierter C-Code aus:
1 | if(st[0]=='s'){printf("\n(\ |
2 | storno: #) save/ Dateiken\
|
3 | nbuchstabe: ");scanf("%4s"\ |
4 | ,sr);name[7]=sr[0];if(name\ |
5 | [7]>96&&name[7]<123){datei\ |
6 | =fopen(name,"w");if(datei)\ |
7 | {for(n=0;n<256;n++){for(i=\ |
8 | 0;i<32;i++){b=mem[1][0xa00\ |
9 | 0+n*32+i];h=(b>>4&15)+48;i\ |
10 | f(h>57)h+=39;b=(b&15)+48;i\ |
11 | f(b>57)b+=39;sr[2*i]=h;sr[\ |
12 | 2*i+1]=b;}fprintf(datei,"%\ |
13 | s\n",sr);}fclose(datei);}}} |
;-)
Einige Variablennamen wie "datei" und "name" sind unnötig lang, hier würde ein "d" und ein "n" völlig ausreichen. Man könnte auch die unnötig langen Namen der Dateifunktionen (fopen/fprintf/fclose) mit entsprehchenden #defines sinnvoll abkürzen, um das ganze gleich viel übersichtlicher zu gestalten. Die Zeilen in Deinem Formatierungsbeispiel sind eindeutig zu kurz, das ist Ressourcenverschwendung.
:
Bearbeitet durch User
Rufus Τ. F. schrieb: > Einige Variablennamen wie "datei" und "name" sind unnötig lang, > hier würde ein "d" und ein "n" völlig ausreichen. > Man könnte auch die unnötig langen Namen der Dateifunktionen > (fopen/fprintf/fclose) mit entsprehchenden #defines sinnvoll abkürzen, > um das ganze gleich viel übersichtlicher zu gestalten. Sinnvolle Abkürzungen wären zum Beispiel immer der letzte Buchstabe der jeweiligen Funktion. Den kann man sich ganz besonders gut merken:
1 | #define e fclose
|
2 | #define f fprintf
|
3 | #define n fopen
|
Leider kollidiert das n mit Deinem Vorschlag, n für name zu verwenden. Aber das ist kein Problem: Du nimmst dann einfach den vorletzten Buchstaben statt den letzten. Also m für name... passt!
Ich sehe: Wir verstehen uns. Unterscheidet sich das Resultat eigentlich in der Lesbarkeit von den Opcodes der CPU, die das Zeug simulieren soll?
Entscheidend ist nicht die Lesbarkeit, sondern die Funktion. Und funktionieren tut's.
Josef G. schrieb: > Entscheidend ist nicht die Lesbarkeit, sondern die Funktion. O nein. Unlesbares Zeug ist unwartbar. Daß es funktioniert, kann durchaus Zufall sein; Fehler in so einem Gemansche findet man eh' nie.
Josef G. schrieb: > Entscheidend ist nicht die Lesbarkeit, sondern die Funktion. > > Und funktionieren tut's. Hast du die CPU nicht für "Hobbyisten" gemacht? Die "Hobbyisten" die ich kenne lesen sehr gerne Programmcode... Mal im erst: Klar können die meisten Leute hier im Forum deinen Datensalat so zurechtbiegen, dass sie was damit anfangen können (z.B. Dateiendungen ändern oder Code formatieren). Aber wer hat schon lust darauf? Du gehst doch auch nicht übel-riechend, ungeduscht und mit zersausten Klamotten zur Familienfeier, nur weil du dir sicher bist, dass dich deine Familie immer noch liebt.
Josef G. schrieb: > Entscheidend ist nicht die Lesbarkeit, sondern die Funktion. Die Funktion ist die ALLERMINDESTE Anforderung an Code. Wer sich allein damit zufrieden gibt, stellt keine besonderen Ansprüche an sich.
Rufus Τ. F. schrieb: > Josef G. schrieb: >> Entscheidend ist nicht die Lesbarkeit, sondern die Funktion. > > O nein. Unlesbares Zeug ist unwartbar. Für Josef vielleicht nicht. Und außer ihm wird vermutlich niemals jemand Änderungen an dem Code vornehmen wollen. Rufus Τ. F. schrieb: > Daß es funktioniert, kann durchaus Zufall sein Ob der Code funktioniert, kann außer Josef niemand beurteilen, da keiner außer ihm weiß, was dessen Funktion überhaupt sein soll. Deswegen sehe ich da keinerlei Probleme ;-)
@ Josef G. (bome) Benutzerseite
>Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.
OMG! Und da wir dich kennen, wissen wir, daß du das ernst meinst!
Mein Beileid!
Josef G. schrieb: > Entscheidend ist nicht die Lesbarkeit, sondern die Funktion. In den 60igern des letzten Jahrhunderts vielleicht.
Das wegen seiner Formatierung kritisierte Programmstück:
1 | if(st[0]=='s') { printf("\n(storno: #) save/ Dateikennbuchstabe: "); |
2 | scanf("%4s",sr); name[7]=sr[0]; if(name[7]>96 && name[7]<123) { |
3 | datei = fopen(name,"w"); if(datei) { for (n=0; n<256; n++) { |
4 | for(i=0; i<32; i++) { b=mem[1][0xa000+n*32+i]; h=((b>>4) & 15)+48; |
5 | if(h>57) h=h+39; b=(b & 15)+48; if(b>57) b=b+39; sr[2*i]= (char) h; |
6 | sr[2*i+1]= (char) b; } fprintf(datei,"%s\n",sr); } fclose(datei); }}} |
anders formatiert:
1 | if(st[0]=='s') { |
2 | |
3 | printf("\n(storno: #) save/ Dateikennbuchstabe: "); |
4 | scanf("%4s",sr); name[7]=sr[0]; |
5 | |
6 | if(name[7]>96 && name[7]<123) { |
7 | |
8 | datei = fopen(name,"w"); |
9 | |
10 | if(datei) { |
11 | |
12 | for (n=0; n<256; n++) { |
13 | |
14 | for(i=0; i<32; i++) { |
15 | |
16 | b=mem[1][0xa000+n*32+i]; |
17 | h=((b>>4) & 15)+48; if(h>57) h=h+39; |
18 | b=( b & 15)+48; if(b>57) b=b+39; |
19 | sr[2*i]= (char) h; sr[2*i+1]= (char) b; |
20 | }
|
21 | |
22 | fprintf(datei,"%s\n",sr); |
23 | }
|
24 | |
25 | fclose(datei); |
26 | }
|
27 | }
|
28 | }
|
Funktion: Wenn aus dem Menü "save" ausgewählt wurde, wird ein Dateikennbuchstabe erfragt und der Inhalt der Seite E des Text-RAM als Hexdump gespeichert. Das Programmstück ist ein winziger Teil des Gesamtprogramms. Wenn man sich von der Funktion überzeugt hat, kommt man vielleicht auch zu dem Schluss, dass es besser ist, das Programmstück in kompakter Form zu speichern, weil es sonst den Gesamtcode nur unnötig aufbläht.
Frank M. schrieb: > Aber das ist kein Problem: Du nimmst dann einfach den vorletzten > Buchstaben statt den letzten. Also m für name... passt! ROTFL BTC
Josef G. schrieb: > Wenn man sich von der Funktion überzeugt hat, kommt man vielleicht auch > zu dem Schluss, dass es besser ist, das Programmstück in kompakter Form > zu speichern, weil es sonst den Gesamtcode nur unnötig aufbläht. Nein. Tut man nicht. So kann man das wenigestens ein bisschen lesen. Das ändert allerdings auch nichts an der unterirdischen Qualität des "Codes". > if(name[7]>96 && name[7]<123) { Was bedeuten diese "magic numbers"? Warum 96? Warum nicht 43? Mir ist klar, daß das ASCII-Codes sind. Aber warum schreibst Du dann nicht die zugehörigen Zeichen als Zeichenkonstanten da hin? 96 ist '@'. 123 ist '{'. Der Compiler versteht auch das, das ist äquivalent. Und was ist mit Großbuchstaben? Warum verwendest Du nicht einfach die Standardfunktion isalpha? Das könnte man einfach so lesen: > if (isalpha(name[7])) { (Was passiert eigentlich mit name[0] bis name[6]? Ach ... nee, ich will das doch besser nicht wissen)
Rufus Τ. F. schrieb: > Was passiert eigentlich mit name[0] bis name[6]? Steht im Kopf bei der Variablen-Vereinbarung:
1 | name[9]="emtext-0"; |
Rufus Τ. F. schrieb: > Und was ist mit Großbuchstaben? Da auf meiner Website die Dateien emtext-a, emtext-b, emtext-c im Verzeichnis soft mitgeliefert werden, sollte dem Anwender klar sein, dass Kleinbuchstaben erwartet werden.
Für welches Problem noch mal ist eigentlich diese Lösung gedacht? "Wenn das die Lösung sein soll, dann hätte ich gerne mein Problem wieder!" (Beliebter Spruch bei meinen Entwicklerkollegen)
Wolfgang R. schrieb: > Für welches Problem noch mal ist eigentlich diese Lösung gedacht? Man könnte MS fragen ob die ihre nächste Windows Version damit bauen wollen. Das wäre dann das garantiert sicherste BS aller Zeiten.
Josef G. schrieb: > Rufus Τ. F. schrieb: >> Was passiert eigentlich mit name[0] bis name[6]? > > Steht im Kopf bei der Variablen-Vereinbarung: >
1 | > name[9]="emtext-0"; |
2 | >
|
Sollte vollständig natürlich heissen
1 | char name[9]="emtext-0"; |
Da die Akzeptanz des Emulationsprogramms offenbar vor allem an der rechteckigen Formatierung eines kleinen Programmteils scheiterte, habe ich diese nun geändert. Zu der rechteckigen Formatierung war es vor sehr langer Zeit gekommen, als ich den Quelltext ausdrucken wollte und deshalb die Textbreite reduziert habe. http://www.bo8h.de/Downloads/
Josef G. schrieb: > Da die Akzeptanz des Emulationsprogramms offenbar vor allem > an der rechteckigen Formatierung eines kleinen Programmteils > scheiterte, habe ich diese nun geändert. Jetzt fehlt noch ein Makefile und normale Dateinamen.
Alexander F. schrieb: > Makefile Wie man das Programm compiliert, und überhaupt eine ausführliche Anleitung zum Programm, steht auf der Seite Emul.txt. Wem das Testen der Beispielprogramme in emtext-a, emtext-b, emtext-c zu aufwendig ist, der schaue sich weiter unten den Abschnitt zu Conway's Game of Life an.
:
Bearbeitet durch User
Josef G. schrieb: > offenbar vor allem an der rechteckigen Formatierung eines > kleinen Programmteils scheiterte, Nein. Du hast die Kritik nicht verstanden.
@ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite >> offenbar vor allem an der rechteckigen Formatierung eines >> kleinen Programmteils scheiterte, >Nein. Du hast die Kritik nicht verstanden. Und du hast immer noch nicht Josef's medizinisches, praktisch unlösbares Problem verstanden. Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht" Beitrag "Re: 8bit-Computing mit FPGA" Beitrag "Re: Ein Vorschlag zur Intervall-Arithmetik"
Alexander F. schrieb: > Josef G. schrieb: >> Da die Akzeptanz des Emulationsprogramms offenbar vor allem >> an der rechteckigen Formatierung eines kleinen Programmteils >> scheiterte, habe ich diese nun geändert. > > Jetzt fehlt noch ein Makefile und normale Dateinamen. Du bist wirklich maßlos. Jetzt ist Josef über seinen Schatten gesprungen und DU forderst schon wieder neue sportliche Höchstleistungen. So geht das nicht, ein alter Mann ist kein D-Zug...
Alexander F. schrieb: > normale Dateinamen
1 | cp emul.c.txt emul.c |
2 | cp coka.txt coka |
3 | cp teca.txt teca |
oder dasselbe mit mv statt cp.
Uhu U. schrieb: > Yalu X. schrieb: >> Dass ein Compiler > > Welcher Compiler? Öhem, könntest du mal richtig zitieren? War das ein Beitrag vor 20 Jahren?
Guido B. schrieb: > Öhem, könntest du mal richtig zitieren? War das ein Beitrag vor > 20 Jahren? Öhem, bist du zu doof, den Rückwärtslink zu benutzen?
Falk B. schrieb: > @ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite > >>Nein. Du hast die Kritik nicht verstanden. > > Und du hast immer noch nicht Josef's medizinisches, praktisch unlösbares > Problem verstanden. Jedoch hat Rufus ganz sicher verstanden, dass Du der Ansicht bist, dass er das noch nicht verstanden hat. Das hast Du nur noch nicht verstanden. Deshalb schreibst Du immer wieder das Gleiche. Ein wenig so wie Josef.
Josef G. schrieb: > Alexander F. schrieb: >> normale Dateinamen > cp emul.c.txt emul.c > cp coka.txt coka > cp teca.txt teca > oder dasselbe mit mv statt cp. Gute Idee. Warum lieferst du deinen Code nicht gleich auf diese Weise aus?
Uhu U. schrieb: > Welcher Compiler? GCC. Frag mich aber (mehr als eineinhalb Jahre danach) nicht nach der Version.
Uhu U. schrieb: > Guido B. schrieb: >> Öhem, könntest du mal richtig zitieren? War das ein Beitrag vor >> 20 Jahren? > > Öhem, bist du zu doof, den Rückwärtslink zu benutzen? Öhem, sorry, das war in der Tat das Problem. Habs gefunden.
Josef G. schrieb: > Die C-Quelldateien sind jetzt ohne Zusatz-Endung .txt Endlich ist es so weit, und wir können durchstarten! Jetzt wird sich bo8 durchsetzen, und in zwei Jahren kennt keiner mehr ARM, AVR und x86.
Josef G. schrieb: > Die C-Quelldateien sind jetzt ohne Zusatz-Endung .txt Und warum benennst du die VHDL-Dateien nicht um? Irgendwo kannst du in deinem Betriebssystem einstellen, welcher Dateityp mit welchem Programm geöffnet wird.
http://www.bo8h.de/Argumente/ "Angeblich leiden manche Menschen an Dyskalkulie. " Und andere an, ähh. Ach was solls, das hatten wir alles schon ein Dutzend mal. "Die Bailey-Borwein-Plouffe-Formel zur Berechnung von Pi ist ein Argument für die Sonderstellung des Hexadezimalsystems." WOW! https://de.wikipedia.org/wiki/Bailey-Borwein-Plouffe-Formel Na dann ist das Hexadezimalsystem ja ger nicht mehr aufzuhalten! Naja, das ist vielleicht kein sonderlich intersantes Projekt für Techniker, dafür umso mehr für Psychiologen.
Beitrag #5398939 wurde von einem Moderator gelöscht.
Vielleicht hat ja die umständliche Zeicheneingabe bei der alten Version des Emulationsprogramms den Einen oder Anderen abgeschreckt. Bei der neuen Version ist sie komplett neu. Wer sich nicht für das Projekt interessiert, interessiert sich vielleicht trotzdem für meine Implementierung von Game of Life. Die Beschreibung dazu steht auf der Seite Emul.txt am Ende der Beschreibung des Emulationsprogramms. Man braucht dazu auch die Datei teca im aktuellen Verzeichnis. Zur Eingabe des Kommandos 1.GOL drückt man 1^gol und dann Return. Zuvor wechselt man mit shift-e in die Seite E und erstellt dort im Bereich der ersten 64 Zeilen ein wenig Text. Zum angenehmeren Arbeiten schiebt man mit shift-v Text und Cursor ein paar Zeilen nach unten. Der Text dient als Startbild. Mit shift-e kehrt man in die Seite C zurück und gibt dort das Kommando ein. Nach Eingabe-Aufforderung SIZE drückt man 0 oder 1, nach Eingabe-Aufforderung RULE drückt man 0. Iterationen führt man aus mit Taste ^.
ich hab mir deinen Code NICHT angeschaut, nur das 1. beste File genommen: x Beliebiges Beispiel:
1 | t1oup <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvs) or |
2 | (s7 and s6 and z5 and z4 and z3 and z2 and z1 and s0 and ccvz) or |
3 | (s7 and s6 and z5 and z4 and z3 and z2 and s1 and z0 and ccus) or |
4 | (s7 and s6 and z5 and z4 and z3 and z2 and s1 and s0 and ccuz) or |
5 | (s7 and s6 and z5 and z4 and z3 and s2 and z1 and z0 and ccas) or |
6 | (s7 and s6 and z5 and z4 and z3 and s2 and z1 and s0 and ccaz) or |
7 | (s7 and s6 and z5 and z4 and z3 and s2 and s1 and z0 and ccks) or |
8 | (s7 and s6 and z5 and z4 and z3 and s2 and s1 and s0 and cckz) or |
9 | (s7 and s6 and z5 and z4 and s3 and s0 and ccsz) or |
10 | (s7 and s6 and z5 and z4 and s3 and s1 and ccsz) or |
11 | (s7 and s6 and z5 and z4 and s3 and s2 and ccsz) ; |
12 | t1our <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvz) or |
13 | (s7 and s6 and z5 and z4 and z3 and z2 and z1 and s0 and ccvs) or |
14 | (s7 and s6 and z5 and z4 and z3 and z2 and s1 and z0 and ccuz) or |
15 | (s7 and s6 and z5 and z4 and z3 and z2 and s1 and s0 and ccus) or |
16 | (s7 and s6 and z5 and z4 and z3 and s2 and z1 and z0 and ccaz) or |
17 | (s7 and s6 and z5 and z4 and z3 and s2 and z1 and s0 and ccas) or |
18 | (s7 and s6 and z5 and z4 and z3 and s2 and s1 and z0 and cckz) or |
19 | (s7 and s6 and z5 and z4 and z3 and s2 and s1 and s0 and ccks) or |
20 | (s7 and s6 and z5 and z4 and s3 and s0 and ccss) or |
21 | (s7 and s6 and z5 and z4 and s3 and s1 and ccss) or |
22 | (s7 and s6 and z5 and z4 and s3 and s2 and ccss) ; |
Bin weiterhin schwer beeindruckt wie man sowas versteht und vorallem wie man eine Woche nachdem man es geschrieben hat, noch weiß was es macht.. geschweige denn einen Fehler finden würde.. aber: https://en.wikipedia.org/wiki/Duplicate_code Falls du irgendwann mal in die Geschichtsbücher eingehen solltest, dann als der Mensch der mit maximalstem Aufwand das minnimalste Problem gelöst hast.. zum Editor: es gibt Telefonbuch dicke Threads über "ist vi besser als notepad" bei deinem Editor wäre das ein Einzeiler ...
:
Bearbeitet durch User
Robert L. schrieb: > Duplicate_code Schau mal genau hin:
1 | t1oup <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvs) or |
2 | t1our <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvz) or |
Josef G. schrieb: > Schau mal genau hin:t1oup <= (s7 and s6 and z5 and z4 and z3 and z2 and > z1 and z0 and ccvs) or > t1our <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvz) > or Ja, alle Operanden bis auf den letzten (also 89%) sind gleich, deswegen Roberts Hinweis auf duplicate Code.
hier auch ein schönes beispiel
1 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
2 | h=h+2; if(b & 128) k=k+4; |
3 | |
4 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
5 | h=h+2; if(b & 64) k=k+4; |
6 | |
7 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
8 | h=h+2; if(b & 32) k=k+4; |
9 | |
10 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
11 | h=h+2; if(b & 16) k=k+4; |
12 | |
13 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
14 | h=h+2; if(b & 8) k=k+4; |
15 | |
16 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
17 | h=h+2; if(b & 4) k=k+4; |
18 | |
19 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
20 | h=h+2; if(b & 2) k=k+4; |
21 | |
22 | punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1; |
23 | h=h+2; if(b & 1) k=k+4; } |
Bin ich hier in der Rubrik "Quellcode aus der Hölle" gelandet?
Ich weiß nicht wie man das höflich formuliert. Aber jemand der solchen Code produziert und gleichzeitig eine Programmiersprache erfindet. Ist halt schon irgendwie so, als ob jemand der glaubt Elektronen wären an Fixstellen in einem Atom würde versuchen einem Physiker die Welt zu erklären..
:
Bearbeitet durch User
Ich finde im ganzen Code keine Funktionen und der Inhalt von mass.c, dass.c und emul.c ist auch zu ca. 50% gleich. Im VHDL Code ist es noch viel schlimmer. Da gibt es mehrere Dateien, die zu mehr als 90%, teilweise sogar 100% gleich sind.
Robert L. schrieb: > Aber jemand der solchen Code produziert und gleichzeitig eine > Programmiersprache erfindet Es geht ja nicht nur um den Code. Das iet ja nur ein Bruchstück des Problems. Hier passt halt garnichts: der Code, das VHDL, die Sprache, das Konzept an sich, die Namen der Register und Befehle, die Doku. Und allen vorran: die völlige Beratungsresistenz.
Beitrag #5402344 wurde von einem Moderator gelöscht.
Robert L. schrieb: > Bin weiterhin schwer beeindruckt wie man sowas versteht und vorallem wie > man eine Woche nachdem man es geschrieben hat, noch weiß was es macht.. > geschweige denn einen Fehler finden würde.. Die von Josef für das von Dir zitierte Beispiel gewählte tabellenähnliche Form halte ich im konkreten Fall sogar für sehr übersichtlich, da die Art und Weise der Befehldekodierung ersichtlich wird. > aber: https://en.wikipedia.org/wiki/Duplicate_code Der Wikipedia-Artikel bezieht sich ausschließlich auf Duplicate Code im Bereich der Softwareentwicklung. In Deinem Beispiel geht es jedoch um eine Hardwarebeschreibung, bei der eine explizitere Schreibweise in manchen Fällen durchaus sinnvoll sein kann. Das Beispiel ist eben einfach eine Darstellung in disjunktiver Normalform. Ich sehe auch nicht, dass die Zusammenfassung des gemeinsamen Anteils "s7 and s6 and z5 and z4 and z3" die Lesbarkeit verbessern würde. Der ansonsten ausgesprochenen Kritik an Josefs Projekt, Quellcode, Struktur, Dokumentation schließe ich mich natürlich an und habe solche auch selbst schon wiederholt geübt. Aber es bringt einfach nichts.
Andreas S. schrieb: > Die von Josef für das von Dir zitierte Beispiel gewählte > tabellenähnliche Form halte ich im konkreten Fall sogar für sehr > übersichtlich, da die Art und Weise der Befehldekodierung ersichtlich > wird. Die Übersichtlichkeit leidet eher darunter, dass es zum "Finde den Unterschied!" wird. Die Variablen sind sich optisch zu ähnlich.
:
Bearbeitet durch User
Alexander F. schrieb: > und der Inhalt von mass.c, > dass.c und emul.c ist auch zu ca. 50% gleich. Wäre es besser gewesen, ich hätte den gemeinsamen Teil nur einmal im Download-File gespeichert und würde dann in der Dokumentation zu den einzelnen Programmen beschreiben, wie man den gemeinsamen Teil in die einzelnen Dateien hinein-kopieren muss? Alexander F. schrieb: > Im VHDL Code ist es noch viel schlimmer. > Da gibt es mehrere Dateien, die zu mehr als 90%, Hier gilt dasselbe wie beim C-Code. > teilweise sogar 100% gleich sind. Ist richtig bei ks3a.vhd und ks3e.vhd für das S3A- und S3E-Board und hat den Grund, dass es die Dokumentation vereinfacht und übersichtlicher macht.
Josef G. schrieb: > Wäre es besser gewesen, ich hätte den gemeinsamen Teil nur einmal > im Download-File gespeichert und würde dann in der Dokumentation > zu den einzelnen Programmen beschreiben, wie man den gemeinsamen > Teil in die einzelnen Dateien hinein-kopieren muss? Nein. C unterstützt Funktionen: http://www.c-howto.de/tutorial/funktionen/
Robert L. schrieb: > hier auch ein schönes beispiel Dann mach doch mal einen Vorschlag, wie du es geschrieben hättest. Ist übrigens ein zeitkritischer Teil des Programms, wo man keine Schleifen gebrauchen kann.
Alexander F. schrieb: > Nein. > C unterstützt Funktionen: http://www.c-howto.de/tutorial/funktionen/ Und wie kriegt man den Code für die gemeinsame Funktion in die drei einzelnen Programme?
Josef G. schrieb: > Alexander F. schrieb: >> Nein. >> C unterstützt Funktionen: http://www.c-howto.de/tutorial/funktionen/ > > Und wie kriegt man den Code für die gemeinsame Funktion > in die drei einzelnen Programme? Du hast eine CPU und einen Emulator geschrieben, weißt aber nicht, wie man das macht? Sehr seltsam...
1 | gcc -c function.c |
2 | gcc -c emul.c |
3 | gcc -o emul emul.o function.o |
Alexander F. schrieb: > weißt aber nicht, wie man das macht? Sehr seltsam... Nein, das wusste ich tatsächlich nicht, und ich verstehe es auch nicht. Und wie sähe nach deinem Vorschlag die Dokumentation aus? Wäre die nicht viel komplizierter als meine Dokumentation? Und der Ablauf für den Anwender wäre auch komplizierter.
Josef G. schrieb: > Robert L. schrieb: >> hier auch ein schönes beispiel > > Dann mach doch mal einen Vorschlag, wie du es geschrieben hättest. > > Ist übrigens ein zeitkritischer Teil des Programms, > wo man keine Schleifen gebrauchen kann. zeitkritisch... ok, lassen wird das mal einfach so stehen... mit einem makro vielleicht.. dass du 8 mal aufrufst der compilierte code wäre 100% der selbe
:
Bearbeitet durch User
@ Le X. (lex_91) >Es geht ja nicht nur um den Code. Das iet ja nur ein Bruchstück des >Problems. >Hier passt halt garnichts: der Code, das VHDL, die Sprache, das Konzept >an sich, die Namen der Register und Befehle, die Doku. >Und allen vorran: die völlige Beratungsresistenz. Alles schon bekannt. Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
Josef G. schrieb: > Wäre es besser gewesen, ich hätte den gemeinsamen Teil nur einmal > im Download-File gespeichert und würde dann in der Dokumentation > zu den einzelnen Programmen beschreiben, wie man den gemeinsamen > Teil in die einzelnen Dateien hinein-kopieren muss? #include "function.c" macht das selbe wie dein copy&past und nein, das ist nicht "super", es beantwortet nur deine Frage..
:
Bearbeitet durch User
Robert L. schrieb: > #include "function.c" Ok, das ginge. Aber auch mit dieser Lösung müsste der Anwender eine zusätzliche Datei ins aktuelle Verzeichnis laden, und man müsste in der Dokumentation darauf hinweisen.
Josef G. schrieb: > Robert L. schrieb: >> #include "function.c" > > Ok, das ginge. Aber auch mit dieser Lösung müsste der > Anwender eine zusätzliche Datei ins aktuelle Verzeichnis > laden, und man müsste in der Dokumentation darauf hinweisen. keine Ahnung was du damit meinst kannst ja #include "../shrd/function.c" machen.. mein "Vorschlag" wäre, wenn überhaupt nur ein TEIL der Lösung, und auch nur exemplarisch..
Wenn DAS die Lösung sein soll, dann hätte ich gerne mein Problem zurück!
Josef G. schrieb: > Ok, das ginge. Aber auch mit dieser Lösung müsste der > Anwender eine zusätzliche Datei ins aktuelle Verzeichnis > laden, und man müsste in der Dokumentation darauf hinweisen. Wie konnte sich dann z.B. Linux durchsetzen, bei dem alleine der Kernel schon aus etlichen tausend Dateien besteht? Deine Argumentation ist vollkommener Unfug und eigentlich nur der Tatsache geschuldet, dass Du bis vor wenigen Tagen der Überzeugung warst, man müsse an sämtliche Dateinamen noch ein ".txt" anhängen, und der Verbreitung von Einzeldateien statt z.B. kompletter ZIP- oder tar-Archive, in denen sich der gesamte Projektbaum einschließlich Buildskripten, Makefile und Projektdateien der Entwicklungsumgebung(en) befindet. Oder eben gleich die Bereitstellung auf einem Versionskontrollsystem wie z.B. Git oder Subversion. Auch hierfür gibt es Unmengen an freiverfügbaren Diensten, und natürlich kann man auch seinen eigenen Server ins Internet "stellen".
Andreas S. schrieb: > und der Verbreitung von Einzeldateien statt z.B. kompletter ZIP- oder > tar-Archive, in denen sich der gesamte Projektbaum einschließlich > Buildskripten, Makefile und Projektdateien der Entwicklungsumgebung(en) > befindet. Josef scheint ein neues Hobby entdeckt zu haben: den Sprung über den eigenen Schatten. Hier: http://www.bo8h.de/Downloads/ gibts ein zip-Archiv mit vielen *.txt-Dateien, aber auch etlichen, ohne das obligatorische .txt am Ende - er scheint sich also doch noch etwas schwer zu tun, mit der neuen Sportart. Vollends grotesk ist der Teilbaum __MACOSX: dort sind die *.txt-Dateien in einem Format abgespeichert, das mit "plain ASCII" herzlich wenig zu tun hat. Z.B. verweigert der Linux-Editor Pluma das Öffnen dieser Dateien von vorn herein, weil ungültige Zeichen drin stehen. Zusammenfassend kann man wohl sagen, dass Josef auf dem Weg ist, das Konzept der Dateiendung zu begreifen. Man sieht an dem zip-Verzeichnis ganz deutlich, wie er noch immer mit sich ringt... Aber egal, er hat ja erst mal ein ganz fundamentales Problem zu lösen: Josef, du musst einfach mehr Anlauf nehmen - Überlichtgeschwindigkeit muss man schon haben, wenn man den Schatten überwinden will, ohne über den Schatten der eigenen Beine zu stolpern.
Uhu U. schrieb: > Vollends grotesk ist der Teilbaum __MACOSX: Das Verzeichnis ist offenbar ein Artefakt des Kompressions- Verfahrens, ich weiss nicht wo das herkommt. Das originale Verzeichnis bo8h-2018-04-22 enthält die Datei version.txt und die Unterverzeichnisse info, soft, vhdl, und sonst nichts. Daraus habe ich auf meinem Apple die zip-Datei erstellt. Wenn ich die zip-Datei auf meinem Apple entpacke, erhalte ich wieder das Original-Verzeichnis. Wenn ich die zip-Datei auf meinem Linux-PC entpacke, finde ich auch dieses merkwürdige __MACOSX -Verzeichnis. Ich habe es auf meinem Linux-PC einfach gelöscht, und alles scheint dann normal zu funktionieren.
Aber anscheinend haben ja auch andere Leute hier die zip-Datei auf ihrem Rechner entpackt. Merkwürdig, dass niemand sonst von diesem merkwürdigen __MACOSX -Verzeichnis berichtet hat.
Josef G. schrieb: > Aber anscheinend haben ja auch andere Leute hier die zip-Datei > auf ihrem Rechner entpackt. Merkwürdig, dass niemand sonst von > diesem merkwürdigen __MACOSX -Verzeichnis berichtet hat. Ich bin mir ziemlich sicher, dass fast jeder dieses Verzeichnis gesehen hat. Es ist einfach nur das kleinste Problem bei deinem Projekt, also hat es niemand erwähnt. Das Verzeichnis enthält irgendwelche Metadaten und kann problemlos entfernt werden: https://stackoverflow.com/a/13665552
__MACOSX enthält jede ZIP Datei die auf einem iMac erstellt wurde google liefert dazu fast 1000000 Einträge..
Danke für die Info. Habe schon befürchtet, ich hätte ein Virus verbreitet.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.