Thema: Verrückter als wir...?

[nooooooooos]

Joa...dann kriegt wenigstens die Post wieder mal ein bisschen Aufwind^^
Ja aber wenn jemand einfach nur Schaltpläne nachbaut, lernt man nix und Spass machts auch nich...

Aber jetzt backtotopik
Findet ihr einen Stack soo wichtig? Also in meinem OS könnte ich getrost auf ihn verzichten...Oder ist das zwinged für uIP?
Weil wenn ich noch nen Stack mach, dann brauch ich nur für Code + Stack schon 6 Register (wenn ichs mit doppelter Segmentierung mach...), und eben dann wächst der Verkablungsgrad ziemlich an....

[Svenska]

Da kommt mir doch ganz spontan die Idee ... warum machen wir nicht eine eigene LowLevel-CPU

Wenn noch nichtmal das Betriebssystem aus den Anfängen herauskommt mit einer CPU anfangen?
Außerdem braucht man dazu Lötkolben, Ätzmaterial und wasweißichnichtalles - das hat bestimmt nicht jeder interessierte zuhause. Einen Computer zur Softwareentwicklung dagegen schon eher.

Findet ihr einen Stack soo wichtig? Also in meinem OS könnte ich getrost auf ihn verzichten...Oder ist das zwinged für uIP?

uIP lass erstmal aus dem Spiel.
Aber ein Stack ist äußerst elementar, um Funktionen aufrufen zu können oder sogar rekursiv programmieren zu können. Wie willst du denn Funktionen aufrufen, wenn du keine Rücksprungadresse sichern kannst? Ein Stack ist extrem notwendig. Selbst der Intel 4004 (allererster Intel-Prozi) hatte schon einen (wenn auch in Hardware gegossen und ohne Speicherzugriff). Mit dem 8080 wurde der dann durch Register in den Speicher verlegt.

Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.

Weil wenn ich noch nen Stack mach, dann brauch ich nur für Code + Stack schon 6 Register (wenn ichs mit doppelter Segmentierung mach...), und eben dann wächst der Verkablungsgrad ziemlich an....

Lass die Segmentierung aus dem Spiel (was meinst du überhaupt mit doppelter Segmentierung?), die ist einfach zu kompliziert in Hardware zu gießen.
Und ja, Register sind ein zu lösendes Problem in der Beschaltung und vor allem gilt: je mehr, desto besser. Wenn du genug Register hast, kannst du die Hardware mehr Akku-orientiert basteln, wenn nicht, solltest du mehr auf allgemeingültige Register setzen.

Imho ist es besser, zwei oder drei unbenutzte Register zu haben, um Daten zwischenspeichern zu können (d.h. um Speicherzugriffe zu sparen). Es ist aber alles eine Frage des Aufwandes, den man treiben möchte.
Akku-zentriert => einfach zu bauen, weniger Opcodes, komplizierte Programmierung
Allgemein => komplizierter zu bauen, mehr Opcodes, einfache Programmierung

Gruß,
Svenska

[nooooooooos]

Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.

Nöö ich kann Regsiter usw. auch einfach in Variablen sichern...

(was meinst du überhaupt mit doppelter Segmentierung?),

Ja eben früher hatte man ja Segmente und darin Offsets. ( CS:IP )
Ich habe die Idee ein Supersegment noch weiter in Subsegmente einzuteilen und erst dann mit Offsets darin zu arbeiten. ( FS[Firstsegment]:SS[Subsegment]:OF[Offset] = FS:SS:OF)

Ist ja eigentlich wie mit 24bit registern, nur dass ich in der alu mit 8Bit registern rechnen muss... -> Darum find ichs nich so schwierig...

Und ja, Register sind ein zu lösendes Problem...

Das gedenke ich sozulösen, indem ich 8 (3Bit im opcode) verschiedene gleicherechtigte 8bittige Register mache...


Gruss
Nooooooooooooos

[kevin]

Wenn noch nichtmal das Betriebssystem aus den Anfängen herauskommt mit einer CPU anfangen?

Naja, bei LOST merkt man schon, daß kaum einer Interesse hat, mitzumachen, weil jeder schon sein eigenes OS hat. Bei der CPU wäre das jedenfalls momentan vermutlich noch nicht der Fall.

(Bitte nicht falsch verstehen, ich bin trotzdem auch der Meinung, daß nichts draus werden würde...)

[nooooooooos]

Hehe...und wenn wir dann einen Computer hätten....wer kriegt ihn?...Ich wär dafür, dass wir ihn am Dreiländereck zwischen DE, AU + CH im Bodensee versenken...

[kevin]

Australien liegt am Bodensee?

[Termite]

Meinte wohl AT

und mit dem stack. selbst so poplige controler wie PICs haben nen stack, selbst wenn der nur 2 recursionen speichern kann. Wobei solche controller auch nicht in c programiert werden. dazu haben die einfach zu wenig rescourcen.  (pic 10xxx pic 12xxx )

Ich persönlich würde beim CPU Projekt weniger das zusammenbauen als problem sehen. Lötkolben gibts recht günsig im baumakrt. ist dann zwar kein nobel von weller sondern eher ein brateisen mit mit 230v ( daher geringerer strom, darum längere heizzeiten) ginge aber trozdem. lochraster platinen und fädeldrat gibts im versandhaldel oder beim localen dealer um die ecke. Gedruckte platinen wird dann schon schwerer. passende cnc fräs  plotmaschine hat sicher keine. und selber ätzen ist ne riesen sauerei (Fe3Cl)
Platine Bohren ist dann das nächste. 1mm löcher sind schon fast scheunentore und Hartmetal bohrer in ner normalen bohrmaschine kanste vergessen.

beim fehlersuchen wirds dann sicher lustig. signalverläufe mit nem multimeter aufzeichnen. ohne oskar / oder digitalanaliser wird dann sicher lustig und frustrierend.

dann doch lieber spice anwerfen und das ganze nur simuliert laufen lassen. da kann man wenigstens wirklich alles überall abreifen und aufzeichnen. und ne fehlverdrahtung läst sich einfach mal um biegen ohne sich gleich brandblasen hohlen zu müssen. auserdem kann da einem einer schneller helfen. is ja nur ne datei die ausgetauscht werden muss.

mal ne frage. wer von euch hat schon mal
a) nen lötkolben in der hand gehabt.
b) eine gedruckte platine mit bedrahteten bauteilen bestückt
c) einen schaltung auf einer Lochrasterplatine aufgebaut
d) eine gedruckte leiterplatte selber gefertigt
e) eine gedruckte leiterplatte selber entworfen
f) sich auf fehlersuche bei einer selbst aufgebauten schaltung gemacht
g) eine schaltung selber entworfen

gruss

[RedEagle]

a) nen lötkolben in der hand gehabt.
 ICH
b) eine gedruckte platine mit bedrahteten bauteilen bestückt
 Jo, schon 100 mal
c) einen schaltung auf einer Lochrasterplatine aufgebaut
 Jo einmal
d) eine gedruckte leiterplatte selber gefertigt
 Ja, ca. 20 Geätzt (in der tat recht schmutzig); 3 gefräst (Teuer & langsam aber sauber)
e) eine gedruckte leiterplatte selber entworfen
 Jo, ne Digitaluhr (mit nem ATmega32)
f) sich auf fehlersuche bei einer selbst aufgebauten schaltung gemacht
 Jo, mindestens 3 mal die Woche in der schule
g) eine schaltung selber entworfen
 Jo, ne Digitaluhr, und nen paar kleinere Digitale/Analoge schaltungen

Ich muss Termite recht geben. Wer noch nie etwas mit Elektrotechnik zu tun hatte solte da die Finger von lassen. Und wenn man kein Oszilloskop beherscht, kann man die Fehlersuche vergessen.
Und ich bin mir auch sicher, das es bei einer CPU nicht mit dem einfachen verbinden von ein und ausgängen von TTL-ICs getan ist.
Nur wenn jemand weiß, wie eine CPU funktioniert ist er noch lange nicht in der Lage eine selber zu bauen. Da steckt ne menge Handwerkliches geschick hinter.

[Termite]

Ich selber hätte daheim eher das problem woher nen oskar nehmen wen nicht stehlen.

zur not haben wir in der firma ein paar nette rumstehen. und als wheinachtsgeschenk taugt das leider auch nicht, da macht der preis nicht wirklich mit.

gruss

[Svenska]

Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.

Nöö ich kann Regsiter usw. auch einfach in Variablen sichern...

Na dann viel Spaß, wenn du zum Rücksprung aus einer Prozedur erstmal von "irgendwo" aus dem Speicher, wo du selbst nicht weißt, wo (kein Stack), die Rücksprungadresse raussammeln musst...

(was meinst du überhaupt mit doppelter Segmentierung?),

Ja eben früher hatte man ja Segmente und darin Offsets. ( CS:IP )
Ich habe die Idee ein Supersegment noch weiter in Subsegmente einzuteilen und erst dann mit Offsets darin zu arbeiten. ( FS[Firstsegment]:SS[Subsegment]:OF[Offset] = FS:SS:OF)

Man kann sich die Programmierung auch richtig schwer machen...

Ist ja eigentlich wie mit 24bit registern, nur dass ich in der alu mit 8Bit registern rechnen muss... -> Darum find ichs nich so schwierig...

Dann musst du je drei Register zu einem 24-Bit-Register zusammenführen können, um eine absolute Speicheradresse zu bekommen... oder du quälst dich mit deinen Segmentgrößen rum (8 Bit? 256 Byte pro Segment?)

Und ja, Register sind ein zu lösendes Problem...

Das gedenke ich sozulösen, indem ich 8 (3Bit im opcode) verschiedene gleicherechtigte 8bittige Register mache...

Womit wir bei CISC und einer in EPROMs gespeicherten Tabelle gelandet wären - denn in Hardware kannst du vielleicht 20 Opcodes gießen (pro Platine einen), aber nicht pro Befehl 8 Varianten.

Lötkolben gibt's für 4€ im Baumarkt, da geb ich Termite recht (ich hab meinen für 3,95€ von Conrad in Berlin). Arbeiten kann man damit auch (heute erst nen Verstärker umgerüstet von Kopfhörerkabel auf Klinkenbuchse ) Und was das Bohren usw. angeht, ohne Standbohrmaschine wird das nix. Zuhause habe ich auch keine, aber bohren könnte ich trotzdem mit einer.

dann doch lieber spice anwerfen und das ganze nur simuliert laufen lassen. da kann man wenigstens wirklich alles überall abreifen und aufzeichnen. und ne fehlverdrahtung läst sich einfach mal um biegen ohne sich gleich brandblasen hohlen zu müssen. auserdem kann da einem einer schneller helfen. is ja nur ne datei die ausgetauscht werden muss.

Wenn man nicht der Meister in E-Technik ist, sollte man das gesamte Teil sowieso erstmal simulieren. Damit erspart man sich kistenweise Arbeit später beim Fehlersuchen. Logische Fehler in der Platine ersetzen stelle ich mir nicht gerade einfach vor...
a) nen lötkolben in der hand gehabt. heute erst wieder
b) eine gedruckte platine mit bedrahteten bauteilen bestückt hab bisher nur selbstgezeichnete Platinen benutzt
c) einen schaltung auf einer Lochrasterplatine aufgebaut bisher nicht
d) eine gedruckte leiterplatte selber gefertigt selbst gezeichnet und geätzt, nicht gedruckt
e) eine gedruckte leiterplatte selber entworfen aus dem Schaltplan, ja, aber nur Kleinigkeiten und handgezeichnet
f) sich auf fehlersuche bei einer selbst aufgebauten schaltung gemacht ja, aber nur 2W-Verstärker =)
g) eine schaltung selber entworfen aus dem Schaltplan

Das Ätzen selbst fand ich garnicht so schlimm. In eine Plastewanne das Eisen-III-Chlorid reintun und einfach abwarten. Schlimmer ist dann nur, den Lack wieder runterzukriegen Wie es sich mit zweiseitigen Platinen verhält, weiß ich nicht.

Im Großen und Ganzen habe ich bisher nicht die Ausstattung, eine Platine zu bauen. Aber wenn ich nächsten Winter anfange, E-Technik zu studieren, wird sich das Eine oder Andere nicht vermeiden lassen - und wenn dann der Schaltplan steht, ist die Miete schon halbiert.

Gruß,
Svenska

[nooooooooos]

Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.

Nöö ich kann Regsiter usw. auch einfach in Variablen sichern...

Na dann viel Spaß, wenn du zum Rücksprung aus einer Prozedur erstmal von "irgendwo" aus dem Speicher, wo du selbst nicht weißt, wo (kein Stack), die Rücksprungadresse raussammeln musst...

Nööö wenn ich eine feste Speicheradresse dafür festlege nich...

Ist ja eigentlich wie mit 24bit registern, nur dass ich in der alu mit 8Bit registern rechnen muss... -> Darum find ichs nich so schwierig...

Dann musst du je drei Register zu einem 24-Bit-Register zusammenführen können, um eine absolute Speicheradresse zu bekommen... oder du quälst dich mit deinen Segmentgrößen rum (8 Bit? 256 Byte pro Segment?)

Der einzige Unterschied ist, dass bei bst. Operationen keinen Übertrag auf das nächst höhere Register passiert, aber dass kann man ja mit ADC schön umgehen.

Und ja, Register sind ein zu lösendes Problem...

Das gedenke ich sozulösen, indem ich 8 (3Bit im opcode) verschiedene gleicherechtigte 8bittige Register mache...

Womit wir bei CISC und einer in EPROMs gespeicherten Tabelle gelandet wären - denn in Hardware kannst du vielleicht 20 Opcodes gießen (pro Platine einen), aber nicht pro Befehl 8 Varianten.

Ist es nicht realistisch zu denken, dass alle 8 Register Leitungen zu den 3 ALU Ein/Ausgängen haben und dann jeweils von einem Chip nur die benutzten freigeschaltet werden?

Lötkolben gibt's für 4€ im Baumarkt, da geb ich Termite recht (ich hab meinen für 3,95€ von Conrad in Berlin). Arbeiten kann man damit auch (heute erst nen Verstärker umgerüstet von Kopfhörerkabel auf Klinkenbuchse ) Und was das Bohren usw. angeht, ohne Standbohrmaschine wird das nix. Zuhause habe ich auch keine, aber bohren könnte ich trotzdem mit einer.

dann doch lieber spice anwerfen und das ganze nur simuliert laufen lassen. da kann man wenigstens wirklich alles überall abreifen und aufzeichnen. und ne fehlverdrahtung läst sich einfach mal um biegen ohne sich gleich brandblasen hohlen zu müssen. auserdem kann da einem einer schneller helfen. is ja nur ne datei die ausgetauscht werden muss.

Wenn man nicht der Meister in E-Technik ist, sollte man das gesamte Teil sowieso erstmal simulieren. Damit erspart man sich kistenweise Arbeit später beim Fehlersuchen. Logische Fehler in der Platine ersetzen stelle ich mir nicht gerade einfach vor...

Dann soll ich also zuerst das ganze simulieren??

@Termite: Jo alles ausser d+c, aber der zuständige Lehrer/Betreuer für mein Projekt kann das ja in die Hand nehmen und ne Ätzmaschine suchen...e + f war halt nur bei relativ einfachen Schlatungen (zu ner CPU).


Gruss
Noooooooooooooos

[kevin]

Nööö wenn ich eine feste Speicheradresse dafür festlege nich...

Also das ist schon wichtig genug, daß ich dafür ein Register opfern würde.

[nooooooooos]

Naja..bei meinem Aufbau wärens denn 3...aber wenn ihr meint...Ich persöhnlich kann gut auf den Stack verzichten...

[kevin]

Im Prinzip ist das Sache des Programmierers, solange genug Allzweckregister da sind. Wenn er welche für einen Stack opfern will, kann er das tun, wenn nicht, dann eben nicht.

[Svenska]

Wie ich bereits schrieb - du kannst den Stack gerne irgendwo in den Speicher festlegen (u.U. sogar auf einen getrennten Adressraum, wenn du so willst). Aber Multiprocessing/Multitasking (präemptiv) setzt einen verschiebbaren Stack voraus. Und genau aus diesem Grund gibt es zwar ein präemptiv-Multitask-Betriebssystem für den Amstrad CPC, nicht aber für den C64.

Die Idee mit den Registern in der ALU stimmt so, allerdings brauchst du trotzdem für jede Kombination einen Opcode. Sonst könntest du ja nicht unterscheiden, welche Register nun z.B. addiert werden sollten.

Und ja, du solltest erst alles simulieren (siehe auch MyCPU). Oder du hast die Gerätschaften (Logic analyzer, Oszilloskop), um Bugs später herauszusammeln und die gesamte Hardware dafür ausgelegt (Fädeltechnik). Mit gezeichneten/gedruckten/gefrästen Platinen wirst du bei Bugs eher Fluchen.

Gruß,
Svenska
(, der zu faul zum Zitieren ist)

[nooooooooos]

Ah oke...dann beginn ich denn mal mit der Simulation.
Jaja so ists klar mit den Opcodes...Ich mach glaub ich einen Befehl 16Bit.

Ich kann doch die Register fürs Multitasking auch irgendwo an einem festgelegten Platz im Speicher sichern??


Gruss
Noooooooooooos

[RedEagle]

Währe Multitasking nicht nen bischen viel??
Ich finde Multitasking jedenfalls sehr weit übertrieben, da sowas nicht gerade wenig Arbeitsspeicher in anspruch nimmt.
Wenn man seine CPU so baut/gestaltet, dass man sie später um einige features erweitert ist ja OK, aber ich bin der meinung das ein einfaches Textmode, singletasking, singleuser OS ausreichen sollte.
Außerdem sollte man sich erstmal gedanke über das "benutzen" von Interrupts machen. Dafür ist ja auch einiges an Speicher (und/oder) Register erforderlich.

ps.: Es wird schon gründe dafür geben, warum DOS kein multitasking kann. Mann sollte nicht erwarten, das der Prozessor mehr kann als ein 80186. Mann sollte froh sein, wenn er in der Lage ist ein MFA zu ersetzen...

[nooooooooos]

Jojo...dann mach ichs mal ohne Stack usw...

[Svenska]

Währe Multitasking nicht nen bischen viel??

Warum? Die hardwareseitigen Voraussetzungen sind jedenfalls gering (ein verschiebbarer Stack und diverse Sprungmöglichkeiten sind alles), um präemptives Multitasking hinzukriegen. Für kooperatives MT ist ein verschiebbarer Stack natürlich nicht nötig.

Speicherschutz ist wieder ein anderes Thema, dafür braucht man auch auf Prozessorebene eine Unterstützung. So weit will auch ich nicht gehen.

Ich finde Multitasking jedenfalls sehr weit übertrieben, da sowas nicht gerade wenig Arbeitsspeicher in anspruch nimmt.

Man muss es ja nicht gleich übertreiben. Ein kleiner MT-Kernel lässt sich durchaus effizient programmieren - eine Bank (á 32 KB) sollte dafür schon reichen. Ich verweise nochmals auf SymbOS. Das unterstützt präemptives MT auf einer CPU, die -definitiv- dafür nicht gebaut wurde.

Wenn man seine CPU so baut/gestaltet, dass man sie später um einige features erweitert ist ja OK, aber ich bin der meinung das ein einfaches Textmode, singletasking, singleuser OS ausreichen sollte.

Später Erweiterungen hinzufügen ist gleichbedeutend mit einem kompletten Neuentwurf, schließlich ist sämtliche Software auf die CPU hin programmiert worden und eher nicht auf Erweiterungen hin optimiert. Je langsamer die CPU, desto mehr muss optimiert werden.
Den Textmode würde ich vorerst streichen - dazu brauchst du schon Peripherie Und auf eine MT-fähige CPU kann man durchaus ein ST-OS aufsetzen, ohne Leistung zu verschenken. Andersrum geht das nicht.

Es wird schon gründe dafür geben, warum DOS kein multitasking kann.

Weil MT damals kein Thema war. Den Erfolg siehst du in TSRs. Und in Windows 3.0, welches auch auf einem 8088 noch MT kann.

Mann sollte nicht erwarten, das der Prozessor mehr kann als ein 80186.

Das reicht doch aus Man muss sich ja nicht auf das Niveau des Intel 8008 herunterlassen...

Was ist ein MFA?

Jaja so ists klar mit den Opcodes...Ich mach glaub ich einen Befehl 16Bit.

Wow, so viele? Was willst du mit 64k verschiedenen Opcodes? 8 Bit reichen meiner Meinung nach dicke aus für so eine Heimbau-CPU. Nach der Opcodelänge richtet sich dein µCode-EPROM und die Datenleitungen dorthin. 256 CPU-Befehle sollten meiner Meinung nach auch reichen (RISC I hatte 30, glaube ich. Eine PDF dazu habe ich hier.)

Ich kann doch die Register fürs Multitasking auch irgendwo an einem festgelegten Platz im Speicher sichern??

Klar, dagegen spricht ja auch nichts. Aber jede Anwendung (jeder Prozessfaden) braucht einen eigenen Stack, um selbst rekursiv arbeiten zu können.

dann mach ichs mal ohne Stack usw

Ich will dir den Spaß nicht verderben, aber ohne Stack kommst du nicht allzu weit. Das merkst du dann an der Programmierung. Mindestens im Speicher hartcodieren wirst du den müssen.
Übrigens: Die C64-Architektur (hartcodierter Stack im RAM) führte auch dazu, dass kaum rekursive Algorithmen eingesetzt wurden, weil einfach zu schnell ein Stack-Overflow auftrat.

Und schaut euch mal SymbOS an (und schreibt was hierzu), falls ihr das noch nicht getan habt. Der Emulator WinAPE taugt auch gut dazu, es mal laufenzulassen und auszuprobieren. So weit muss man es natürlich nicht treiben, aber dieses System zeigt eindrucksvoll, was man anstellen kann, wenn man will.
Die Voraussetzungen dafür sind: 128-576 KB RAM, 4 MHz und 4 EPROMs. So viel solltest du mit deiner CPU schon schaffen können.

Gruß,
Svenska

[Termite]

Moin

sind im opcode nicht auch die Addressen der register und speicherzellen mit versteckt? sowpe die datenworte die verwendet werden sollen?

ein PIC hat z.B. 12 bis 14 bit Op-Codes je nach Addressbusbreite. Ist auch irn RISC befehlssatz.

der 8086 hat meines wissens auch nur weniger 8 bit befehler. die meisten benötigen mehr. da Addressen, Register, interruptnummern mit codirt werden müssen. CISC

von ARM möcht ich gar nicht reden. der Befehlssatz ist würcklich übel. mit seinen ganzen vor und randbedingungen die man da noch mit reinkodieren kann. (sowas wie führe den befehl nur aus wenn das Carri flag nicht gesetzt ist. das geht so wie ich das bisher verstanden hab für alle befehle.)

gruss