www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik suche beschreibung zu p-code


Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal bei der UCSD nachgesehen? Die hatten den Kram doch mit ihrem 
UCSD-Pascal damals verbrochen ...

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ?!

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
143KB waren doch der reine Wahnsinn!

Autor: Ale (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DIe Quellcode von Apple II Basic interpreter (irgenwo verfügbar), kann 
vielleicht dir helfen.

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-))

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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/re...
(Einstiegsseite ist 
http://miller.emu.id.au/pmiller/ucsd-psystem-um/index.html)





Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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)

Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
crunchen heisst heite doch defragmentieren (naja, 
Festplatten/Betriebssysteme arbeiten inzwischen effektiver und nutzen 
den freigewordenen Platz für Fragmente von Dateien).

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ?!

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: GeraldB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.