Ich hatte einen Traum...

[josto]

Unproduktiv schon, aber nicht sinnlos.

Unproduktiv ja, da vermutlich niemand unsere Ergebnisse je produktiv nutzen wird/kann.
Doppelt unproduktiv, da wir parallel quasi beide das Gleiche entwickeln.

Aber sinnlos nicht, da wie yeti schon so schön sagte, es macht Spass und erweitert den Wissenshorizont enorm.

[TuxFan]

Hallo!

...............Unproduktiv?
Neeee!
Ein benutztes Hirn bleibt länger fit!..............

Dem Gesagten/Geschriebenen kann ich nur zustimmen.

Gruß
TuxFan

[drohne235]

> Nach vielen Iterationen nun endlich: Die LED blinkt !!!
> Komisch, meine Frau konnte meine Freude nicht verstehen
> Unser Hobby macht manchmal ganz schön einsam.

Das kenne ich nur zu gut!

Also für mich ist das eine extrem spannende Sache!

@paulruiz

Für das PDP11-System würde ich den Code von TriOS in Regnatix einfach beenden, damit sich dort nichts gegenseitig behindert, da TriOS ja einige Bereiche vom eRAM verwendet. Dann kannst du ohne Probleme den gesamten eRAM für dich verwenden.

Initialisierung: Beim Start würde ich mit cogstop(0) einfach den TriOS-Loader beenden, denn dieser wird durch eine Variable im eRAM gesteuert. Mehr muß nicht passieren, damit ist Regnatix vogelfrei und deine Software ist der Alleinherrscher im Chip.

Exit: Für das Exit aus der OS-Loop genügt eine einfache reboot-Anweisung in Spin - dann bootet Regnatix wieder aus dem EEPROM und es meldet sich TriOS/PropForth.

[paulruiz]

Hab meine Hive bis zum Bellatrix aufgebaut, also nur eine Propeller aber das ist genug um CVM debuggen zu können. Anbei die Dateien mit ein funktionierendes CVM Das heißt, ein "Hello, World!" Programm lauft richtig ab und weil das Standard Library nicht trivial ist wird fast alle CVM Code benutzt. Also jetzt haben wir ein einfache aber ziemlich komplette C compiler für das Hive, aber momentan nur für LMM Programme.

Nächste Schritt ist meine Hive weiter zu bauen. Wenn Ich das VGA Test Programm versuche, mit das Hive verbunden mit dem VGA Eingang meines Fernsehers gibt es kein Bild. Sollte das funktionieren, oder war das etwas dummes um zu versuchen? (Hab kein Zeit gehabt um das Signal mit Oszilloskope zu überprüfen)

Was sind gute Software debugging Tools für Propeller? So weit benutz Ich Gear (version 2009 aus Parallax Forum) und PASD. Gibt es was besseres?

Paul

[josto]

Gratulation!!!
Freut mich für dich.
Ich bin noch nicht viel weiter, gebe meinen Weg aber nicht auf.
Als Debugger verwende ich auch PADS, was besseres habe ich bisher nicht gefunden. Mein Problem ist, dass ich einen Debugger unter Linux bräuchte, denn ich arbeite lieber unter Linux.

Wir sollten uns mal kurzschließen bezüglich Integration ins TriOS, Library-Funktionen, C-Debugger und ähnliches. Vielleicht ergeben sich da Synergieeffekte.

[paulruiz]

Ich bin noch nicht viel weiter, gebe meinen Weg aber nicht auf.

Selbstverständlich nicht: Software Vielfalt ist gut, weil im Software Monokultur Bugs oft lange unbemerkt bleiben.

Mein Problem ist, dass ich einen Debugger unter Linux bräuchte, denn ich arbeite lieber unter Linux.

Ja, mochte auch gerne etwas haben das auf Linux und OSX funktioniert. Im generellem bin Ich erstaunt wie altmodisch und unbequem die Propeller tools sind. Ich hatte gedacht das Parallax doch wohl ein gutes emulation und debug Program dabei hatte, mit zugriff auf Quell ebene. Gear bringt emulation aber kein Quell ebene und hat kein Breakpoints. Vielleicht ist emulation auch eine Brücke zu weit: zuerst mal Quell debugging von PASM und SPIN, und zuerst GDB-style damit es später auch autark auf Hive funktioniert.

Ich glaub es last sich was basteln aus die BMA und SPUD debuggers, fur beide gibt es Quelle. Beiden benutzen ein bstc List Datei um von Adressen zum Quelle zu gehen. Ich hab noch kein funktionierendes Spin compiler in C gefunden, und bstc is nicht offene Quelle glaub Ich. Vielleicht ist Sphinx brauchbar fur dieses Zweck. Vielleicht können wir Brad mal Bitten um bstc Quelle frei zu geben.

Wir sollten uns mal kurzschließen bezüglich Integration ins TriOS, Library-Funktionen, C-Debugger und ähnliches. Vielleicht ergeben sich da Synergieeffekte.

Genau. Hier Unten mein Heutigen Gedanken:

[1] TriOS
Vielleicht konnen wir anfangen mit das eRAM in zwei Teilen: 0.5MB fur TriOs und Ramdisk und 0.5MB fur XMM. Programme werden gestarted etwas wie
"cvm <program>" und "tcc <program>". Die Spin Programmen "tcc" bzw. "cvm" laden <program> ins eRAM xmm Bereich, starten eine Cog mit dem CPU Kode und gehen dan in eine OS loop. Die OS Befehle in run_cvm.spin sind meiner Meinung nach eine quick fix von Bellard, die Liste in Zog seht sich besser aus. Etwa 20 OS funktionen reichen aus fur ein mini-OS. Ein solches mini-OS greift dan wieder zu auf TriOS Bibliothek reg-ios.spin.

[2] Library funktionen
Lassen sich vielleicht einfach bauen auf Basis von http://minnie.tuhs.org/Archive/PDP-11/T ... ibc/stdio/

[3] C-Debugger
Ja, das muss dabei sein. Ich denke es gebe ein syscall "break" welche die CPU register abspeichert und kontrolle an die OS Schleiffe gibt. Die OS Schleife geht dan in eine weitere Kommunikationsschleife mit Debugger auf PC oder auf Bellatrix. Vielleicht kan das so gemacht werden das ein einziges Debugger nutzbar ist fur PASM, Spin und C.

Paul

[drohne235]

Ich verwende PASD, damit kann man recht komfortabel arbeiten. Bei Gear hat mir immer die Anbindung direkt an die Infrastruktur im System gefehlt.

[1] TriOS
Vielleicht konnen wir anfangen mit das eRAM in zwei Teilen: 0.5MB fur TriOs und Ramdisk und 0.5MB fur XMM. Programme werden gestarted etwas wie
"cvm <program>" und "tcc <program>". Die Spin Programmen "tcc" bzw. "cvm" laden <program> ins eRAM xmm Bereich, starten eine Cog mit dem CPU Kode und gehen dan in eine OS loop. Die OS Befehle in run_cvm.spin sind meiner Meinung nach eine quick fix von Bellard, die Liste in Zog seht sich besser aus. Etwa 20 OS funktionen reichen aus fur ein mini-OS. Ein solches mini-OS greift dan wieder zu auf TriOS Bibliothek reg-ios.spin.

Das ist eine sehr gute Idee. TriOS kann man recht einfach auf die unterste RAM-Bank einschränken. Ich würde das in reg-ios per #define und bedingter Compilierung konfigurierbar machen. Wenn XMM dann die obere RAM-Bank nutzt, ist auch der Code für die Ansteuerung wesentlich einfacher. Und sowohl für TriOS als auch für die XMM-Sachen sind 512 KB ausreichend denke ich.

[Nadji]

Ich verwende PASD, damit kann man recht komfortabel arbeiten. Bei Gear hat mir immer die Anbindung direkt an die Infrastruktur im System gefehlt.

[1] TriOS
Vielleicht konnen wir anfangen mit das eRAM in zwei Teilen: 0.5MB fur TriOs und Ramdisk und 0.5MB fur XMM. Programme werden gestarted etwas wie
"cvm <program>" und "tcc <program>". Die Spin Programmen "tcc" bzw. "cvm" laden <program> ins eRAM xmm Bereich, starten eine Cog mit dem CPU Kode und gehen dan in eine OS loop. Die OS Befehle in run_cvm.spin sind meiner Meinung nach eine quick fix von Bellard, die Liste in Zog seht sich besser aus. Etwa 20 OS funktionen reichen aus fur ein mini-OS. Ein solches mini-OS greift dan wieder zu auf TriOS Bibliothek reg-ios.spin.

Das ist eine sehr gute Idee. TriOS kann man recht einfach auf die unterste RAM-Bank einschränken. Ich würde das in reg-ios per #define und bedingter Compilierung konfigurierbar machen. Wenn XMM dann die obere RAM-Bank nutzt, ist auch der Code für die Ansteuerung wesentlich einfacher. Und sowohl für TriOS als auch für die XMM-Sachen sind 512 KB ausreichend denke ich.

Hm warum so statisch?
Eine Stelle bestimmen, an der die Bereiche stehen entweder vorne im eRam , oder hinten, besser wäre es in den zuständigen Propeller. Dort eine tabelle an der z.B. steht
Anfang adresse ram ,End adresse ram, Bits, 3 byte ID

Also z.b.
$1000 chksum bit, Anz, "go" ; Blockgröße, Checksumme ;erste eintrag sondereintrag
$00000 $01fff $40 "TIO" ; trios
$02000 $03FFF $40 "XMM " ;xmm
$04000 $07FFF $01 "FRE" ; freier, unbenutzer speicher
$08000 $09FFF $41 "RES" ; reserviert könnte z.b. im eeprom stehen wo sich XMM später einträgt
$0A000 $0A2FF $4 "DIR" ; block der auf eine erweiterung dieser tabelle zeigt (für später mal)
$00000 $chksum $81 "EOF" ;ende markierung entweder hier die checksumme oder am anfang nicht beides
$06000 $xxxxx ; Checksum um die gültigkeit zu überprüfen
Eine Voreinstellung davon steht im hinten im eeprom, sprich wie es nach einem Kaltstart eingestellt wird.
So kann man jederzeit den Speicher anpassen wie an möchte, ohne neu zu übersetzten. die daten im eeprom ändern und Neustart.
Als Bits wäre denkbar $01 dynamischer wert,$02 temporäre daten (z.b. xmm brauch mal viel platz dann holt es sich noch was vom free-Bereich und gibt es später wieder frei), $40 fixer wert, darf im betrieb nicht verändert werden erfordert neustart, ,...
die Bits die nicht benötigt werden, bleiben erst mal frei.
Die Endekennung macht ob mit nem Bit z.B. $80, oder der Kennung eof, oder wenn Anfangsadresse gleich null, oder alles drei.
Die Checksum, wird über alle Einträge gemacht, z.b. EOR über alles mit funnycompliment $aa550ff0. damit wäre es z.b. möglich einen Warmstart zu machen. auf jedenfall könnte man damit die Gültigkeit sicherstellen.
das letzte Byte bei der Größe könnte man weglassen, oder man legt ne Blockgröße fest, z.b. 4KB in der der Speicher vergeben wird. dann reichen 16 Bitwerte für Anfang und ende.
Im eeprom könnte eine etwas abgewandelte Tabelle stehen, z.b. wenn anfangsadresse leer ist, steht eine länge bei der Endadresse. statt XMM steht res dort, und xmm trägt sich dann dort (aber nur im ram) ein wenn es verwendet wird, sollte aber xm2 verwendet werden (nur mal als beispiel), trägt sich das dort im ram steht auch ein. wenn es den Bereich wieder freigeben kann trägt es wieder res ein. dort könnten auch Daten stehen wie lang die Tabelle ist, z.b. 4 einträge, Speichergröße, wo die Tabelle im ram steht. Die Tabelle im eeprom könnte kleiner sein.
das ganze kann man sich so ähnlich vorstellen wie die Partitionstabelle bei ner Festplatte.

Vorteil, man könnte mit beliebigen Speicherausbau arbeiten, und die größen jederzeit schnell anpassen ohne neu kompilieren zu müssen.
Wie die Tabelle dann konkret aussieht, sollte man diskutieren z.B: welcher Bedarf existiert, und was sinnvoll ist,auf jeden Fall sollte sie offen für Erweiterungen sein, das ganze ist jetzt nur mal so grob, hingeschrieben.

[josto]

Mein Compiler nimmt so langsam Formen an. Das Fibonacci Programm vom GCC Pendant habe ich erfolgreich ausgeführt. Leider (bisher ) erreiche ich nicht die Performance des GCC, aber ich arbeite daran...

Im Moment wird nur LMM unterstützt. Als nächstes kommt XMM dran.

[josto]

GCC ist beim Fibonacci Programm ca. 3-mal schneller als SmallC. Ich wollte doch wissen warum. Ich habe ein kleines Beispiel des PropGCC gefunden. Folgende Funktion:

Code: Alles auswählen

char *strcpy(char *dst_orig, const char *src) {
    char *dst = dst_orig;
    while ((*dst++ = *src++) != 0)
        ;
    return dst_orig;
}

wird beim GCC zu:

Code: Alles auswählen

    .global _strcpy
_strcpy
    mov r7, r0
.L5
    rdbyte r6, r1
    cmp r6, #0 wz
    add r1, #1
    wrbyte r6, r7
    add r7, #1
    IF_NE jmp .L5
    jmp   __LMM_RET

Das ist nativer Prop Assembler. Für Funktionsparameter und lokale Variablen werden Register verwendet. Von Hand könnte man das kaum besser machen...

Der SmallC Compiler dagegen macht daraus:

Code: Alles auswählen

PUB _strcpy:
    ENTER
    ADDSP -4
    GETw1s 12
    POINT2s -4
    PUTwp1
_54:
    POINT2s -4
    GETw1p 0
    INCwp
    PUSH1
    POINT2s 8
    GETw1p 0
    INCwp
    MOVE21
    GETb1p 0
    POP2
    PUTbp1
    NE10f _55
    JMPm _54
_55:
    GETw1s 12
    RETURN

Dies ist VM-Code, welcher von einer virtuellen Maschine im COG interpretiert wird. Hier wird der Stack für Funktionsparameter und lokale Variablen genutzt.
Wenn man jetzt noch berücksichtigt, dass jede VM Anweisung im Schnitt mit 10 Befehlen interpretiert wird, ist es wirklich erstaunlich, dass der Unterschied beim obigen Testprogramm nur einen Faktor 3 ausmacht.

Ingesamt also sehr ernüchternd....

Paul: Hast du für den FBCC Vergleichswerte?