Propeller Chip wird "erwachsen"

[R. M. (exp)]

2006 habe ich mir ein Propeller Demo Board zugelegt.
Ich habe damit ein bischen rumgespielt und dann ist es in der
Bastelkiste verschwunden.
Der Grund war, diese SPIN Programmiersprache war mir doch etwas zu
exotisch und nur ASM wollte ich mir nicht antun.
Zwischendurch habe ich immer wieder mal C-Compiler gefunden,
doch die kosten entweder richtig Geld (ICCprop) oder sind doch zu sehr 
mit
SPIN belastet (Catalina C).

Vor einigen Monaten habe ich mehr durch Zufall diese Seite gefunden:

http://code.google.com/p/propgcc/

Dieser GCC Port befindet sich noch im ALPHA RELEASE Stadium
( GDB und eine IDE fehlen noch)

Trotzdem konnte ich damit schon einige nette Applikationen programmieren
und bin auch als "AlphaTester" unterwegs.
Ich finde immer noch einige Bugs, aber die Leute vom Build Team sind
dafür sehr dankbar und der bugfix wird sehr schnell durchgeführt.

Mittlerweile "freunde" ich mich immer mehr mit diesem Chip an
und die 8 parallelen CPUs zwingen ein wenig zum Umdenken
gegenüber normalen interrupt gesteuerten Anwendungen.

Meine eigenen Projekte sind hier:
http://home.mnet-online.de/reimay/Projects/

mit freundlichen Grüssen
Reinhard

[Olaf (Gast)]

> Der Grund war, diese SPIN Programmiersprache war mir doch etwas zu
> exotisch und nur ASM wollte ich mir nicht antun.

Und dann hast du dich entschlossen BASIC zu verwenden?
Oder wieso hast du in Radiometer.c gleich vier goto auf
einer Bildschirmseite?

Olaf

[R. M. (exp)]

@ Olaf

Volltreffer:
Da hast Du auf Anhieb die Stellen entdeckt, die ich immer schon
ändern wollte, aber dann doch wieder vergessen habe.

Danke für die Erinnerung !

[Yalu X. (yalu) (Moderator)]

Olaf schrieb:
> Oder wieso hast du in Radiometer.c gleich vier goto auf
> einer Bildschirmseite?

Vier? Ich zähle sieben! Ok, vielleicht habe ich einen größeren
Bildschirm als du ;-)

Aber gut, lassen wir das. Die anderen Programmteile scheinen ja
goto-frei zu sein.

[Olaf (Gast)]

> Da hast Du auf Anhieb die Stellen entdeckt, die ich immer schon
> ändern wollte, aber dann doch wieder vergessen habe.

Jaja, ist immer unangenehm wenn fremde Leute in den eigenen Source 
schauen. :-)

Ich fand das Konzept mehrere Controller in einem Baustein zu haben auch 
schon immer ganz nett, allerdings fand ich die Vorstellung einen 
Controller mit etwas anderem als C zu programmieren auch absurd.
Von daher Teile ich deine Einstellung das so ein gcc ganz nett sein 
koennte und man vielleicht auch mal einen Blick auf die Propeller werfen 
sollte sobald der gcc vernuenftig laeuft.

Ich hab dazu aber mal eine Frage. (hab deinen Source nur ganz kurz 
ueberflogen) Mir ist nicht ganz klar mit welchen Strategien die einzelen 
C Funktionen auf die jeweiligen Prozessoren verteilt werden. Braucht es 
dafuer nicht eine Spracherweiterung? Und wie ist die 
Interprocesskomunikation gedacht?

> Vier? Ich zähle sieben! Ok, vielleicht habe ich einen größeren
> Bildschirm als du ;-)

Ich glaub ich hab die Labels gezaehlt. :)

Olaf

[(prx) A. K. (prx)]

Allerdings scheint mit der Ansatz von XMOS etwas umgänglicher als der 
Propeller-Chip - ausser was den Chip bzw. dessen Gehäuse angeht.

[R. M. (exp)]

///////////////////////////// propeller.h /////////////////////////////////

/**
 * start a cog with a parameter
 * the fields in parameter are:
 * 31:18   = 14-bit Long address for PAR Register
 * 17:4    = 14-bit Long address of code to load
 * 3       = New bit
 * 2:0     = Cog ID if New bit is 0
 * @param a - parameter value
 */
#define coginit(id, code, param) __builtin_propeller_coginit( \
                                 (((uint32_t)(param) << 16) & 0xfffc0000) \
                                 |(((uint32_t)(code) <<  2) & 0x0003fff0) \
                                 |(((id)                  ) & 0x0000000f) )

/**
 * start a new propeller cog 
 * @param code - address of PASM to load
 * @param par  - value of par parameter usually an address
 * @returns COG ID provided by the builtin function.
 */
#define cognew(code, param) coginit(0x8, (code), (param))

///////////////////////////////////////////////////////////////////////////

//////// Anwendungsbeispiel ///////////////////////////////////////////////

#define STACKSIZE 20


void start_lmm(void *func, int *stack_top)
{
    extern unsigned int _load_start_kernel[];

    /* push the code address onto the stack */
    --stack_top;
    *stack_top = (int)func;

    /* now start the kernel */
    cognew(_load_start_kernel, stack_top);
}


                                        
// startet die Task_PWM_Pin7() auf dem nächsten freien cog
start_lmm(Task_PWM_Pin7, cog_stack + STACKSIZE);

/////////////////////////////////////////////////////////////////////////////////

zur Interprozesskommunikation verwende ich z.Zt. globale struct
siehe zB. myrOBOT\lib\kernel.c

hoffentlich ist dort kein GOTO mehr zu finden ;-)

[W.S. (Gast)]

R. M. schrieb:
> hoffentlich ist dort kein GOTO mehr zu finden ;-)

Hä? Das Wörtchen "goto" gehört zum Kernvokabular von C und man sollte es 
auch benutzen dürfen, ohne rote Ohren zu bekommen. Basta.

Wer ist eigentlich so kühn, Konstrukte wie
while(1) {...}
besser zu finden als
Marke: .... goto Marke;
?
(Vorsicht! Wer while(1) {.... if(..) break; .. } wegen des break 
benutzt, ist m.E. bloß zu doof, die eigentliche (richtige) 
Abbruchbedingung zu formulieren.


W.S.

[Max (Gast)]

W.S. schrieb:
> Wer ist eigentlich so kühn, Konstrukte wie
> while(1) {...}
> besser zu finden als
> Marke: .... goto Marke;
> ?

Dijkstra.
"The unbridled use of the go to statement has as an immediate 
consequence that it becomes terribly hard to find a meaningful set of 
coordinates in which to describe the process progress. ... The go to 
statement as it stands is just too primitive, it is too much an 
invitation to make a mess of one's program."

---

>   The identifier in a goto statement shall name a label located
>   somewhere in the current function.

>   A continue statement shall appear only in or as a loop body.

>   A break statement shall appear only in or as a switch body or loop
>   body.

Goto ist also eine fette Keule gegenüber break/continue in seinen 
möglichen Verwendungen. Zudem existiert keine Verwendung die über 
bedingte (inklusive der Trivialbedingungen true und false) Schleifen 
nicht gelöst werden kann.
Goto erhöht daher die Komplexität (somit die Fehlerdichte) und liefert 
nur sehr geringen Mehrwert.

Für den größten Teil der Goto Nutzer halte ich diesen Stil als 
Sackgasse. Es sind seltenst diejenigen, die Erklären könnten, warum in 
ihrem Code goto's Vorteile die Nachteile überwiegen.
Kannst du einen solchen Fall konstruieren?

[Lästermaul (Gast)]

Hay R. M.

Für den Propeller Compiler den Alpha-Test machen und dann mit diesen 
Warmduschern über goto diskutieren? Wie passt das zusammen :-)
Ein echter Programmierer kümmert sich doch nicht um so eine 
Anfängerregel.

[Nils S. (kruemeltee)]

>Dieser GCC Port befindet sich noch im ALPHA RELEASE Stadium
>( GDB und eine IDE fehlen noch)
Ich frage mich immer wieder, warum so viele Leute meinen, eine IDE 
gehört zum Compiler oder umgekehrt herum und denken, dass das nicht 
komplett ist, wenn man einen einzelnen Compiler bekommt.

Ja, ich verwende vim und screen, fühl mich aber deswegen nicht elitär 
und hab auch nichts gegen IDEs und grafische Editoren, nur denke ich, 
sollten viele dieses "IDE+Compiler-Denken" ablegen ;)

Ich hab auch schon einiges mit dem Propeller gemacht, nur war ja bisher 
das Problem, dass es keinen guten, freien C Compiler gab. SPIN ist toll, 
aber schnarchlahm und sich in einen neuen Assembler für einen einzigen 
Chip einarbeiten wollte ich dann auch nicht...

Vielleicht wirds ja noch was, bevor er Großvater wird ;)
Gibt den Propeller ja auch schon gut 5 Jahre...

[Johann L. (gjlayde)]

Goto gehört zum Sprachumfang von C/C++.
Warum solle das ein α-Tester nicht testen dürfen?

[Johann L. (gjlayde)]

Was ist eigentlich "cog memory"?

[Nils S. (kruemeltee)]

Jeder der einzelnen Cores (COGs) hat seinen eigenen kleinen Speicher, 
afaik 2k.

[asd (Gast)]

Max schrieb:
> Für den größten Teil der Goto Nutzer halte ich diesen Stil als
> Sackgasse.

Ja.

> Es sind seltenst diejenigen, die Erklären könnten, warum in
> ihrem Code goto's Vorteile die Nachteile überwiegen.
> Kannst du einen solchen Fall konstruieren?

Gotos sind durchaus üblich und IMHO sinnvoll bei Funktionen die viele 
Fehlerbehandlungsfälle durchlaufen müssen, da wird mittels entspr. "goto 
error_out" der Code doch um einiges vereinfacht. In den meisten anderen 
Fällen sollte man goto aber in der Tat vermeiden.

[R. M. (exp)]

Nils S. schrieb:
>>Dieser GCC Port befindet sich noch im ALPHA RELEASE Stadium
>
>>( GDB und eine IDE fehlen noch)
>
> Ich frage mich immer wieder, warum so viele Leute meinen, eine IDE
>
> gehört zum Compiler oder umgekehrt herum und denken, dass das nicht
>
> komplett ist, wenn man einen einzelnen Compiler bekommt.


ich hab das erwähnt, wegen der Antwort vom Build Team auf die Frage,
was sie davon halten auf den propgcc in einem Forum namens
< Mikrokontroller.net> aufmerksam zu machen.

"
I think that sounds like a good idea.
It's certainly good to get more exposure for propgcc and more testers to 
help us improve it.
The only thing I ask is that you please make it clear that this is an 
alpha release.
It is missing some important features (like an IDE and debugger),
and people using it can expect to find bugs!

Thanks,

"

meine eigene Meinung:
a GUI is nice, but not essential

[Nils S. (kruemeltee)]

War ja kein Vorwurf direkt an dich, ich sehe das genauso wie du.