suche beschreibung zu p-code

@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 ?!

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.

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

>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.