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
Mal bei der UCSD nachgesehen? Die hatten den Kram doch mit ihrem UCSD-Pascal damals verbrochen ...
@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.
DIe Quellcode von Apple II Basic interpreter (irgenwo verfügbar), kann vielleicht dir helfen.
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.
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.