aus einer 8 bit CPU eine 16 bit CPU machen

>> Zum Spaß habe ich mich mit etwas relativ nutlzosem befasst:
>Ja, da muß man wohl zustimmen.

Naja, so ein winziges bischen Nutzen ist schon dabei: Wenn man so einen 
Emulator programmiert, kann man lernen, wie so ein Prozessor 
funktioniert.

Wenn man ein Assemblerprogramm für den Mini-16-Bitter schreibt, kommt 
man auch auf ein paar Ideen, welche Befehle im Instruktionssatz noch 
nützlich wären.
Den Hauptnutzen wäre also quasi der Lerneffekt.

chris

Auf dem Apple wurde ebenfalls ein 16-Bit Prozessor (Sweet 16 genannt)
auf einem 8-Bitter (6502) emuliert. Auf diesem Pseudoprozessor wurden
diejenigen Teile des Integer-Basic-Interpreters implementiert, die
heftigen Gebrauch von 16-Bit-Operationen machten und nicht extrem
zeitkritisch waren.

Dadurch wurde der Code des Basic-Interpreters deutlich verkürzt, ohne
dass darunter die Ausführungsgeschwindigkeit zu sehr litt. Der
Interpreter für den Sweet-16-Code fiel speichermäßig nur wenig ins
Gewicht, da der Programmcode gerade einmal 300 Bytes groß war.

In diesm Fall war also der praktische Nutzen gegeben. Beim später
erschienenen Aplesoft-Basic wurde dann aber trotzdem darauf
verzichtet, da dessen Entwicklung an einen kleinen Zulieferer (ich
glaube, dessen Name war Microsoft ;-)) outgesourcet wurde.

> Naja, so ein winziges bischen Nutzen ist schon dabei: Wenn man so einen
> Emulator programmiert, kann man lernen, wie so ein Prozessor
> funktioniert.

...wobei man wiederum nicht vergessen darf, dass die Implementation 
eines realen Prozessors wiederum andere Probleme aufwirft, die man beim 
Programmieren eines Emulators nicht antrifft, die aber einen recht 
entscheidenden Einfluss auf das Design haben.

Das freut mich, dass Ihr es teilweis auch interessant findet.

>Vieleicht magst du ja noch weitere Details deines Projektes hier posten?
Die Struktur der CPU hat Daniel F. in diesem Thread gepostet:
Beitrag "Prozessor Eigenbau: Instruktionssatz" und stammt wohl aus einem 
Vorlesungsskript von einem Herrn Lampacher und Herr Poner.
Leider hatte die CPU keinen Namen weshalb ich sie kurz "lapoco" ( 
LAmpacher-POner-COre ) genannt habe.

Der Emulator für den Atmega8 findet sich im Link ganz oben und ist in C 
programmiert, sodass man ihn eigentlich auf jede andere CPU übertragen 
kann, für die es einen C-Compiler gibt.
Man könnte den Emulator z.B. in einen ARM laden, dann hätte man aus 
einer 32Bit eine 16Bit CPU gemacht ;-)

Das Projekt findet sich im Link aus dem ersten Post. Dort findet sich 
auch der Befehlssatz. Es sind nur 16 Befehle. Man kann den Befehlssatz 
wohl als "orthogonal" bezeichen, jeder Befehl kann auf alle Register 
angewendet werden. Zusätlich habe ich noch einen Assembler und Simulator 
für den PC in Java programmiert. Der läuft bis jetzt aber nur als 
Kommandozeilenversion und der Imput-File-Path ist in Main.java fest 
eingestellt. Um das Ganze mal in die Realität umzusetzen, habe ich den 
Emulator mit einem kurzen lapoco-Testprogramm auf einen Atmega8 portiert 
und ein paar LED's blinken lassen.

Die Befehel können bis zu 3 Register gleichzeitig ansprechen z.B.

sub R1,R2,R2 // R1=R2-R3

Wenn man den Emulator auf dem Atmega8 kompiliert, werden mit der 
Compileroption "Os" nur ca. 1Kb an Speicher verbraucht. 
Interssanterweise läuft der Emulator dann auch schneller als mit der 
Opion "O0".

>Auf dem Apple wurde ebenfalls ein 16-Bit Prozessor (Sweet 16 genannt)
>auf einem 8-Bitter (6502) emuliert. Auf diesem Pseudoprozessor wurden
>diejenigen Teile des Integer-Basic-Interpreters implementiert ...

Das ist ja hoch interessant. Auf die selbe Weise könnte man ja einen 
C-Compiler verwenden, wenn es z.B einen für "lapoco" gäbe. Der 
CPU-Emulator ist schnell entworfen und dann hätte man quasi sofort für 
jede neue CPU einen Compiler.

> Auf die selbe Weise könnte man ja einen C-Compiler verwenden, wenn
> es z.B einen für "lapoco" gäbe. Der CPU-Emulator ist schnell
> entworfen und dann hätte man quasi sofort für jede neue CPU einen
> Compiler.

So wird es ja bspw. bei Java gemacht: Der Compiler übersetzt den
Java-Quellcode in den Byte-Code, der dann von derr Java Virtual
Machine ausgeführt wird.

Schon vor 30 Jahren gab es UCSD-Pascal. Dabei handelte es sich um ein
Betriebssystem mit einer Entwicklungsumgebung für Pascal, das komplett
auf der so genannten p-code machine lief und somit leicht portierbar
war. Einer der Ports wurde von der Fa. Apple als Apple-Pascal
vertrieben, später ein weiterer von IBM für den IBM-PC.

>> es ist die super-Möglichkeit einmal eine eigene Traum-CPU zu
>> entwickeln.
>
> Quark, um eine Traum-CPU zu entwickeln benutzt man höchstens FPGAs,
> aber doch keine anderen CPUs!

Warum nicht? Während der Entwicklung hat ein Software-Emulator den
Vorteil, dass er schneller realisiert, leichter gedebugt und besser
erweitert werden kann als ein FPGA-Design. Man kann damit bereits
Entwicklungstools wie Assembler und Compiler testen und erkennen, ob
bspw. der Befehlssatz etwas taugt. Mit einer FPGA-Implementierung kann
man in einer nächsten Phase abschätzen, wie gut sich die Architektur
in Logik umsetzen lässt. Damit minimiert man das Risiko in der
(teuren) dritten Phase, in der die eigentliche Chip-Entwicklung
stattfindet.

Im realen Einsatz eine Software-CPU natürlich der entsprechenden
Hardware-CPU hinterher. Das tut aber i.Allg. auch eine Soft-CPU im
FPGA, nur ist dort der Unterschied nicht so groß.

@Simon:

Du weisst sicher wie die großen Prozessorbauer neue Designansätze
untersuchen? Zeigt mir den FPGA, der komplette Designs von aktuellen
Chips fasst.

>Auf dem Apple wurde ebenfalls ein 16-Bit Prozessor (Sweet 16 genannt)
>auf einem 8-Bitter (6502) emuliert.

Sehr interessant. Ich habe mir gerade mal die Dokumentation zum Sweet 16 
angeschaut ( es gibt orgiginal Texte von Steve Wozniak )
http://6502.org/source/interpreters/sweet16.htm

Der Prozessor hat 16 16Bit Register und 32 Befehle.Die meisten Befehle 
sind mit nur 8 Bit codiert.
Ein einfaches und Code-effizientes Design. Sehr lehrreich.