Ich hatte einen Traum...

[drohne235]

Wie bindet man eigentlich solche speziellen Sachen wie cognew und cogstop konform in den Compiler ein?

[josto]

@drohne235: Ich habe keine Ahnung . Ich dachte, hier im Forum könnte mir da jemand helfen?
Im Moment würde ich etwas Spin Code mit einbinden, so dass der ASM Code aus dem Spin Startup-Code gestartet wird.

[drohne235]

@drohne235: Ich habe keine Ahnung . Ich dachte, hier im Forum könnte mir da jemand helfen?
Im Moment würde ich etwas Spin Code mit einbinden, so dass der ASM Code aus dem Spin Startup-Code gestartet wird.

Da habe ich mich falsch ausgedrückt, ich meinte etwas anderes als die Startup-Prozedur: Wir haben ja mehrere Cores zur Verfügung und in Spin auch grundlegende Befehle, um diese zu handhaben. Wir können in einer COG einen neuen Spin/PASM-Code mit cognew starten, können eine COG mit cogstop beenden usw. In C wollen wir das später ja auch können. Die Frage ist nun: Wie macht man das nun konform in C? Wie starte ich zum Beispiel aus einer C-Routine heraus eine andere C-Routine in einer neuen COG. Wie der Propeller das auf Maschinenebene macht ist mir klar, aber wie formuliert man das konform in C? Fügt man einfach entsprechende Schlüsselworte bzw. Befehle hinzu, oder gibt es dort schon entsprechende Ansätze?

Edit:
Habe es gerade im Apple II Thread gepostet, ist aber hier auch interessant:

Liste von Emulationen auf dem Prop: http://forums.parallax.com/showthread.p ... mocog+6502

[PIC18F2550]

Hallo drohne235,

ob der Compiler diese funktion überhaut unterstützt hängt davon ab ob er multicore Prozessoren überhaupt selbst erkennt und somit den code optimieren kann.

Ansonsten muss für jedem cog eine seperate compiler+startanweisung im Quelltext sein und er muss die RAM-Bereiche der cogs und des hRam sowie des Stackpointer unterscheiden können.

Stell ich mir nicht gerade einfach vor.

[Nadji]

Bei so einem C-Compiler sollte auch inline Assembler vorhanden sein, damit kann man dann alle Maschinensprachebefehle ausführen.
Um z.B. unter Linux einen neuen Kindprozess zu erzeugen ruft man einfach die Funktion fork() auf. fork() erzeugt ein Kindprozess und liefert gleichzeitig zwei Werte zurück einmal die PID von dem Kindprozess und der Kindprozess bekommt 0 zurückgeliefert.
Es existieren danach also 2 Prozesse.
Es sei denn fork() liefert -1 zurück, dann gab es einen Fehler, und es wurde kein Kindprozess erzeugt.
also
if ( fork() == 0 ) ... hier kindprozess
else .. hier gleichzeitig vaterprozess

[Nadji]

Wie bindet man eigentlich solche speziellen Sachen wie cognew und cogstop konform in den Compiler ein?

hier wäre einfach eine library die die Funktionen anbietet.

sprich
#include <systemlibswasauchimmer.h> // bekanntmachung
#include <hive.h> // sonstige hive spezifische includes
....
cognew(); // einfach als funktion aufrufen
....

evt nennt man sie etwas anders PROPcognew() läßt also alles mit PROP anfangen, sorgt dafür das es nicht so leicht namenskonflikte gibt.

implementiert wird das dann entweder als funktion, die evt in assembler geschrieben ist, oder als #define

[paulruiz]

Ich hab noch eine Bellard compiler gefunden:
http://bellard.org/fbcc/

Diese ist 4700 Linien (~100KB Quelle) und seht sich wohl strukturiert und einfach zu lesen aus. Das backend ist für eine stack machine, also soll also nicht zu schwierig um zu schreiben sein für ZPU/ZOG. Am besten: diese Compiler akzeptiert K&R C und ansi C. Nachteil: float/double wird nicht unterstützt und Dokumentation ist teilweise Französisch.

Paul

[yeti]

Wäre ein Port von "Sphinxcompiler" dann nicht der erste Schritt?
Man hätte so Spin (und somit auch PASM) schonmal abgehakt...
Und für andere Sprachen kann dann der PASM-Teil davon Backend spielen.
Ein eigener PASM-Assembler wäre so nicht nötig.

[yeti]

Wie bindet man eigentlich solche speziellen Sachen wie cognew und cogstop konform in den Compiler ein?

http://code.google.com/p/propgcc/source ... e/toggle.c

[yeti]

Ein kleines Problem gab es noch mit dem Dateisystem, da der Treiber in Sphinx zwei gleichzeitig geöffnete Dateien zulässt. Der aktuelle Administra-Code kann das nicht.

Wenn das nicht behoben wird brauchen wir hier garnicht weiterträumen.

Aber die Ramdisk im TriOS kann bis zu acht gleichzeitig geöffnete Dateien verwalten, also hab ich das als Ausgleich angedacht. Muss man halt nur alle nötigen Dateien vorher in die Ramdisk kopieren.

Das SRAM als RAMDisk verballern blockiert dessen Anwedung als XMM-Speicher... insofern halte ich das Ausweichen auf die RAMDisk nur um mehr als 2 Files öffnen zu können für keine zukunftsträchtige Lösung.