hallo leuts,
ich habe vergeblich nach einer guten beschreibung (egal ob deutsch oder
englisch) zum thema p-code gegoogelt. hier im forum findet sich leider
auch nicht das was ich suche. ich bin auf der suche nach einer
beschreibung des p-codes, mit all seinen opcodes (plus erklärung und
parameter). einen p-code compiler und interpreter habe ich schon
gefunden, aber eine ausführliche beschreibung steht noch aus. kann mir
da jemand helfen ?
gruß
rene
@rufus
ich habe zwar die freigegebenen quelltexte des ucsd pascals, aber noch
keine beschreibung der opcodes des p-codes. ich hab lediglich ergoogeln
können das es mehrere kategorien gibt, aber das wars dann auch schon.
eine genaue beschreibung habe ich noch nicht finden können.
aber wieso meinst du "verbrochen" ? ist das ucsd pascal so schlecht ?!
Oh, das sollte keine wirkliche Wertung sein. Ich hatte Anfang der 80er
das Pech, daß man mir damit in der Schule das Pascal-Programmieren recht
effektiv verleiden konnte ... was auch am Diskettenjonglieren lag; die
verwendeten Apple-II-Rechner hatten halt nicht wirklich
Speicherkapazität auf ihren Diskettenlaufwerken.
aso :-)
ja das disk-jonglieren hat mir z.b. auch die freude am geos auf dem c64
genommen. wollte damals eigentlich mal was damit programmiert haben (in
dem großen c64 buch standen einige api-funktionen, habe aber leider nie
programme zum laufen bekommen :-(( und das disk-jonglieren ging mir sehr
schnell auf den keks ...
weswegen ich nach p-code suche :
ich möchte mir gerne einen interpreter bauen mit dem ich ohne "größeren"
aufwand (kleine) programme auf einem msp430 bzw. pc laufen lassen kann.
aber irgendwie finde ich keine gescheite beschreibung der opcodes. habe
zwar mehrere interpreter und compiler (u.a. direkt von ucsd) aber keine
beschreibung des systems (und vor allem eben der opcodes) an sich.
auf einer seite (http://www.threedee.com/jcm/psystem/) war gar zu lesen
das es dokumentation in elektronischer form nicht gibt. wäre natürlich
sehr schade. vor allem weil man sich dann nur an dem interpreter code
halten kann.
@rahul
irgend so ein wahnsinniger war gar der meinung das man mit 640kB Ram bis
in alle ewigkeiten auskommt :-) schade nur das dieser jenige eine
gewisse prozessorfamilie auf eben diese 640kB (ok es war ja etwas mehr
als 1MByte) beschränkt hat. verdammt, warum hat sich nur der 68000 nicht
als pc-prozessor durchgesetzt :-))
@ale
die quellcodes würden zur not auch helfen, nur würde ich gerne eine
genaue dokumentation der opcodes haben, damit ich das ganze system
(interpreter und compiler) besser verstehen kann.
> schade nur das dieser jenige eine gewisse prozessorfamilie> auf eben diese 640kB (ok es war ja etwas mehr als 1MByte)> beschränkt hat.
Es war ganz genau exakt 1 MByte, und die "Beschränkung" kam von der
Firma Intel. Bill G. hat damit exakt gar nichts zu tun. Intel versuchte
einen 8-Bit-Prozessor aufwärtskompatibel aufzubohren, und heraus kaum
die (grauenhafte) segmentierte Architektur des 8086, die mit 20
Adressleitungen exakt 1 MByte adressieren konnte.
Der 68K wurde unter anderem wegen der nicht exisitierenden
Kompatibilität zu alten 8080-Systemen und deren Software nicht verwendet
(ja, Wordstar wurde für 8080 unter CP/M geschrieben).
Auch daran ist Bill G. nicht schuld; nicht, daß ich den Kerl sonst
irgendwie für lobenswert halten würde. Alles kann man ihm aber nicht in
die Schuhe schieben, auch nicht die globale Erwärmung. Leider.
Einen Interpreter einer etwas anderen Art für MSP430 findet sich
übrigens hier http://rowley.co.uk/msp430/basic.htm - aber das ist wohl
nicht, was Du suchst.
Hast Du das hier http://en.wikipedia.org/wiki/P-code_machine und das
hier http://en.wikipedia.org/wiki/UCSD_p-System gesehen? Vielleicht
hilft ja einer der Links in den Artikeln weiter.
Oder das hier:
http://miller.emu.id.au/pmiller/ucsd-psystem-um/reconstruct/03-04-pseudo-machine.html
(Einstiegsseite ist
http://miller.emu.id.au/pmiller/ucsd-psystem-um/index.html)
>Alles kann man ihm aber nicht in die Schuhe schieben, auch nicht die globale >Erwärmung. Leider.
Naja, viele Server laufen mit einem Mikrosoft-Betriebssystem. Die
meisten Rechner der typischen Eselbenutzer (CS-Spieler und wer sonst
noch den ganzen Tag am PC "arbeitet") vermutlich auch. Beides rennt
quasi ununterbrochen, verbaucht kostbare Energie und wärmt damit
teilweise einfach nur die Bude, weil der Bootvorgang zu lange dauert.
Somit sind also Bill G., Linus Torvalds und AT&T für die globale
Erwärmung verantwortlich.
(Entschuldigung für die Fred-Entführung)
Wenn man zwei Laufwerke hatte dann lief UCSD-P eigentlich garnicht
schlecht. Und es hinderte einem ja auch niemand daran sich ein 2x80T
Laufwerk zu kaufen. :-)
Damals nervig, aber heute natuerlich kultig war das crunchen. Das
Filesystem hat neue Files immer nur hinten angehangen. Hat man dagegen
ein File geloescht so blieb der freie Platz zunaechst ungenutzt. Es gab
dann eine extra Funktion welche alle Files wieder von hinten nach vorne
umsortiert hatte.
Das hat, zusammen mit dem Diskettenwechsel beim anwerfen des Compilers,
dafuer gesorgt das man sich sehr genau ueberlegt hat ob man nicht
irgendwo ein Semikolon vergessen hat.
Ausserdem wenn ihr glaubt UCSD-P war lahm dann haette ihr mal Lisp in
der P-Code Version sehen sollen.
Irgendwer hat uebrigens das UCSD unter Linux ans laufen gebracht. ICh
wuerde mal einen Blick in de.alt.folklore.computer vor 2-3 Jahren
empfehlen.
Olaf
crunchen heisst heite doch defragmentieren (naja,
Festplatten/Betriebssysteme arbeiten inzwischen effektiver und nutzen
den freigewordenen Platz für Fragmente von Dateien).
>Bill G. hat damit exakt gar nichts zu tun.
den meinte ich auch gar nicht :-) sondern denjenigen der unbedingt
abwärtskompatibel sein wollte :-)
danke für die links. hatte bei wikipedia (de) nichts gescheites
gefunden, und unter wikipedia (en) wohl das falsche gesucht ... werds
mir mal anschauen (auch den msp430-basic link, für reine
interpreter-sachen sicherlich nicht uninteressant, allerdings für
kompatibilität wohl eher ungeeignet, ucsd pascal lässt sich hingegen
(weitestgehend) auf einem pc, einem apple, einem z80-system und und und
.. portieren)
hat eigentlich jemand so ein system mal mit einem modernen prozessor
(avr, arm o.ä.) aufgezogen ?!
@rufus
jo erstmal danke für die links. der link von miller.emu.id.au ist in
etwa das was ich suche. jetzt mal schauen ob ich sowas auf einem msp
realisiert bekomme.
rene
> Damals nervig, aber heute natuerlich kultig war das crunchen. Das> Filesystem hat neue Files immer nur hinten angehangen. Hat man dagegen> ein File geloescht so blieb der freie Platz zunaechst ungenutzt. Es gab> dann eine extra Funktion welche alle Files wieder von hinten nach vorne> umsortiert hatte.
Das ist nicht ganz richtig. Man konnte die Dateien sowohl komplett nach
vorne als auch nach hinten schieben. Es war auch möglich ein "Loch" an
einer bestimmten Stelle zu erzeugen.
Dateien konnten nicht fragmentiert gespeichert werden. Die Speicherung
erfolgte im freien Bereich, der groß genug für die Datei war - also
nicht unbedingt hinten.