Hi alle zusammen, Ich hab angefangen einen eigenen Computer aus einem w65c816 gebaut, der hat so eine Möglichkeit zwischen Programm und Datenzugriff zu unterscheiden. Damit hab ich schon einen normalen computer gebaut und baue grad einen der so eine Art pseudo Harvard macht. Ich würde als nächstes aber gerne einen Computer mit einer echten harvard Architektur bauen. Kennt ihr einen Chip den ich verwenden könnte? Am liebsten sogar einen der bis heute neu zu kaufen ist. Ich meine auch wirklich Mikroprozessor, also ohne RAM und ROM. Über gpios können wir reden.. Vielen Dank schon mal Stefan
:
Bearbeitet durch User
Stefan S. schrieb: > Kennt ihr einen Chip den ich verwenden könnte? Am liebsten sogar einen > der bis heute neu zu kaufen ist. Nimm einen FPGA. Da kannst du dir den gewünschten µP selber schnitzen.
Deutlich nach dem Harvard Mark I hat eine Harvard Architektur im Sinn einer Adressraumtrennung eigentlich nur im Kontext von Mikrocontrollern überhaupt einen Sinn.
Marek N. schrieb: > 8051 ist Harvard. Und ist als EFM8 Serie von Silabs auch als relativ neuer Chip zu haben. Das ist aber eine ziemlich kranke mehrfach Havard Architektur. Ein anderes Beispiel wäre AVR (wie z.B. in vielen Arduino).
Er will es aber ohne ROM und ohne RAM. Ohne ROM gibt's immerhin den 8031, auch wenn wohl nur abgeschaltet. Aber ohne RAM?
Es gab allerdings wirklich einen Mikroprozessor mit m.W. getrennt rausgeführten Bussen: Motorola 88100. Dürfte aber selbst in Museen selten sein.
Also will einen 8-bit retro computer bauen. Ich schau mir 8051 und efm8 mal an. Sollte ich keinen geeigneten Chip finden, überlege ich einen fpga zu nehmen und ihn mit einem risc-v Basis Befehls Satz auszustatten, damit es einen ordentlichen Compiler gibt. Ich lass den thread aber noch ein bisschen offen für Rückfragen oder weiteren Vorschlägen
Stefan S. schrieb: > damit es einen ordentlichen Compiler gibt Retro mit modernem Compiler, ist das kein Stilbruch?
(prx) A. K. schrieb: > Motorola 88100. Darauf habe ich vor 30 Jahren mit Unix angefangen: DG/UX, Data General AViiON. Aber ich geb' dir recht: scheint selbst museal nicht mehr groß zu existieren. Der Compiler hatte übrigens einen "Silicon filter": damit wurden die Hardware-Bugs des m88k im generierten Assemblercode manuell umschifft. :-o
Stefan S. schrieb: > Kennt ihr einen Chip den ich verwenden könnte? Ein FPGA. Ein Mikroprozessor in echter Harvard-Architektur hat das Problem, simultan Zugriffe auf den ganzen Programmspeicher und den ganzen Datenspeicher ausführen zu können. Wenn diese Speicher extern sein sollen, wie du es vor hast, dann benötigt man den Programmspeicheradressbus, sagen wir 16 Leitungen denn Programmbefehlsbus, sagen wir 16 Leitungen, den Datenadressbus, sagen wir 16 Datenleitungen und den Datenbus, du wolltest 8 bit, also 56 plus ein paar Steuerleungen, somit 60 pins. Das war zu viel, so viele Pins haben nur FPGA, und in den programmierst du dir dann einen Prozessor nach einem Wunsch rein. So versteht man auch gleich, wie Prozessoren funktionieren und warum Harvard Scheisse ist. Genau so beliebt ist die Entscheidung nach eigenem I/O Bus oder memory mapped I/O. Interessant wird die Architektur bei einer Stack-Maschine, die relativ zu TopOfStack und relativ zu Displayregistern addressieren kann. Lernst du dann auch gleich.mit.
Stefan S. schrieb: > Sollte ich keinen geeigneten Chip finden, überlege ich einen fpga zu > nehmen und ihn mit einem risc-v Basis Befehls Satz auszustatten, Ich hoffe, dir ist klar, dass ein RISC-V keine Harvard-Architektur ist.
Natürlich, aber ich will ja auch nur den Befehls Satz benutzen und nicht die Architektur... Ich will dass die Befehle möglichst gleich kodiert sind. Hab aber nur risc-v geschrieben, Weill mir keine andere Architektur bekannt ist, die gut dokumentiert und für die halbwegs aktuelle kompiler existieren.
S. R. schrieb: > dass ein RISC-V keine Harvard-Architektur ist. Getrennte Busse für I und D kann man aber auch bei gemeinsamem Adressraum implementieren. Der ARM9 Core des STR9 hat gleich 3 Busse zum Rest vom Chip. Ist halt wieder die Frage, woran man Harvard festmacht. An den Bussen oder den Adressräumen.
Für mich ist es hauptsächlich die Trennung der Busse. Ich weiß, dass ich darauf keinen Einfluss habe, aber meine Hoffnung ist, dass man mit getrennten Bussen für I und D leichter pipelining machen kann. Ich hoffe trotzdem dass es vielleicht ein wenig schneller sein kann. Mein großes Endziel ist eine komplett eigene Architektur, die auf einem Cpld oder fpga ausgeführt ist. Deswegen möchte ich erst einmal Erfahrung mit verschiedenen alten Architekturen sammeln. Ich würde da als experiment gerne die Einfachheit der alten computer mit den modernen Techniken verbinden. Mit der 6502 Architektur hab ich jetzt länger gespielt. Ich würde jetzt noch andere Architekturen ausprobieren. Mit dem w65c816 Bau ich gerade ein komplexere System das getrennte addressräume für beides besitzt. Da ist halt einiges an glue logic notwendig damit das funktioniert. Dass die avr Controller auch harvard benutzen ist mir entgangen... Wollte grad nur nochmal erklären, was mein Ziel ungefähr ist, weil die Diskussion ansonsten wahrscheinlich irgendwann relativ schnell zu einer Sinn vs Unsinn Diskussion verkommt. Vielen Dank für das produktive feedback
Stefan S. schrieb: > Für mich ist es hauptsächlich die Trennung der Busse. Die mit Abstand konsequenteste Implementierung einer Havard-Architektur mit getrennten Bussen besitzt die SP-50-Familie von Valvo, mit den Ausführungen PCB5010 mit maskenprogrammiertem ROM und PCB5011 mit externem Speicher. Es gibt sogar insgesamt vier verschiedene Adressräume mit getrennten Bussen: 1. Programmspeicher 2. X-RAM 3. Y-RAM 4. Koeffizienten-ROM Die Befehle sind 40 Bit breit und enthalten jeweils einen Bereich für die verschiedenen Einheiten des Prozessors, d.h. ALU, Adresszaehler, usw., ähneln also vom Aufbau der VLIW-Architektur klassischer Cray-Rechner. Dadurch führen sie pro Befehlswort immer sechs Befehle gleichzeitig aus. ALU-Operationen verwenden immer Operanden aus verschiedenen Speichern und somit Adressräumen, so dass man schon ganz genau planen muss, wo man was ablegt. Es gibt keine "Hintertür" wie bei den meisten anderen Harvard-basierten Prozessoren, um auf einen anderen Speicher zuzugreifen. Beispiel:
1 | r := a + b |
2 | s := a + c |
3 | t := b + c |
Dies ist nicht direkt möglich, da man die Variable a, b und c nicht so auf X-RAM und Y-RAM aufteilen kann, dass jeweils eine ALU-Operation auf X und Y zugreift. Folglich muss man eine der Variable erst ins anderen RAM umkopieren. Ich bin mir nicht einmal sicher, ob es solch einen Befehl überhaupt gibt oder ob man statt dessen die Konstante 0 ins Koeffizieten-ROM legen und dann eine Addition (X) + (C) => (Y) durchführen muss. Es gibt zudem überhaupt keine Möglichkeit, Datenzugriffe auf den Programmspeicher durchzuführen, um z.B. ein Programm in den Speicher zu laden. Das muss man ggf. alles außerhalb des Prozessors mit Hilfslogik realisieren. Ich habe vor ewiger Zeit damit begonnen, eine ISA-Einsteckkarte mit einem PCB5011 aufzubauen, bei der der PC (nach Deaktivieren des DSP) Zugriff auf alle vier Adressräume hat. Diese Karte ist leider niemals fertig geworden, aber ich habe es mir fest vorgenommen, das irgendwann in diesem Leben noch zu erledigen. Vielleicht sollte ich irgendwann einmal ganz vorsichtig mit dem Einlesen bzw. Umkopieren der Disketten für den Assembler beginnen. Übrigens eignen sich "normale" Programmiersprachen wie z.B. C nicht besonders gut für die Arbeit mit solchen strikt adressraumgetrennten Prozessoren, da es keine Ausdrucksmöglichkeiten für Adressräume gibt, z.B. in Form von Speicherklassen. Auch bei Pointern müsste man sich irgendwelche Tricks überlegen, um zu kennzeichnen, auf welchen Adressraum sie sich beziehen sollen. Ansonsten müsste man viel zu viel dem Compiler überlassen. Es gibt auch noch (mindestens) eine weitere DSP-Architektur, die ähnlich konsequent realisiert ist, nämlich Motorola DSP5600x. Hierfür sollte man auch noch wesentlich mehr Literatur, Software und auch Bauelemente finden. PS: Wie sich vielleicht schon herumgesprochen hat, konnte sich die SP-50-Familie nicht wirklich auf dem Markt durchsetzen. KORREKTUR: Ich habe gerade noch ein Paper gefunden, in dem unter anderem die Architektur des PCB5010 dargestellt ist, d.h. der Version mit Masken-ROM und internen RAMs. Man sieht, dass alle drei Speicher wahlweise über den X-Bus oder Y-Bus erreicht werden können, wodurch vermutlich die obigen Rechenoperationen doch ohne Umkopieren möglich sind. Beim PCB5011 bin ich mir aber sehr sicher, dass die dort nur extern verfügbaren RAMs fest an die jeweiligen Busse (X-Bus, Y-Bus) angeschlossen sind. Wie es mit dem externen Koeffizienten-ROM (im Blockschaltbild als "DATA ROM" bezeichnet) aussieht, weiß ich aber nicht. http://jjschmid.de/jjschmid-background.pdf
:
Bearbeitet durch User
Motorola DSP 560xx. Ähnelt der SP-50 Familie, ebenfalls mit X und Y-RAM. Für Signalverarbeitung OK. Alles andere erfordert(e) Verrenkungen mit dauerndem umkopieren zwischen den RAM Bereichen.
MaWin schrieb: > Wenn diese Speicher extern sein sollen, wie du es vor hast, dann > benötigt man den Programmspeicheradressbus, sagen wir 16 Leitungen denn > Programmbefehlsbus, sagen wir 16 Leitungen, den Datenadressbus, sagen > wir 16 Datenleitungen und den Datenbus, du wolltest 8 bit, also 56 plus > ein paar Steuerleungen, somit 60 pins Dann guck dir mal die alten Prozessoren an. Um die Zahl der Leitungen zu reduzieren wurde da teilweise gemultiplext. Und 16 (externe) Datenleitungen hatte lange nicht jeder. Der 6502/6510 bspw. mit seinen 8 Bit Daten kam bei 64k Adressraum mit 40 Pins aus und brauchte dann auch kein Multiplexing. http://archive.6502.org/datasheets/rockwell_r650x_r651x.pdf
Wolfgang schrieb: > Um die Zahl der Leitungen zu reduzieren wurde da teilweise gemultiplext. Das widerspricht ja nun aber komplett dem Ziel, durch Trennung der Busse möglichst schnell und einfach zu werden.
Wolfgang schrieb: > Der 6502/6510 bspw. mit seinen 8 Bit Daten kam bei 64k Adressraum mit 40 > Pins aus und brauchte dann auch kein Multiplexing. Harvard macht man nur um schnell zu sein, wobei Speicherzugriff die Langsamkeit bestimmt. Multplexing ist langsam. Wer Programm und Datenzugriffe multiplext, kann gleich die bessere vonNeumann Architektur nehmen.
Du scheinst gerne selbst Dinge herauszufinden. Kennst Du das Buch "The Elements of Computing Systems -- Building a Modern Computer from First Principles" von Noam Nisan und Shimon Schocken? Dort wird anhand eines recht simplen Systems der gesamte Entwicklungspfad gezeigt. Von Gatter-Ebene bis zum Betriebssystem. Und es wird nichts ausgelassen, auch wenn der Prozessor eher simpel ist. Das Buch ist nix für Leute, die eine tu-das-dann-das-und-frag-nicht Anleitung suchen, aber vielleicht findest Du dort eine Inspiration, wie man tatsächlich ein ganz eigenes System erstellen kann und am Schluss jeden Aspekt verstanden hat. Grüße, Stefan
(prx) A. K. schrieb: >> dass ein RISC-V keine Harvard-Architektur ist. > Getrennte Busse für I und D kann man aber auch bei gemeinsamem > Adressraum implementieren. Stimmt, aber dann ist es für den Programmierer ja wieder ein von Neumann-Modell. Für die Wahre Schottische, äh, Harvard-Erfahrung braucht man aber auch getrennte Befehlssätze für die einzelnen Busse und das bietet der RISC-V-Befehlssatz nicht. ;-) Das von Neumann-Programmiermodell hat sich durchgesetzt. Ob der Prozessor jetzt Harvard, von Neumann oder eine Hybridmischung macht, spielt für den Programmierer so gut wie keine Rolle - und so verhalten sich auch moderne Programmiersprachen bzw. Compiler. Stefan S. schrieb: > Ich hoffe trotzdem dass es vielleicht ein wenig schneller sein kann. Du kannst dir ja modernere Ansätze der Mikroarchitekturen anschauen, z.B. Instruction Fusion. Mit einem CPLD wird das aber vermutlich alles nichts.
(prx) A. K. schrieb: > Deutlich nach dem Harvard Mark I hat eine Harvard Architektur im Sinn > einer Adressraumtrennung eigentlich nur im Kontext von Mikrocontrollern > überhaupt einen Sinn. Nein, so kann man das nicht stehen lassen. Gab dazu vor paar Tagen auf Heise einen Artikel warum die Harvard Architektur durchaus sinnvoll ist. Nur, ich finde ihn nicht mehr. :-((( Also, es ging darum, dass Google und Amazon mit ihren Cloud-Servern langsam die Hosen voll bekommt vor Angriffen. Die Harvard-Architektur ist deutlich sicherer vor Angriffen von aussen auf den Programmcode. Bei der ganzen Sache beteiligt sich auch IBM. Es wurden paar Prozessoren genannt, aber die hab ich vergessen ...
Nick M. schrieb: > Die Harvard-Architektur ist deutlich sicherer vor Angriffen von aussen > auf den Programmcode Sicher, noch sicherer ist Programmcode im ROM. Aber modifizierter Code ist nur 1 Schwachstelle von vielen. Um Daten abzugreifen z.B. Zugangskennwörter, muss man nicht immer Trojanercode installieren. Oft reicht es auch einfach den vorhandenen Code mit manipulierten Anfrageparametern aufzurufen. So im Sinne von Enter Search: findetnix "; SELECT * FROM Passwords ; "
S. R. schrieb: > Mit einem CPLD wird das aber vermutlich alles nichts. Aus meinem Verständnis heraus ist ein cpld mehr oder weniger fast das gleiche wie ein fpga nur ohne features wie eigener RAM, ad Wandler, etc. Auch wenn der größte fpga vllt größer ist als der größte cpld, sind die cplds uaf jeden fall groß genug um eine 8 bit soft CPU zu beinhalten und noch ein bisschen platz zu haben. S_Hennig schrieb: > Kennst Du das Buch "The Elements of Computing Systems -- Building a > Modern Computer from First Principles" von Noam Nisan und Shimon > Schocken? Nope, kannte ich bisher nicht, steht aber jetzt auf meiner Amazon Wunschliste. Nick M. schrieb: > Also, es ging darum, dass Google und Amazon mit ihren Cloud-Servern > langsam die Hosen voll bekommt vor Angriffen. Die Harvard-Architektur > ist deutlich sicherer vor Angriffen von aussen auf den Programmcode. Bei > der ganzen Sache beteiligt sich auch IBM. Es wurden paar Prozessoren > genannt, aber die hab ich vergessen ... Ging es vllt um IBMs power architektur? Oder war das noch was anderes?
Stefan S. schrieb: > Ging es vllt um IBMs power architektur? Oder war das noch was anderes? PowerPC wurde auch genannt. Sorry, ich find den Artikel nicht. Hab eine 1/2 Stunde gesucht.
Stefan S. schrieb: > Aus meinem Verständnis heraus ist ein cpld mehr oder weniger fast das > gleiche wie ein fpga Nö. Ein CPLD sind mehrere GALs in einem Gehäuse. Es ist also nicht ein 2-dimensionales Array von FlipFlops "Macricells" über den ganzen Chip mit nur ein paar I/O am Rand sondern ein 1-dimensionales Array von FlipFlops "Registern" entlang der Aussenpinreihe wahrend auf der Chipfläche nur eine AND/OR Matrix liegt. Viel weniger Speicher. Viel weniger Fähigkeit.
Beitrag #6458860 wurde von einem Moderator gelöscht.
Beitrag #6458888 wurde von einem Moderator gelöscht.
MaWin schrieb: > ein 1-dimensionales Array von FlipFlops "Registern" entlang der > Aussenpinreihe Manfred, ich glaube, dein Wissen aus dem vorigen Jahrtausend darfst du mal auffrischen: https://www.xilinx.com/publications/products/cpld/coolrunnerii-product-brief.pdf Wie du 512 Makrozellen nur an der „Außenpinreihe“ (wo ist die eigentlich bei einem BGA?) platzierst, wäre eine interessante Frage. Allerdings: die Ressourcen der größten CPLDs sind etwa im gleichen Bereich wie die der kleinsten FPGAs. Es ist also keineswegs nur so, dass nur die „größten FPGAs“ da deutlich mehr zu bieten hätten, wie Stefan oben postulierte. Ich würde jedenfalls für CPU-Experimente selbst kein CPLD nehmen wollen sondern ein FPGA. Aber das muss er selbst wissen. Für den Preis so eines 512er CoolRunner-II-ICs (60 Euro) bekommt man jedenfalls schon problemlos ein komplettes FPGA-Entwicklungsboard.
>Es gibt auch noch (mindestens) eine weitere DSP-Architektur, die ähnlich >konsequent realisiert ist, Das typische an DSP ist ja, dass er mehrere Busse hat (mehr als typ. Harvard) >>Um die Zahl der Leitungen zu reduzieren wurde da teilweise gemultiplext. >Das widerspricht ja nun aber komplett dem Ziel, durch Trennung der Busse >möglichst schnell und einfach zu werden. Mehrere Busse in MUX-Betrieb sind zwar langsamer als das gleiche mit NonMUX, jedoch können erstgenannte weitaus schneller sein, als alles über nur einen Bus (VonNeumann) mit NonMUX zu übertragen. Denn in gleiche Richtung laufende Werte (Bytes, Worte usw, innerhalb von Instrukt bzw. Daten), lassen sich schneller multiplexen als man Werte von Instrukt. und! Daten zusammen über nur einen Bus (VonNeumann) übertragen kann.
CPLDs wären mit ihren breiten EingangsMatrix und den breiten VerbindungsStrukturen prinzipiell besser geeignet als FPGAs, wenn sie genug MCs hätten.
Ingo E. schrieb: > Motorola DSP 560xx. Ähnelt der SP-50 Familie, ebenfalls mit X und Y-RAM. > Für Signalverarbeitung OK. Alles andere erfordert(e) Verrenkungen mit > dauerndem umkopieren zwischen den RAM Bereichen. Es wurde schon alles gesagt, aber bloß nicht von jedem. Ich hatte bereits auf diese Familie hingewiesen: Andreas S. schrieb: > Es gibt auch noch (mindestens) eine weitere DSP-Architektur, die ähnlich > konsequent realisiert ist, nämlich Motorola DSP5600x. Hierfür sollte man > auch noch wesentlich mehr Literatur, Software und auch Bauelemente > finden.
MCUA schrieb: > CPLDs wären mit ihren breiten EingangsMatrix und den breiten > VerbindungsStrukturen prinzipiell besser geeignet als FPGAs, wenn sie > genug MCs hätten. Das war auch Mein letzter Stand. Ich hab mich nur nicht getraut das explizit zu behaupten. Und zum Thema Preis von oben: Ich habe ein Board das kostet 10€ incl. Versand mit einem cpld von altera. Da kasst der core von einem w65c816 rein und es ist noch über die Hälfte Platz (laut der ide von altera). Ich hab geschaut nach vergleichbaren fpgas und die billigsten Boards die zu meinem cpld ungefähr equivalent waren, waren cyclone 3 boards für 30€... Ich glaube da ist mehr als genug Platz für das was ich machen will. Nick M. schrieb: > PowerPC wurde auch genannt. Kann auch sein. Die Frage ist nur, obs da kleine PowerPC CPUs zu kaufen gibt. MaWin schrieb: > Viel weniger Speicher. Viel weniger Fähigkeit. Ich brauche nur die Funktionalität einer logischen Schaltung. Dafür sind cplds völlig ausreichend. Für den selbstgebauten video chip werd ich einen fpga benutzen, da ich keine andere billige Möglichkeit kenne dual port RAM an so einen Chip anzubinden. Jörg W. schrieb: > Das widerspricht ja nun aber komplett dem Ziel, durch Trennung der Busse > möglichst schnell und einfach zu werden. Da gibt es einen Prozess namens pipelinig. Der wird durch einen Bus für program viel einfacher, da kein Datenzugriff dein Laden der nächsten Anweisung blockiert. Ich will nicht weiter über die vielleicht Einsatz findenden Technologien diskutieren, denn ich bin nicht mal mit dem alten Projekt fertig. Vielleicht stellt sich in der Implementatierung vom Projekt raus, dass ein cpld nicht mehr wirtschaftlich ist und ich nehme dann am Ende doch einen fpga. Das schau ich aber dann. Außerdem ist das was ich machen will ja nur ein Experiment. Ich will versuchen was zu bauen das von außen möglichst aussieht wie ein 8 bit System aus den 80ern aber intern features hat die niemals eine Alte Architektur hatte. Ich ich will nach und nach auch einen eigenen optimierenden Compiler für meine Architektur bauen und ein eigenes Multitasking OS bauen. Ich hoffe die großen Kritiker bemerken, dass das nur ein verrücktes pet Projekt ist, wo es drum geht Spaß zu haben und nicht die beste neue Architektur zu bauen. Und schon wieder vielen Dank an alle interessanten Denkanstöße und Hinweise von allen. Und natürlich auch vielen Dank an alle kritischen Stimmen.
>Ich habe ein Board das kostet 10€ incl. Versand mit einem cpld von >altera. Da kasst der core von einem w65c816 rein und es ist noch über >die Hälfte Platz Das wird ein FPGA nicht PLD sein.
>Ich brauche nur die Funktionalität einer logischen Schaltung.
Dann nimm 7400.
Stefan S. schrieb: > Außerdem ist das was ich machen will ja nur ein Experiment. Ich will > versuchen was zu bauen das von außen möglichst aussieht wie ein 8 bit > System aus den 80ern aber intern features hat die niemals eine Alte > Architektur hatte. Solche Ideen hab ich auch manchmal beim EInschlafen. Ein 6502 @ 100 MHz mit Caching. :-))
Nick M. schrieb: > Also, es ging darum, dass Google und Amazon mit ihren Cloud-Servern > langsam die Hosen voll bekommt vor Angriffen. Die Harvard-Architektur > ist deutlich sicherer vor Angriffen von aussen auf den Programmcode. Bei > der ganzen Sache beteiligt sich auch IBM. Es wurden paar Prozessoren > genannt, aber die hab ich vergessen ... gings da um Graviton2 oder was aktuelleres?
GeGe schrieb: > gings da um Graviton2 oder was aktuelleres? Ging sicheerlich um Aktuelles. Bitte fragt mich nicht. Ich hab den Artikel nur gelesen um die Begründung zu finden. Und ich musste dann sehr hämisch lachen.
Nick M. schrieb: > Die Harvard-Architektur > ist deutlich sicherer vor Angriffen von aussen auf den Programmcode. Wenn die MMU zwischen Daten und Code unterscheidet, Code nicht schreibt und Daten nicht ausführt, dann ist die Situation sicherheitstechnisch ähnlich Harvard. So geschehen mit dem NX Bit, das zum "return oriented programming" führte. Und dagegen hilft Harvard nicht.
(prx) A. K. schrieb: > So geschehen mit dem NX Bit, das zum "return oriented > programming" führte. Und dagegen hilft Harvard nicht. Der Stack ist nicht im Code-Adressraum. Daher kann da auch nichts ausgeführt werden.
Nick M. schrieb: >> So geschehen mit dem NX Bit, das zum "return oriented >> programming" führte. Und dagegen hilft Harvard nicht. > > Der Stack ist nicht im Code-Adressraum. Daher kann da auch nichts > ausgeführt werden. Erst nachgucken was das ist, dann kommentieren.
Selbst in quarts steht cpld. Dann sollten wir uns mal bei altera beschweren.
(prx) A. K. schrieb: > Erst nachgucken was das ist, Und, was nütz das? Ist das ein von dir eingeschleuster Code? Nein. Und wie kannst du auf den Stack zugreifen, ohne deinen eigenen Code einzuschleusen? Erst nachdenken, dann kommentieren.
Diese Unterscheidung gab es übrigens schon früher. Intels Segmentierung ab 286 unterschied zwischen Code- und Datensegmenten. Und Telefunkens Grossrechner TR-440 von 1969 markierte Speicherworte mit 2 Bits Typenkennung, einer davon für Befehle, weshalb für jeden, der jemals was damit zu tun hatte, der Typenkennungsalarm ein Begriff ist.
Nick M. schrieb: > Und, was nütz das? Ist das ein von dir eingeschleuster Code? Nein. > Und wie kannst du auf den Stack zugreifen, ohne deinen eigenen Code > einzuschleusen? Du schleust damit nur Zeiger auf bestehenden Code ein, keinen eigenen Code. Auf den Stack kann man zugreifen, weil der in Programmiersprachen wie C ein Mix aus Daten und Returnadressen ist. Ein Bufferoverflow erwischt damit die Returnadresse. Das ist bloss etwas umständlich. Weniger gut funktioniert das in Sprachumgebungen, die keine Daten im Stack adressieren. Wie etwa in klassischem Fortran.
:
Bearbeitet durch User
> Die Harvard-Architektur ist deutlich sicherer vor Angriffen von aussen > auf den Programmcode prinzipiell ist das sicherer, weil schon vom Bus her getrennt. Meist gibt es aber auch da Wege, Daten irgentwie nach Instruktion zu transferieren. 100% sicher wird wohl nichts zu machen sein. Man kriegt diese Bits immer irgentwie zu Instruktion.
MCUA schrieb: > Man kriegt diese Bits immer irgentwie zu Instruktion. Jo, aber wenn im Befehlsspeicher nur Masken-ROM ist, musst du schon den Chiphersteller bemühen, deinen Code dort unterzubringen. ;-) Und wenn das Teil dann auch noch einen separaten Hardware-Stack für Returnadressen hat, dann wirds auch schwierig, diese zu manipulieren.
:
Bearbeitet durch User
Masken-ROM wäre wohl das relativ am sichersten. aber auch das nicht mit 100%. Man kann u.U. dieses ROM umgehen und liest diese Daten von sonst wo her.
(prx) A. K. schrieb: > Auf den Stack kann man zugreifen, weil der in Programmiersprachen > wie C ein Mix aus Daten und Returnadressen ist. Ein Bufferoverflow > erwischt damit die Returnadresse. Das ist bloss etwas umständlich. Und wer legt fest, dass das so sein muss? Du, damit dein Beispiel funktioniert? Oder IBM, damit die sichere Prozessorarchitekt dir zuliebe unsicher wird?
MCUA schrieb: > Masken-ROM wäre wohl das relativ am sichersten. > aber auch das nicht mit 100%. > Man kann u.U. dieses ROM umgehen und liest diese Daten von sonst wo her. Nö, nicht bei Prozessoren, die keinen anderen Speicher für Programmcode kennen. Auch bei den o.a. DSP gibt es prinzipbedingt keine Hintertür für anderen Programmcode. Und da es auch gar keine Write-Enable-Leitung o.ä. für den Programmbus gibt, kann es auch keine Schreibzugriffe geben. Somit genügen auch normale EPROMs bzw. Flash-Bausteine, die extern programmiert werden.
Stefan S. schrieb: > Ich habe ein Board das kostet 10€ incl. Versand mit einem cpld von > altera. Hört sich interessant an, wie heißt es und wo gibt es die Wunderwaffe?!
Darf ich mich mal einschalten? Ich hab zu Harvard immer die Vorstellung zwei Stacks zu haben. Einen return stack und einen data stack. Damit wäre rop auch ausgeschlossen. Bei meinem Projekt soll es aber nicht primär um Sicherheit gehen, sondern eher um Performance. Ich finde es aber sehr interessant dass die Diskussion grad wieder total am abdriften ist. Ich mach mir aber fleißig Notizen 😊. Ich hab übrigens mit Unterstützung von einem makro Assembler und dem 65816 schon einen getrennten Daten und Programm stack gebaut. Wie ich das mache passt hier aber grad nicht ganz rein.
MCUA schrieb: > 100% sicher wird wohl nichts zu machen sein. > Man kriegt diese Bits immer irgentwie zu Instruktion. Hast Du Dir überhaupt mal die SP-50- und DSP56k-Architekturen angeschaut? Ohne externe Verbindung zwischen den Bussen ist da nix mit Hintertürchen. Der ganz große Nachteil besteht dann aber auch darin, dass man ohne externe Mittel kein Firmwareupdate durchführen oder Softwareteile nachladen kann.
Stefan S. schrieb: > Bei meinem Projekt soll es aber nicht primär um Sicherheit gehen, > sondern eher um Performance. Dann solltest Du lieber ein hochintegriertes SoC mit internem SRAM einsetzen. Mit einem FPGA-Anteil dazu kann man auch tolle Rechenbeschleuniger und Wunderperipherie realisieren. Beispiel: Xilinx Zynq 7000, MPSoC, RFSoC.
MCUA schrieb: > ..was ein FPGA ist. Ist es nicht. Beweis folgt: https://www.intel.de/content/www/de/de/products/programmable/cpld/max-ii.html
Das ist ein billiges Board mit einem altera Max II. Ich hab dir mal einen random link von ebay raus gesucht. https://www.ebay.de/itm/133514948782
Andreas S. schrieb: > Dann solltest Du lieber ein hochintegriertes SoC mit internem SRAM > einsetzen. Damit kann ich dann aber keinen diskreten computer mehr bauen. Mein Limit sind eh wenige Megahertz. Nach wie vor wird wahrscheinlich fast jeder arduino schneller sein als dieser computer. Ich will trotzdem schauen, was ich aus einer alten Architektur bzw einer selbst gebauten minimalistischen Architektur noch rausholen kann. Deswegen auch meine liebe zum w65c816. Das Teil gibt einem alle möglichen Informationen die es ermöglichen außergewöhnliche Dinge zu tun, wenn man den original 6502 im Hinterkopf behält. Das Design was ich grade entwerfen und baue hat nicht nur 1M Adress Raum, sondern auch sondern sogar das doppelte. (64k *256. Mit Unterscheidung zwischen Daten und Code.) Es läuft mit einer Art pseudo Havard, damit ich in der Zeit wo der Prozessor Anweisungen liest kann der Rest vom System dma machen. Ich hab meine glue logic in einem cpld, das es ermöglicht über einen in Rom vorliegenden kleinen bootloader verschiedene Programme zu laden... In Sachen Performance werd ich zwar nicht mehgr viel reißen können, aber ich mach das ja wegen dem Spaß....
Stefan S. schrieb: > Damit kann ich dann aber keinen diskreten computer mehr bauen. Wenn der Computer wirklich diskret werden soll, dann nimm einen 74LS181 als Basis, 74LS95A als Register. So eine Idee hatte ich vor Jahrzehnten, daher extra dazumals einen 74181 gekauft, Projekt ist aber nie geworden …
:
Bearbeitet durch Moderator
Stefan S. schrieb: > Das Design was ich grade entwerfen und baue hat nicht nur 1M Adress > Raum, sondern auch sondern sogar das doppelte. (64k *256. Mit > Unterscheidung zwischen Daten und Code.) Wenn Du scharf auf Bankumschaltung und eine möglichst altertümliche und leicht verkorkste Architektur bist, dann wäre doch sicherlich bo8 das richtige für Dich. Dort wird ja auch sehr viel auf Steckkarten realisiert, was man eigentlich auch gleich mit ins FPGA integrieren könnte.
:
Bearbeitet durch User
Jörg W. schrieb: > Wenn der Computer wirklich diskret werden soll, dann nimm einen > 74LS181 als Basis, 74LS95A als Register. Oder gleich Am290x. Damit könnte man sich z.B. auch einen zur DEC PDP-11/34 oder Siemens R10VH kompatiblen Prozessor bauen. Leider habe ich vor etlichen Jahren meine Kuchenbleche voll mit Am290x entsorgt. :-(((
Ganz so diskret sollte es doch nicht sein. Ich wollte halt gerne ein paar schwarze Käfer haben.
Stefan S. schrieb: > Ich wollte halt gerne ein paar schwarze Käfer haben. Dann drapiere die doch um ein FPGA rundrum, und hänge ein paar Blinkenlights mit dran. ;-) Sorry, nicht ernst gemeint. Ich würde sowas heutzutage wohl wirklich komplett in einem FPGA realisieren. Habe vor Kurzem mal als VHDL-Übung meine alte Bildschirmsteuerung (Erzeugung des BAS-Signals für Fernseher), die ich vor 35 Jahren in Hardware genagelt hatte, aufgebaut.
Willst du sowas wie eine PDP 8? Da gibt es ein schönes Buch dazu.
Stefan S. schrieb: > Ich wollte halt gerne ein paar schwarze Käfer haben. Die Bausteine der Am290x-Familie gibt es nicht nur im grauen Keramikgehäuse, sondern auch im schwarzen Kunststoffgehäuse. Auch beim 74181 waren schwarze Kunststoffgehäuse sehr gebräuchlich. Abgesehen davon finde ich die Vielzahl an keramischen Gehäuse sogar viel spannender; insbesondere die Ausführungen mit vergoldetem, aufgelöteten Deckel machen doch richtig etwas her, insbesondere auch als EPROM.
:
Bearbeitet durch User
Ich kann grad ein paar Worte vhdl und noch weniger verilog. Deshalb will ich keine eigene soft CPU implementieren😅 Für den address decoder schaffe ich das grad so noch. Ich bau wahrscheinlich besser kein komplettes System nach. Mal schauen was ich mach, wenn ich fertig bin.
Jörg W. schrieb: > Wenn der Computer wirklich diskret werden soll, dann nimm einen > 74LS181 als Basis, 74LS95A als Register. > > So eine Idee hatte ich vor Jahrzehnten, daher extra dazumals einen 74181 > gekauft, Projekt ist aber nie geworden … Bau doch den MIPS TTL nach ;)
Stefan S. schrieb: > Deshalb will > ich keine eigene soft CPU implementieren😅 Kennst du das: https://opencores.org/projects?expanded=Processor
..ja genannte Dinge sind rel. sicher, streite ich gar nicht ab! Aber ich behaupte hier, es gibt keine 100%-Sicherheit! (auch nicht bei DSP) Auserdem ist diese Diskuss. pardox: Denn je mehr Möglichkeiten eine CPU hat (wodurch die Leistung ja auch besser wird / was auch bei DSP zutrifft), desto anfälliger (!) das Ganze für Manipulation. Also wozu über sowas paradoxes diskutieren? (Das ist eher 'was' für die Presse) >Wenn der Computer wirklich diskret werden soll, dann nimm einen >74LS181 als Basis, 74LS95A als Register. Diesen Typ ALU ('181 '182) gibt es seit Ende der 60er, viele Firmen haben den benutzt. Als BidirShift kann man auch den '194 nehmen (für kleinen Akku), oder eine von weiteren 10000 Möglichkeiten. Je mehr Register desto besser. >> ..was ein FPGA ist. >Ist es nicht. Beweis folgt: Ist definitiv ein FPGA (sieht man, wenn man rein guggt), auch wenn Altera u. Intel das CPLD genannt haben. >Ganz so diskret sollte es doch nicht sein. Aber jetzt den Rückzieher machen. Und ausserdem nimmt man keine 65xx-CPU als Vorlage!
Jörg W. schrieb: > Wie du 512 Makrozellen nur an der „Außenpinreihe“ (wo ist die eigentlich > bei einem BGA?) platzierst, wäre eine interessante Frage 2 pro Pin. Die bonding Pads sind an diesen IC immer aussen, was dann das Gehäuse macht um die lötbar zu machen hängt halt von der Pinanzahl ab. Nicht ohne Grund findest du in deiner verlinkten Tabelle die CPLD mit steigender Makrozellenanzahl auch nur in Gehäusen mit immer mehr Pins. Das 512er in Gehäuse mit 270 Pins, oder zumindest 170 wenn einige Zellen nicht kontaktiert werden. Der strenge Zusammenhang zwischen Gehäuseanschlussanzahl und Maktozellenanzahl ist typisch für CPLDs. Und zeigt auch, warum die so wenig leistungsfähig sind. Will man eine simple Schaltung, z.B. IIR Filter auf S/P-DIF Audiodatenstrom, braucht man gleich ein riesen-CPLD mit hundert und mehr Pins, von dem man nur 8 als I/O benötigt.
Stefan S. schrieb: >> ..was ein FPGA ist. > > Ist es nicht. Beweis folgt: > https://www.intel.de/content/www/de/de/products/programmable/cpld/max-ii.html Auf der verlinkten Seite gibt es eine FAQ mit dem ersten Eintrag: "What is the MAX II device family?" Da steht: "Altera’s MAX II family of low-cost CPLDs was the first architecture introduced that combines the best of traditional CPLD architectures with Altera's innovative FPGA look-up table (LUT) logic structure. " Es gibt halt Hersteller, die FPGAs mit OnChip Flash für die Konfiguration als CPLD vermarkten. Das man keinen externen Konfigurationsspeicher bei CPLD brauchte war wohl das was sie als "the best of traditional CPLD architectures" betrachten.
>Und zeigt auch, warum die so wenig leistungsfähig sind. Es kommt auf die Anwendung an. Bei breiten Eingangsstrukturen reicht bei PLD evtl. 1 PT aus zur Codierung, bei FPGA müssten mehr. LUTs hintereinander verschaltet werden. LUTs sind vor allem viel billiger (und mitl.weile auch schneller) als MCs, weshalb die in neueren Bausteinen fast nur noch eingesetzt werden. Bei PLDs steigt der Flächenbedarf quadratisch mit der MAC-Anzahl, wegen der Verdrahtung; Deshalb wirds irgentwann unbezahlbar.
Andi schrieb: > Stefan S. schrieb: >>> ..was ein FPGA ist. >> >> Ist es nicht. Beweis folgt: >> https://www.intel.de/content/www/de/de/products/programmable/cpld/max-ii.html > > Auf der verlinkten Seite gibt es eine FAQ mit dem ersten Eintrag: "What > is the MAX II device family?" > Da steht: > "Altera’s MAX II family of low-cost CPLDs was the first architecture > introduced that combines the best of traditional CPLD architectures with > Altera's innovative FPGA look-up table (LUT) logic structure. " > > Es gibt halt Hersteller, die FPGAs mit OnChip Flash für die > Konfiguration als CPLD vermarkten. Das man keinen externen > Konfigurationsspeicher bei CPLD brauchte war wohl das was sie als "the > best of traditional CPLD architectures" betrachten. So weit ich das richtig verstanden habe was im Datenblatt steht ist es ein CPLD mit relativ kleinen makrozellen. Außerdem meint altera die machen da irgendwas damit sie die makrozellen ähnlich einfach herstellen können wie luts. Und wenn selbst im Datenblatt nicht steht, dass es ein fpga ist, wird das wohl auch nicht so sein.
> was im Datenblatt steht ist es ein CPLD mit relativ kleinen makrozellen. Es sind LUTs, keine Makrozellen. Makrozellen haben u.a. viel breitere Eing.-Matrix. Und Altera weiss, dass es ein FPGA ist, auch wenn die es nicht schreiben. MAX5000, MAX7000, XC95.., MACH4000 sind z.B. typ. CPLDs.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.