Wofür Propeller von Parallax ?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Olaf schrieb:
> BTW: Ich hab mich noch nie auf dem Level mit ARM beschaeftigt. Sollten
> die nicht mittlerweile auch Superscalar sein?

Auf der Mikrokontrollerebene hat der ARM Cortex-M7 Superskalarität.
Die großen Cortex-A schon länger, aber auch nicht jeder.

Beispiele:
Cortex-A5 ist es nicht, aber Cortex-A8 schon.

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

Olaf schrieb:
> BTW: Ich hab mich noch nie auf dem Level mit ARM beschaeftigt. Sollten
> die nicht mittlerweile auch Superscalar sein?

Konsequenter Smartphoneverächter? ;-)

Aber auch auch der Microcontroller-Core Cortex-M7 ist superskalar.

> Da ist es dann Aufgabe des Compilers
> seinen Code so anzuordnen das dies moeglichst gut klappt.

Wenn es darum geht, exakte Zeitbedingungen einzuhalten, bei denen ein 
Takt mehr oder weniger bereits eine Rolle spielt, wirds etwas 
aufwändiger und der Compiler ist keine Hilfe.

[Olaf (Gast)]

> Wenn es darum geht, exakte Zeitbedingungen einzuhalten, bei denen ein
> Takt mehr oder weniger bereits eine Rolle spielt, wirds etwas
> aufwändiger und der Compiler ist keine Hilfe.

Das stimmt natuerlich. Wenn man sowas echt braucht dann wird es Zeit die 
Aermel hochzukrempeln und wieder mal Assembler zu machen. Allerdings 
kann man das dann dem Propeller nicht vorwerfen. Nur bei einem 
Singlecore wird man es kaum schaffen auf IRQs zu verzichten und die kann 
man sich auch nicht erlauben. Bei so einem Multicore wie dem Propeller 
schon.

Olaf

[zonk (Gast)]

Der Propeller hat ja Interrupts. 3 Stück per core

[mh (Gast)]

Olaf schrieb:
> Allerdings kann man das dann dem Propeller nicht vorwerfen.
Wem soll man es dann vorwerfen? Multiprozesskommunikation ist 
normalerweise kompliziert genug. Da kann ich gut darauf verzichten den 
Teil in Asm zu schreiben, um die volle Kontrolle über jeden Takt zu 
haben.

[zonk (Gast)]

mh schrieb:
> Die Frage geistert seit heut morgen in meinem Kopf rum, nachdem ich
> einen "bank conflict" in einem CUDA Kernel fixen musste. Ich konnte auf
> die schnelle keine zufriedenstellende Antwort finden.

Naja, beim P2 ist der Haupt-RAM in 8 Bänke aufgeteilt..So können alle 
Cores gleichzeitig im RAM lesen oder schreiben, jedoch nur jeweils in 
,,ihrer" Bank, welche nach jedem 2. Takt weiterrotiert zum 
nächsten...Also im Schlimmsten Fall heisst das 7 Slots abwarten , im 
Optimalfall (sequenzielles Zugreifen auf aufeinanderfolgende 
Speicheradressen) muss garnicht gewartet werden. Wenn ich jetzt Code 
ausführe und dann ein Branch kommt muss also im Mittel 3,5 Slots 
abgewartet werden. Trotzdem kann aber zwischendrin jeder Core auf seinen 
eigenen kleinen Speicher zugreifen. DMA macht hier also Sinn..Ganze 
Streams können flott in den Core-Speicher verschoben werden und dort 
anschliessend bearbeitet werden, wie ein Cache im Grunde, nur zu Fuß 
programmiert

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

Aber auch hier wird, wenn ich es richtig verstanden habe, die 
Zugriffszeit eines COGs auf das Hub-Memory nicht von Zugriffen anderer 
COGs beeinflusst.

[Μαtthias W. (matthias)]

Olaf schrieb:
> BTW: Ich hab mich noch nie auf dem Level mit ARM beschaeftigt. Sollten
> die nicht mittlerweile auch Superscalar sein?

Aber nur in der A-Reihe. Die Cortex-M nicht. Und das ist meiner Meinung 
nach auch für die typischen Anwendungen ganz passend.

Matthias

[mh (Gast)]

zonk schrieb:
> Naja, beim P2 ist der Haupt-RAM in 8 Bänke aufgeteilt..So können alle
> Cores gleichzeitig im RAM lesen oder schreiben, jedoch nur jeweils in
> ,,ihrer" Bank, welche nach jedem 2. Takt weiterrotiert zum
> nächsten...Also im Schlimmsten Fall heisst das 7 Slots abwarten , im
> Optimalfall (sequenzielles Zugreifen auf aufeinanderfolgende
> Speicheradressen) muss garnicht gewartet werden.
Es wird also noch komplexer. Wenn ich daraus einen Nutzen ziehen möchte, 
muss ich meine Datenstrukturen über die Bänke verteilen und muss dann 
trotzdem auf auf den richtigen Startpunkt warten.

(prx) A. K. schrieb:
> Aber auch hier wird, wenn ich es richtig verstanden habe, die
> Zugriffszeit eines COGs auf das Hub-Memory nicht von Zugriffen anderer
> COGs beeinflusst.
Wenn das nicht der Fall wäre, könnte man die Zugriffszeiten auch per 
Zufallszahlengenerator erzeugen ;-)

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

Μαtthias W. schrieb:
> Aber nur in der A-Reihe. Die Cortex-M nicht.

Wie schon aufgeführt wurde, ist der Cortex M7 Kern sehr wohl superskalar 
mit bis zu 2 Befehlen pro Takt. Allerdings im Unterschied zu vielen 
Cortex A Kernen ist er in-order.

[mh (Gast)]

(prx) A. K. schrieb:
> Μαtthias W. schrieb:
>> Aber nur in der A-Reihe. Die Cortex-M nicht.
>
> Wie schon zweimal aufgeführt wurde, ist der Cortex M7 Kern sehr wohl
> superskalar mit 2 Befehlen pro Takt. Allerdings im Unterschied zu vielen
> Cortex A Kernen ist er in-order.

Den muss ich mir demnächst auch mal angucken. Sorgt der Kern selbst 
dafür, dass die beiden Befehle keine Konflikte auslösen und tatsächlich 
in-order sind?

[Karl (Gast)]

Olaf schrieb:
> BTW: Ich hab mich noch nie auf dem Level mit ARM beschaeftigt. Sollten
> die nicht mittlerweile auch Superscalar sein?

Arm an sich bezeichnet in diesem Zusammenhang nur eine ISA. Die konkrete 
Implementierung setzt diese ISA um. Dabei kann alles mögliche gemacht 
werden. Z.b. ist ein Cortex M0 sicher nicht superskalar, ein M7 aber 
schon. Als Anwender merkt man davon nichts, außer dass der M7 wesentlich 
mehr Instructions per clock (IPC) hat als der M0. Wenn man darauf von 
Hand optimiert geht sicher noch was, allerdings wird es dann schnell 
Controller-spezifisch, weil die Anbindung und Geschwindigkeit von RAM 
und flash manchmal sehr unterschiedlich sind. Der CM7 von atmel kann 
hier ganz anders sein als der von ST. Dazu kommt, dass die effektive 
Nutzung der Peripherie wichtiger ist als der Code selbst. Die ITCM und 
DTCM und ihre zugreifbarkeit per DMA sind hier beispielsweise zu nennen.

Sorry für OT.

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

mh schrieb:
> Den muss ich mir demnächst auch mal angucken. Sorgt der Kern selbst
> dafür, dass die beiden Befehle keine Konflikte auslösen und tatsächlich
> in-order sind?

Zweifellos.

[Μαtthias W. (matthias)]

(prx) A. K. schrieb:
> Μαtthias W. schrieb:
>> Aber nur in der A-Reihe. Die Cortex-M nicht.
>
> Wie schon aufgeführt wurde, ist der Cortex M7 Kern sehr wohl superskalar
> mit bis zu 2 Befehlen pro Takt. Allerdings im Unterschied zu vielen
> Cortex A Kernen ist er in-order.

Tatsächlich. Da lag ich falsch. Danke für den Hinweis.

[zonk (Gast)]

mh schrieb:
> Es wird also noch komplexer. Wenn ich daraus einen Nutzen ziehen möchte,
> muss ich meine Datenstrukturen über die Bänke verteilen und muss dann
> trotzdem auf auf den richtigen Startpunkt warten.

das Konzept ist eben daraufhin optimiert, komplette Datenpakete zu 
händeln. Per DMA kann auch direkt vom HUB-RAM auf die I/O-Pins gestreamt 
werden(SPI,VGA, oder Ähnliches) oder ein Audiostream von einem der ADCs 
eingelesen werden. Also Datenverarbeitung, sagen wir FFT wäre nur 
sinnvoll wenn es innerhalb des COG-RAMs passiert.(das sind je 4kByte 
wenn ich das hier richtig sehe)

[mh (Gast)]

zonk schrieb:
> das Konzept ist eben daraufhin optimiert, komplette Datenpakete zu
> händeln.
Das verstehe ich nicht. Ich würde sagen für den Propeller2, wurde der 
erreichbare Speicherduchsatz des Hubs maximiert.

Vielleich verstehe ich das aber noch immer falsch. Wenn ich ein Array 
mit 10 Werten von cog1 effizient in den hub kopieren will kann ich 
entweder:
-Warten bis cog1 an der Reihe ist, in die Ziel Bank des hubs zu 
schreiben. Ab da
muss cog1 für jeden weiteren Wert 8 Takte warten, (gültig für Propeller1 
und 2), oder
-die 10 Werte über mehrere Speicherbänke im Hub verteilen und dann in 
jedem Takt in die richtige Bank schreiben (nur Propeller2).

Das würde für mich mehr Sinn ergeben, wenn im Hubspeicher die Bank mit 
jeder Adress wechselt, also Bank = Adresse % 8. Ist das vielleicht der 
Ausweg?

[zonk (Gast)]

Es gibt 8 COGs und 8 Speicherbänke. Das rotiert durch. Die Daten sind 
verteilt Adresse 0 auf Bank 0, Adresse 1 auf Bank 1......Adresse 7 auf 
Bank 7..Adresse 8 wieder auf Bank0...Somit wird durch das weiterschalten 
der Bänke erreicht, dass jeder COG ohne Verzögerung auf ganze 
Arrays/Strings/Streams mit aufsteigenden Speicheradressen zugreifen 
kann. Auch könnten 8 COGS auf die selbe Adresse zugreifen jedoch 
zeitlich versetzt eben....

[R. M. (n_a_n)]

Könnte evtl für jemand interessant sein:
https://propeller.parallax.com/p2.html

Praxisbericht:

Ich habe mir vor ca. 1 Jahr das Eval Board und die Zusatzplatinen 
besorgt.
(z.B. die VGA Zusatzplatine beinhaltet nur Mechanik, nämlich die VGA - 
Buchse,
4x Cinch, eine Audio IN und eine Audio OUT Buchse)

Als Programmiersprachen standen damals das proprietäre SPIN, ASM, C, 
Forth und
BASIC zur Verfügung.

Als einen der ersten Versuche habe ich ein simples ping- game mit 
ausgabe auf einem VGA Monitor umgesetzt.

Die elementaren Graphicroutinen sind in SPIN geschrieben und mir von 
einem Forummitglied zur Verfügung gestellt worden.
Dann gibt es einen C-Wrapper der mir die Funktionen für C zur Verfügung 
stellt.
Das Hauptprogramm habe ich in C implementiert.

Es werden 2 cogs benutzt, einer für Graphic und einer für die 
Spiellogik.

Das Spiel läuft absolut zügig und ruckelfrei.

Ich habe mich dann längere Zeit nicht mehr mit dem P2 beschäftigt,
werde aber demnächst wieder weitermachen (HOBBYMÄSSIG!)

[zonk (Gast)]

Das ist der Punkt. Als Hobby ist das super aber bevor das eine Firma 
hernimmt, setzt sie eher auf ein FPGA

[mh (Gast)]

zonk schrieb:
> Es gibt 8 COGs und 8 Speicherbänke. Das rotiert durch. Die Daten sind
> verteilt Adresse 0 auf Bank 0, Adresse 1 auf Bank 1......Adresse 7 auf
> Bank 7..Adresse 8 wieder auf Bank0...Somit wird durch das weiterschalten
> der Bänke erreicht, dass jeder COG ohne Verzögerung auf ganze
> Arrays/Strings/Streams mit aufsteigenden Speicheradressen zugreifen
> kann. Auch könnten 8 COGS auf die selbe Adresse zugreifen jedoch
> zeitlich versetzt eben....

Ok, also wirklich Bank = Adresse % 8 oder ähnlich. Vielen Dank!

[void (Gast)]

(prx) A. K. schrieb:
> Ja, keine Arbitrierung, sondern Rotation wie bei einem Propeller.
> Dadurch wird es deterministisch. Mit Arbitrierung käme ein faktisch
> unbestimmbarer Zeitfaktor hinein.

Glückwunsch (prx) A. K., du hast soeben Round-robin Arbitrierung 
erfunden.

Olaf schrieb:
> BTW: Ich hab mich noch nie auf dem Level mit ARM beschaeftigt. Sollten
> die nicht mittlerweile auch Superscalar sein?

Solltest du aber mal machen Olaf. Wie üblich gilt da die Antwort: "kommt 
drauf an". Oder genauer ARM Cortex M/R/A: fast-nein*/ja-aber**/ja***.
*   Cortex-M nein, nicht superscalar. Ausnahme M7 bestätigt die Regel.
**  Cortex-R ja, aber nur in-order execution
*** Cortex-A ja, out-of-order execution.

Das erhebt keinen Anspruch auf Vollständigkeit/Richtigkeit. Es mag im 
ARM Zoo, wie schon beim M7 gesehen, noch ein paar mehr Ausnahmen von der 
Regel geben...

[Rapper B (Gast)]

Da habe ich mit meiner Sinnfrage zum Propeller echt was losgetreten haha

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

void schrieb:
> Glückwunsch (prx) A. K., du hast soeben Round-robin Arbitrierung
> erfunden.

Danke der Ehre. Der Begriff Arbitrierung wird üblicherweise für Fälle 
verwendet, bei denen mehrere wollen, aber nicht gleichzeitig können. 
Hier hingegen wird auch verteilt, wenn niemand will und COGs müssen u.U. 
warten, obwohl Zugriff möglich wäre.

[chris_ (Gast)]

R.M. schrieb
>Praxisbericht:
>Ich habe mir vor ca. 1 Jahr das Eval Board und die Zusatzplatinen
>besorgt.
>...

Danke dafür, dass Du etwas Code gepostet hast, da bekommt man eine 
echten Eindruck.
War das Eval Board vor einem Jahr schon verfügbar? Ich dachte, das sei 
jetzt erst raus gekommen.

>Die elementaren Graphicroutinen sind in SPIN geschrieben und mir von
>einem Forummitglied zur Verfügung gestellt worden.
>Dann gibt es einen C-Wrapper der mir die Funktionen für C zur Verfügung
>stellt.
>Das Hauptprogramm habe ich in C implementiert.

Beim SPIN-Teil müsste man eventuell erwähnen, dass dort die schnellen 
Routinen in Propeller-Assembler geschrieben sind.
Welcher C-Compiler wird den verwendet? Beim Propeller1 war das Catalina, 
aber lief auf Grund der damaligen Architektur eher langsam.

[zonk (Gast)]

Das Board welches es jetzt gibt ist das mit der finalen Revision des 
Chips(Rev.C), bei dem alle Mängel und bugs behoben wurden.

chris_ schrieb:
> War das Eval Board vor einem Jahr schon verfügbar? Ich dachte, das sei
> jetzt erst raus gekommen.

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

zonk schrieb:
> bei dem alle Mängel und bugs behoben wurden

Sowas gibts wirklich? Das wäre ein echtes Plus. ;-)

[zonk (Gast)]

Naja, der Propeller 2 war in Fankreisen schon seit Jahren als fpga-Modul 
unterwegs. Der Entwickler setzt halt auf Transparenz und auf seine 
Community. Deshalb gab's da jetzt relativ gute Ergebnisse mit den Chips. 
Paar Fehler gab's aber halt doch bei der Konvertierung in's Silizium, 
weshalb 2 ,,respins" gemacht wurden mussten. Alles in Vollendung bis 
in's Detail;)

[R. M. (n_a_n)]

chris_ schrieb:
> R.M. schrieb
>>Praxisbericht:
>>Ich habe mir vor ca. 1 Jahr das Eval Board und die Zusatzplatinen
>>besorgt.
>>...
>
> Danke dafür, dass Du etwas Code gepostet hast, da bekommt man eine
> echten Eindruck.
> War das Eval Board vor einem Jahr schon verfügbar? Ich dachte, das sei
> jetzt erst raus gekommen.
>
>>Die elementaren Graphicroutinen sind in SPIN geschrieben und mir von
>>einem Forummitglied zur Verfügung gestellt worden.
>>Dann gibt es einen C-Wrapper der mir die Funktionen für C zur Verfügung
>>stellt.
>>Das Hauptprogramm habe ich in C implementiert.
>
> Beim SPIN-Teil müsste man eventuell erwähnen, dass dort die schnellen
> Routinen in Propeller-Assembler geschrieben sind.
> Welcher C-Compiler wird den verwendet? Beim Propeller1 war das Catalina,
> aber lief auf Grund der damaligen Architektur eher langsam.

Das Evalboard war/ist Revision B, ich habe es über Beziehungen aus USA 
bekommen.
Der C-Compiler heißt (unglücklicher) Weise fastspin. Ich verwende die 
Kommandozeilenversion. Es gibt aber auch eine IDE.
Der gcc, wie beim P1, ist leider noch nicht soweit.

edit:
ach ja, der Compiler liegt als Source vor, ich habe Linux, für Windows 
glaube ich auch als binary.
Es ist sehr einfach den Compiler zu bauen: make ist alles

[R. M. (n_a_n)]

Wie schon erwähnt, ich hatte eine längere Pause und habe heute die 
aktuellste Version geholt und gebaut.

reinhard@reinhard-TUXEDO:~/Schreibtisch/Propeller2/spin2cpp-5.0.3$ make
mkdir -p ./build
bison -Wno-deprecated -D parse.error=verbose -D api.prefix={spinyy} -t -b ./build/spin -d frontends/spin/spin.y
frontends/spin/spin.y: Warnung: 26 Schiebe/Reduzier-Konflikte [-Wconflicts-sr]
bison -Wno-deprecated -D parse.error=verbose -D api.prefix={basicyy} -t -b ./build/basic -d frontends/basic/basic.y
frontends/basic/basic.y: Warnung: 15 Schiebe/Reduzier-Konflikte [-Wconflicts-sr]
bison -Wno-deprecated -D parse.error=verbose -D api.prefix={cgramyy} -t -b ./build/cgram -d frontends/c/cgram.y
frontends/c/cgram.y: Warnung: 3 Schiebe/Reduzier-Konflikte [-Wconflicts-sr]
gcc -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/lexer.o -c frontends/lexer.c
gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/symbol.o -c symbol.c
gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/ast.o -c ast.c
gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/expr.o -c expr.c
gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/dofmt.o -c util/dofmt.c
gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/flexbuf.o -c util/flexbuf.c
gcc -MMD -MP -g -Wall -I. -I./build -DFLEXSPIN_BUILD -o build/lltoa_prec.o -c util/lltoa_prec.c
 ... ... ...

reinhard@reinhard-TUXEDO:~/Schreibtisch/Propeller2/spin2cpp-5.0.3$ PATH="$HOME/Schreibtisch/Propeller2/spin2cpp-5.0.3/build:$PATH"
reinhard@reinhard-TUXEDO:~/Schreibtisch/Propeller2/spin2cpp-5.0.3$ fastspin
fastspin: Befehl nicht gefunden.

FASTSPIN HEISST JETZT FLEXSPIN !!!!

reinhard@reinhard-TUXEDO:~/Schreibtisch/Propeller2/spin2cpp-5.0.3$ flexspin
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version 5.0.3 Compiled on: Jan  1 2021
usage: flexspin [options] filename.spin | filename.bas
  [ -h ]              display this help
  [ -L or -I <path> ] add a directory to the include path
  [ -o <name> ]      set output filename to <name>
  [ -b ]             output binary file format
  [ -e ]             output eeprom file format
  [ -c ]             output only DAT sections
  [ -l ]             output DAT as a listing file
  [ -f ]             output list of file names
  [ -g ]             enable debug statements
  [ -q ]             quiet mode (suppress banner and non-error text)
  [ -p ]             disable the preprocessor
  [ -D <define> ]    add a define
  [ -u ]             ignore for openspin compatibility (unused method elimination always enabled)
  [ -2 ]             compile for Prop2
  [ -O# ]            set optimization level:
          -O0 = no optimization
          -O1 = basic optimization
          -O2 = all optimization
  [ -H nnnn ]        set starting hub address
  [ -E ]             skip initial coginit code (usually used with -H)
  [ -w ]             compile for COG with Spin wrappers
  [ -Wall ]          enable warnings for language extensions and other features
  [ -Werror ]        make warnings into errors
  [ -C ]             enable case sensitive mode
  [ -x ]             capture program exit code (for testing)
  [ --code=cog ]     compile for COG mode instead of LMM
  [ --fcache=N ]     set FCACHE size to N (0 to disable)
  [ --fixedreal ]    use 16.16 fixed point in place of floats
  [ --lmm=xxx ]      use alternate LMM implementation for P1
           xxx = orig uses original flexspin LMM
           xxx = slow uses traditional (slow) LMM
  [ --version ]      just show compiler version



reinhard@reinhard-TUXEDO:~/Schreibtisch/Propeller2/testbench2/pong$ flexspin -2 pingpong.c graphictools.c
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version 5.0.3 Compiled on: Jan  1 2021
pingpong.c
|-p2videodrv.spin2
graphictools.c
|-p2videodrv.spin2
memset.c
pingpong.p2asm
Done.
Program size is 347256 bytes

[chris_ (Gast)]

>von R. M. (n_a_n)
>01.01.2021 10:26

>Wie schon erwähnt, ich hatte eine längere Pause und habe heute die
>aktuellste Version geholt und gebaut.

Interessant ... könntest Du mal diesen Benchmark hier laufen lassen?:
Beitrag "Re: STM32 Arduino"

Mich würde der Vergleich zu den genannten Prozessoren interessieren.

[Andi (Gast)]

chris_ schrieb:
> Interessant ... könntest Du mal diesen Benchmark hier laufen lassen?:
> Beitrag "Re: STM32 Arduino"
>
> Mich würde der Vergleich zu den genannten Prozessoren interessieren.

Der Propeller hat keine Hardwareunterstützung für Float, daher ist 
dieser Benchmark etwas unfair. Ein schnelles IIR Filter würde man wohl 
von Hand optimieren und die 16 Bit DSP Befehle oder ein Pipelined Cordic 
verwenden. Der C Compiler erlaubt FixedPoint (16.16) statt Float zu 
verwenden, was erheblich schneller ist, wenn's die Anwendung erlaubt.

Einfach so von deinem C Source compiliert erhalte ich folgende 
Ergebnisse für time/sample:
Float library mit 250 MHz: 38 us
FixedPoint library mit 250 MHz: 9 us

[mh (Gast)]

chris_ schrieb:
> Mich würde der Vergleich zu den genannten Prozessoren interessieren.

Das ist eher ein Compilervergleich, mit der Hoffnung, dass der Compiler 
den Inhalt von millis() nicht kennt, wenn er loop compiliert.

[R. M. (n_a_n)]

chris_ schrieb:
> Interessant ... könntest Du mal diesen Benchmark hier laufen lassen?:
> Beitrag "Re: STM32 Arduino"
>
> Mich würde der Vergleich zu den genannten Prozessoren interessieren.

Hallo chris, ich habe momentan die Hardware nicht bei mir in der 
Wohnung.
Aber hier sind einige benchmark Ergebnisse beschrieben (Laufzeit und 
Speicher),
die die verschiedenen vorhandenen Compiler für P2 vergleichen.

https://forums.parallax.com/discussion/171960/c-and-c-for-the-propeller-2

[R. M. (n_a_n)]

Was ich auf die Schnelle noch zeigen kann:
Ich habe ein IIR HP Filter für Audiobereich implementiert und gemessen.
Das waren meine ersten Versuche mit dem neuen chip.

https://forums.parallax.com/discussion/171100/fastspin-is-really-fast#latest

[R. M. (n_a_n)]

Ach ja, da hab ich noch was gefunden.
Das waren wirklich die allerersten Schritte, noch in Assembler.

https://forums.parallax.com/discussion/170987/simple-iq-modulation-with-cordic-finished#latest

[chris_ (Gast)]

R. M. (n_a_n)
>Hallo chris, ich habe momentan die Hardware nicht bei mir in der
>Wohnung.

Danke für die Antwort. Falls Du mal an die Hardware kommen solltest, 
würde mich genau das Ergebnis für den genannten C-Code interessieren.

[chris_ (Gast)]

>Einfach so von deinem C Source compiliert erhalte ich folgende
>Ergebnisse für time/sample:
>Float library mit 250 MHz: 38 us
>FixedPoint library mit 250 MHz: 9 us

Ahh ... hab's nicht richtig gelesen. Das Ergebnis ist also

time/sample us:
Arduino UNO ( 16Mhz )         us: 127
STM32 BluePill ( 72MHz )      us: 16
Propeller2 ( 250MHz )         us: 9
STM32F4 Discovery ( 168MHz? ) us: 4

[MCUA (Gast)]

> Ein Programmierer der nicht ohne INTs auskommt ist unbrauchbar.
Völliger Quatsch.

INTs/Events (von aussen kommend) sind durch das Gesamt-System bestimmt.
Ohne solch INTs/Events-Bearbeitung wäre viel höhere CPU-Rechenleistung 
(oder sep. Hardware, DMA usw (*)) erforderlich.
Selbst dann stellt sich die Frage wie genau diese Werte in den zentr. 
Speicher kommen; darin liegt der Flaschenhals (auch wenn man es 
Propeller nennt).


> Wenn man also den P2 als Peripherie Baustein an einen Bus hängen will,
> dabei auf die fallende Flanke des ChipSelect wartet, wird der nächste
> Befehl zum einlesen der Daten und/oder Adresse innerhalb von 2
> Taktzyklen ausgeführt.
Innerh. 2 Cycl. wird die CPU es nicht hinkriegen.
(Die ist da nicht besser als andere auch, eher schlechter)

[Carl D. (jcw2)]

Interrupt kann man eben HW-seitig unterschiedlich implementieren. 
Entweder man baut eine CPU, die auf Kommando mal pausieren kann, um 
schnell mal ein anderes Stück Code auszuführen, oder man hat mehr als 
eine CPU und "Interrupt" realisiert man durch "Polling".
Man hat dann zwar das neue Problem den Zugriff der mehreren Kerne auf 
gemeinsame Resourcen in den Griff zu bekommen, dafür hat man entweder 
extrem schnell reagierende ISRs, die brauchen nämlich weder 
"Context-Save", noch müssen sie zwingen auf Shared Resoutcen zugreifen.
Oder man braucht nicht alle 8 Cores für ISRs und kann sie einfach zum 
parallel rechnen nutzen.
Das Shared Resourcen-Problem hat man übrigens auch wenn Peripherie per 
DMA selbstständig Daten vom/zum Speicher transferiert. Nur muß man zum 
Bus-Zyklus stehlen keine CPU-Register benutzen und natürlich 
sicher/wiederherstellen.
Welcher Ansatz besser ist, hängt eher vom Problem ab. Und von der Frage, 
mit was man mehr Erfahrung hat.

[Olaf (Gast)]

> gemeinsame Resourcen in den Griff zu bekommen, dafür hat man entweder
> extrem schnell reagierende ISRs, die brauchen nämlich weder
> "Context-Save", noch müssen sie zwingen auf Shared Resoutcen zugreifen.

Der Context Switch ist kein Problem. Es gibt CPUs die koennen einfach 
ihren Registersatz umschalten. (SH2A, Z80) Allerdings musst du bei echt 
parallel Cores natuerlich kein Gedanken daran verschwenden was du alles 
in der Reaktion auf eine externes Ereignis an Zeit verbraten tust. 
Deshalb hat das seinen Charme.

Olaf

[Ale (Gast)]

I brauche nicht noch eine Platine aber ich habe so gute Erfahrungen mit 
dem P1 gemacht... Cluso's Platinen sind so schön, ich mag daß für VGA 
schon eine Footprint auf der Platine gibt. ManAtWork's Platine hat alle 
PINs auf .1" raster... schwer sich zu entscheiden...

[Nick M. (Gast)]

MCUA schrieb:
>> Ein Programmierer der nicht ohne INTs auskommt ist unbrauchbar.
> Völliger Quatsch.

Ich hab das nicht aus Versehen geschrieben. So ein Programmierer ist 
geistig so festgefahren, dass er sich nichts Anderes vorstellen kann. 
Flexibel geht Anders.

Wenn schon die Zweifel kommen, dass ein INT nicht besser gehandhabt 
wird, wie ist es denn bei 5 INTs gleichzeitig? Die 5 müssen dann auch 
noch ihre Daten wegbekommen.
Da nützen die INT-Prioritäten beim klassischen µC dann auch nichts mehr, 
denn 4 INT-Ebenen blockieren die mit der niedrigsten Priorität. Und dazu 
eine belastbare Aussage bzgl. Latenzzeit für den niedrigsten INT zu 
machen, mit der Hoffnung dass nicht noch ein INT zwischenfeuert ... das 
witz witzig!

[MCUA (Gast)]

> Da nützen die INT-Prioritäten beim klassischen µC dann auch nichts mehr,
> denn 4 INT-Ebenen blockieren die mit der niedrigsten Priorität.
Du hast wohl das INT-Konzept nichtmal verstanden.
Der INT mit niedrig(st)er Prio KANN warten, eben weil die Bearbeitung 
nicht so dringend ist.
Und wenn mehrere mit sehr hoher Prio bearbeitet werden müss(t)en, geht 
das (wie bereits geschrieben) mit sep. Hardware (was aber definitiv 
aufwändiger und teurer ist).
Also, je mehr INTs / INT-Ebenen eine CPU verarbeiten kann, desto besser.

[MCUA (Gast)]

> Der Context Switch ist kein Problem. Es gibt CPUs die koennen einfach
> ihren Registersatz umschalten.
Die Anzahl der Registersätze ist (oft nur auf 2) begrenzt.

[MCUA (Gast)]

> Allerdings musst du bei echt
> parallel Cores natuerlich kein Gedanken daran verschwenden was du alles
> in der Reaktion auf eine externes Ereignis an Zeit verbraten tust.
100 Cores sind nicht schneller als einer, wenn ein Event einem 
bestimmten Thread (damit einem bestimmten Core) zugewiesen werden muss.

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

Die Reaktionszeit ist bei wartenden Cores (Propeller) oder Kontexten 
(XMOS) kürzer als bei klassischen Interrupts.

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

MCUA schrieb:
> Die Anzahl der Registersätze ist (oft nur auf 2) begrenzt.

Das war der Charme von TIs 9900 Architektur. Genau genommen gab es nur 
einen Registersatz, aber das waren gerade einmal 3 Stück: Program 
Counter, Status Register, Workspace Pointer. Was in den Befehlen als 
Register angesprochen wurde lag im RAM, via Workspace Pointer. Also nur 
von der RAM-Kapazität begrenzt. Dementsprechend flott waren Interrupts.

[MCUA (Gast)]

..sozusagen Definitionssache, was 'Register' ist.
Wenn die CPU (CISC) als Source/Destination jeweils auch MEM-Bereich 
nutzen kann/könnte (für alle Befehle, nicht nur für wenige) hätte man 
quasi unendl. viele Register. ... ist also Frage des CPU-Befehls-Satzes
(wobei nat. ein grosser MEM-Bereich weniger schnell angesprochen werden 
kann als ein sehr kleiner Bereich (die man dann womöglich 'Registersatz' 
nennt))

[Nick M. (Gast)]

MCUA schrieb:
> Der INT mit niedrig(st)er Prio KANN warten, eben weil die Bearbeitung
> nicht so dringend ist.

KANN, und wie lange? Falls du das mit den INTs wirklich verstanden hast. 
Denn wenn er könnte, warum ist er dann ein INT?

[Nick M. (Gast)]

MCUA schrieb:
> wenn ein Event einem
> bestimmten Thread (damit einem bestimmten Core) zugewiesen werden muss.

Dieser eine ganz bestimmte wartet nur auf diese eine ganz bestimmte 
Event.
Beim xmos ist das noch flexibler.

[mh (Gast)]

(prx) A. K. schrieb:
> Die Reaktionszeit ist bei wartenden Cores (Propeller) oder Kontexten
> (XMOS) kürzer als bei klassischen Interrupts.
Das hängt wohl ganz stark vom verwendeten Core und dessen Takt ab.

Nick M. schrieb:
> MCUA schrieb:
>> Der INT mit niedrig(st)er Prio KANN warten, eben weil die Bearbeitung
>> nicht so dringend ist.
>
> KANN, und wie lange? Falls du das mit den INTs wirklich verstanden hast.
> Denn wenn er könnte, warum ist er dann ein INT?
Der Entwickler sollte es wissen. Genauso wie der Entwickler auf einem 
Propeller wissen muss, auf wieviele Events er maximal gleichzeitig 
warten muss. 8 Kerne bringen nichts, wenn man auf 9 Events direkt 
reagieren können muss.

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

mh schrieb:
> 8 Kerne bringen nichts, wenn man auf 9 Events direkt
> reagieren können muss.

Zumindest wenn diese 9 Events voneinander unabhängig und zeitkritisch 
sind. Wenn einige davon nur bei verschiedenen Zuständen derselben 
Statusmaschine auftreten, lassen sie sich prinzipiell in einem Core 
zusammenfassen.

Aber natürlich ist gerade eine Architektur wie bei den Propellern mit 
einer harten Grenze versehen. Die erwähnte fehlende Skalierbarkeit.

[mh (Gast)]

(prx) A. K. schrieb:
> mh schrieb:
>> 8 Kerne bringen nichts, wenn man auf 9 Events direkt
>> reagieren können muss.
>
> Zumindest wenn diese 9 Events voneinander unabhängig und zeitkritisch
> sind. Wenn einige davon nur bei verschiedenen Zuständen derselben
> Statusmaschine auftreten, lassen sie sich prinzipiell in einem Core
> zusammenfassen.

Klar, das gleiche gilt aber genauso für Interrupts. Das ganze hängt halt 
von der Anwendung ab. Und ich habe hier immer noch kein Beispiel für 
eine Anwendung gesehen, wo der Propeller duch seine Architektur im 
Vorteil ist.

[Nick M. (Gast)]

mh schrieb:
> 8 Kerne bringen nichts, wenn man auf 9 Events direkt
> reagieren können muss.

Diese 8 Kerne können jedenfalls 8 Events sofort abarbeiten.
Interruptgesteuert werden die 9 Events sequentiell abgearbeitet.

Wer der Beiden braucht länger?

[mh (Gast)]

Nick M. schrieb:
> mh schrieb:
>> 8 Kerne bringen nichts, wenn man auf 9 Events direkt
>> reagieren können muss.
>
> Diese 8 Kerne können jedenfalls 8 Events sofort abarbeiten.
> Interruptgesteuert werden die 9 Events sequentiell abgearbeitet.
>
> Wer der Beiden braucht länger?

Ach Nick, ich habe keine Lust mehr mit dir zu diskutieren, wenn du dir 
immer nur einzelne Sätze herauspickst, statt komplette Aussagen.

[Nick M. (Gast)]

mh schrieb:
> Ach Nick, ich habe keine Lust mehr mit dir zu diskutieren, wenn du dir
> immer nur einzelne Sätze herauspickst, statt komplette Aussagen.

Ich hab mich auf eine Kernaussage von dir bezogen.
Ob du über deine eigenen Aussagen diskutieren willst oder nicht, 
überlass ich dir gerne.

Allerdings würde ich dir dann auch mehr Konsequenz in bezug auf "ich hab 
keine Lust" nahelegen.

[Olaf (Gast)]

> > Die Anzahl der Registersätze ist (oft nur auf 2) begrenzt.

> Das war der Charme von TIs 9900 Architektur. Genau genommen gab es nur
> einen Registersatz, aber das waren gerade einmal 3 Stück: Program

SH2A: 16Banks

Olaf

[Nick M. (Gast)]

mh schrieb:
> Und ich habe hier immer noch kein Beispiel für
> eine Anwendung gesehen, wo der Propeller duch seine Architektur im
> Vorteil ist.

Wir können uns zumindest auf eines einigen:
Die Dokumentation ist ohne Zweifel ungenügender, unprofessioneller Mist.


So, hier ein ganz konkretes Beispiel:

Eine 3-Achs Digitalanzeige (einer Fräsmaschine). Die Positionssignale 
kommen von Glasmaßstäben mit Quadraturencoder-Ausgängen. Die Auflösung 
der GMS ist 1µm.
Es werden also 3 QE-Eingänge benötigt.
Mir ist bekannt, dass es dafür vom ic-haus schöne Chips gibt, die sind 
aber zusätzlich.

Das hat der Propeller:
Quadrature decoding with 32-bit counter, both position and velocity 
modes 1*)

320 MHz Taktfrequenz 2*)

Befehl SPM_CNT_QUAD setzt QE-Decoder Eingang 3*)

Ich konnte nur ein Bsp für den QE-Eingang im Velocity-mode finden *4). 
Ich will aber position mode, velocity mode wäre für die innere 
Regelschleife eines PID-Reglers für ein Servo ideal.

32 Bit counter genügt (bei 1 µm) für etwa 4,3 km, was deutlich über dem 
üblichen Bereich von GMS ist.

Ich kann jetzt nur annehmen was die maximale Eingangsfrequenz für den 
QE-Eingang ist. Ich nehme 80 MHz an, 1/4 er max. Taktfrequenz. Daraus 
ergibt sich eine maximale Verfahrgeschwindigkeit von 4800 m/min. 80 
m/min ist schon absurd hoch, 20 m/min gilt als sehr schnell.

Der Abstand zu realistischen Grenzen ist mehrere Größenordnungen.
Der Rest um die Werte auf einem Display darstellen zu können sollte ohne 
Diskussion mit 5 weiteren Kernen wohl machbar sein.


1*) https://www.parallax.com/propeller-2/   Reiter 64 Smart I/O Pins
2*) https://forums.parallax.com/discussion/170380/new-p2-silicon
3*) https://forums.parallax.com/discussion/170380/new-p2-silicon/p25
4*) 
https://forums.parallax.com/discussion/171659/baffled-by-prop-2-quadrature-encoder

// ========================================================
Noch ein Beispiel, weil ich das eben gefunden habe:
PID-Regler für einen DC-Servomotor, innere Regelschleife.
Der Servomotor hat einen QE-Ausgang. Das Eingangssignal ist 
Geschwindigkeit mit +/- 10V.
Der Regler soll die P-, I-, D-, FF1- und FF2- Terme bearbeiten.
Die Terme bekommen je einen Kern, das Ist-Signal wird von einem Kern im 
QE-Velocity-Mode verarbeitet. Die Rechnerei ist wenig aufwändig. Im 
I-Term kann man noch ein wind-up implementieren.
Ein Kern liest den Sollwert über seinen AD-Eingang, ein weiterer Kern 
gibt den Stellwert über den DA-Wandler aus.
Sind 8 Kerne.
Ich hatte mal Gaudihalber auf einem XMOS einen genau gleichen Regler 
geschrieben, bei dem ich auf 666 KHz gekommen bin, allerdings mit rein 
scaled integer und ohne DA/AD.
Ich kann im Moment nicht nachvollziehen, wie lange Fixed Float auf dem 
Propeller dauert, aber durch den Geschwindigkeitsvorteil vom Prop 2 beim 
AD/DA wage ich zu sagen, dass man auf 50 KHz mit dem Regler hinkommt. 
Damit könnte der äussere Regelkreis mit mindestens 5 kHz arbeiten.

Genügt das jetzt den Zweiflern? Oder haben sie eine CPU die das auch 
locker hinbekommt? Gut beim zweiten Bsp. ist das möglich, 8 kHz hab ich 
schon auch gesehen, es geht bestimmt schneller als die 8 kHz.

[MCUA (Gast)]

>> Der INT mit niedrig(st)er Prio KANN warten, eben weil die Bearbeitung
>> nicht so dringend ist.
> KANN, und wie lange?
Lange genug, um noch bearbeitet zu werden (auch wenn höher prior. INTs 
das System beanspruchen).
Derjenige, der das System baut (bzw die Schaltung für die Anforderung 
baut) muss das nat. im Blick haben (Worstcase-Berechnung usw).
(wenn's zu viele hochprio' sind, auf Hardware ausweichen)


> Wer der Beiden braucht länger?
Das interessiert gar nicht!, solange das System (CPU.. was auch immer) 
es in der geforderten Zeit hinbekommt.
Man nimmt nicht tonnenweise Hardware-Gatter, wenn man es mit nem simplen 
CPU-Konzept schon machen kann.


> Wenn einige davon nur bei verschiedenen Zuständen derselben
> Statusmaschine auftreten, lassen sie sich prinzipiell in einem Core
> zusammenfassen.
Eben. Das läuft ja auf INTs hinaus.


> SH2A: 16Banks
Ja! M16C:2Banks. RX:keine (für Fast-INT können spez. Register benutzt 
werden)

[mh (Gast)]

Nick M. schrieb:
> Genügt das jetzt den Zweiflern? Oder haben sie eine CPU die das auch
> locker hinbekommt? Gut beim zweiten Bsp. ist das möglich, 8 kHz hab ich
> schon auch gesehen, es geht bestimmt schneller als die 8 kHz.

Bei deinem ersten Beispiel nutzt du nichtmal einen Vorteil des 
Propeller? Warum sollte das nicht auch ein gleich schnell getakteter µC 
mit Interrupt hinbekommen? Der kann doch im Zweifel, genauso in Software 
pollen.

Genauso das zweite Beispiel. Das beruht 100% auf der Rechenleistung.

[Nick M. (Gast)]

mh schrieb:
> Bei deinem ersten Beispiel nutzt du nichtmal einen Vorteil des
> Propeller?

3 schnelle QE-Eingänge sind nicht genug?
Nenn mir bitte einen µC der 3 QE-Eingänge hat, welche mit einem sind 
kein Problem. Was ist deren Taktfrequenz?

mh schrieb:
> Genauso das zweite Beispiel. Das beruht 100% auf der Rechenleistung.

Auf paralleler Rechnenleistung. Es werden 5 Terme parallel bearbeitet, 
gleichzeitig ein AD-Eingang der noch skaliert und ein DA-Ausgang der die 
5 Terme aufsummiert und skaliert und ausgibt. Und nebenher ein 
QE-Eingang der die Frequenz ermittelt, das ist nämlich der Velocity 
mode. Also ein QE-Eingang mit Berechnung.
Und das mit 300 MHz.
Welcher µC kann das deiner Meinung nach leisten.
Nenn nur den Typen, mehr nicht.

[Nick M. (Gast)]

MCUA schrieb:
>> KANN, und wie lange?
> Derjenige, der das System baut (bzw die Schaltung für die Anforderung
> baut) muss das nat. im Blick haben (Worstcase-Berechnung usw).
> (wenn's zu viele hochprio' sind, auf Hardware ausweichen)

Oder eben, statt zusätzliche HW dazu entwickeln, auf einen Kern 
auslagern.
Abgesehen davon, dass die worst-case-Berechnung nur auf Annahmen 
basieren kann. Denn INTs haben nun mal die Eigenschaft unberechenbar 
aufzutreten. Wenn genügend INT-Quellen vorhanden sind, wird das ganze 
ein Lotteriespiel. Sowohl vom Zeitverhalten her, als auch von der 
Berechenbarkeit.

[MCUA (Gast)]

..Motor-Control-uCs...(mit jeder Menge ADCs, DACs, Timer..)

> Ich kann jetzt nur annehmen was die maximale Eingangsfrequenz für den
> QE-Eingang ist. Ich nehme 80 MHz an, 1/4 er max. Taktfrequenz.
Dafür braucht man mit Sicherheit nicht mehrere CPU-Kerne.

[Nick M. (Gast)]

MCUA schrieb:
> ..Motor-Control-uCs...(mit jeder Menge ADCs, DACs, Timer..)

Es ging aber ganz konkret um QE-Eingänge. Noch konkreter um 3 
QE-Eingänge.
Ich denke, das ließe sich auch ganz konkret mit einem µC beantworten.

>
>> Ich kann jetzt nur annehmen was die maximale Eingangsfrequenz für den
>> QE-Eingang ist. Ich nehme 80 MHz an, 1/4 er max. Taktfrequenz.
> Dafür braucht man mit Sicherheit nicht mehrere CPU-Kerne.

Nein, da genügt ein Kern. Und 3 QE-Eingänge. Ich hab dafür aber 3 Kerne 
veranschlagt, einer pro QE-Eingang. Einfach weil der dann jeweils seinen 
Zählerwert ins HUB-RAM schreiben kann.

Ich vermute, dass bei denen die hier sagen dass man QE-Eingänge mit INT 
erschlagen kann, die prinzipielle Problematik der QEs nicht ganz 
geläufig ist. Ich erkläre das mal:

QE-Ausgänge prellen. Nicht nur manchmal, sondern zuverlässig. Das tritt 
dann auf, wenn die Position genau so ist, dass man genau auf der Grenze 
steht und die kleineste Bewegung entweder die Position als H oder L 
dedektiert. Das Prellen schadet aber nicht. Das sieht am Ausgang so aus:

A B
0 1
1 1 // Prellendes Signal
0 1

Behandelt man das per INT, gibt es beliebig schnell einen INT, bei dem 
die Position zwischen zwei Lagen hin & herpendelt.
Aus dem Grund haben GSM die eigentlich zur Positionsbestimmung von 1 µm 
sind, eine Auflösung von 0.5 µm. Da kenn das Signal gerne hin & 
herwackeln, es wird nur 1 µm ausgewertet. Eine tatsächliche 
Positionsänderung in dem Sinne tritt nur auf, wenn sich 2 Bits im 
Vergleich zur zuletzt gelesenen Position ändern.

A B
0 1
1 1 // Prellen
0 1
1 0 // Hier ändert sich "wirklich" was.

Die ersten 3 Zeilen waren wieder nur Wackeln, die 4 Zeile eine 
"wirkliche" Änderung. Die 4 Änderungen können innerhalb kürzester Zeit 
auftreten, denn der Verfahrweg waren dann nur 0.5 µm. Und das dann bitte 
für die 3 Kanäle gleichzeitig mit INT behandeln. In dem Fall geht es um 
6 Eingänge. Denn 3 Achsen können problemlos gleichzeitig verfahren. 
Spaßiger wird es bei einer 5-Achs-Fräsmaschine. Mit Port Change-INT ist 
das aussichtslos.
Welchen Typ von INT würdet Ihr stattdessen verwenden?

[Nick M. (Gast)]

Nick M. schrieb:
> Ein Kern liest den Sollwert über seinen AD-Eingang, ein weiterer Kern
> gibt den Stellwert über den DA-Wandler aus.

Hatte eben noch eine Idee:
Statt den Stellwert per DA auszugeben, kann der Kern gleich die H-Brücke 
ansteuern und auch ein Enable Signal auswerten das den Regler 
an/abschaltet.

[MCUA (Gast)]

>>> Ich kann jetzt nur annehmen was die maximale Eingangsfrequenz für den
>>> QE-Eingang ist. Ich nehme 80 MHz an, 1/4 er max. Taktfrequenz.
>> Dafür braucht man mit Sicherheit nicht mehrere CPU-Kerne.
> Nein, da genügt ein Kern. Und 3 QE-Eingänge.
Dafür kein CPU-Kern nötig (80 MHz-Int wäre auch zuviel für CPU, also 
(irgent eine) sep. Hardware nutzen).
Die Encoder-Ergebnisse kann dann eine kleine 8BitCPU ganz gemächlich 
abrufen.

[Nick M. (Gast)]

MCUA schrieb:
> (irgent eine) sep. Hardware nutzen).

Ging es also bei der Diskussion darum, wie man durch Zusatzhardware 
einen Propeller ersetzen kann?
Dann bitte ich um Entschuldigung, ich hab das komplett falsch 
verstanden!

[MCUA (Gast)]

Gut, du willst einen Propeller benutzen um einen Propeller zu benutzen.

[Nick M. (Gast)]

MCUA schrieb:
> Gut, du willst einen Propeller benutzen um einen Propeller zu benutzen.

Nein, bloß keinen Propeller!
Das kann man doch alles per TTL mit weitaus mehr Aufwand bauen.
Ahwa! Machma mit ECL, damit der Solarstrom endlich wegkommt.
Und dass jetzt keiner mit FPGA daherkommt, die sind ausschließlich für 
paar Spezialfälle vorbehalten, eigentlich völlig sinnlos.

[Andi (Gast)]

Ich frag mich ja immer: Was ist der Antrieb für diese Miesmacher, sei es 
nun der Propeller oder seien es FPGAs. Man braucht es nicht, man kann es 
auch anders lösen, ja es gibt gar keine Anwendung.
Sie könnten ja einfach denken: "Nichts für mich", und sich dann mit 
etwas anderem beschäftigen, etwas das sie interessiert. Statt dessen 
suchen sie tagelang nach Argumenten wieso das neue Ding unnötiger 
Blödsinn ist.
Liegt es daran, dass es für sie zu kompliziert ist, und sie nicht 
wollen, dass andere es dann benutzen könnten?
Oder dass der Chef auf die Idee kommen könnte, das einzusetzen, und sie 
vielleicht etwas neues lernen müssen, nachdem sie sich endlich mit dem 
Alten einigermassen auskennen?

Ich versteh es nicht. Mann muss es doch nicht benutzen, wenn man nicht 
will, und es macht auch keinen Sinn es anderen ausreden zu wollen. Die 
haben nämlich eine Anwendung dafür, sonst würden sie es nicht benutzen.

[Alex D. (daum)]

Nick M. schrieb:
> Es ging aber ganz konkret um QE-Eingänge. Noch konkreter um 3
> QE-Eingänge.
> Ich denke, das ließe sich auch ganz konkret mit einem µC beantworten.

Microcontroller mit 3 QE Eingängen gibts bei ST genug. z.B.
STM32F051 hat 3
STM32F103 hat 4
STM32G431 hat 5

[Nick M. (Gast)]

Alex D. schrieb:
> Microcontroller mit 3 QE Eingängen gibts bei ST genug. z.B.

Herzlichen Dank für die weiterführende Antwort!

[Ale (Gast)]

Andi schireb
> Ich frag mich ja immer: Was ist der Antrieb für diese Miesmacher, sei es
> nun der Propeller oder seien es FPGAs. Man braucht es nicht, man kann es
> auch anders lösen, ja es gibt gar keine Anwendung.
> Sie könnten ja einfach denken: "Nichts für mich", und sich dann mit
> etwas anderem beschäftigen, etwas das sie interessiert. Statt dessen
> suchen sie tagelang nach Argumenten wieso das neue Ding unnötiger
> Blödsinn ist.
> Liegt es daran, dass es für sie zu kompliziert ist, und sie nicht
> wollen, dass andere es dann benutzen könnten?
> Oder dass der Chef auf die Idee kommen könnte, das einzusetzen, und sie
> vielleicht etwas neues lernen müssen, nachdem sie sich endlich mit dem
> Alten einigermassen auskennen?

> Ich versteh es nicht. Mann muss es doch nicht benutzen, wenn man nicht
> will, und es macht auch keinen Sinn es anderen ausreden zu wollen. Die
> haben nämlich eine Anwendung dafür, sonst würden sie es nicht benutzen.

Locker sein Modus : An !

Es könnte sein daß du hier nicht genug Threads gelesen hast und nicht 
bemerkt hast daß voll mit Leute ist die genau so denken wie du 
beschrieben hast. Muss du nur irgendwie, auch wenn tangenziell, von der 
Seite oder umgedreht ein Thema ansprechen die nicht "Mainstream" ist: 
Arduino (ist nicht ein uC), gibts andere Prozesoren als AVRs und STM32s, 
andere FPGAs als (die große X) usw. Und bitte alles nur in Perfektes 
Deutsch schreiben ! oh gott rettet uns von diesen die die Artikeln 
falsch deklinieren (wie ich), neben Sätze nicht richtig nutzen usw. 
Nicht alle haben DE als Muttersprache, leben trotzdem in dem 
DE-Sprächige Raum...

Locker sein Modus : Aus !
Seriöse Modus : An !

Trauring :).

Der Propeller 1 kann ganz locker VGA Signalen erzeugen ohne zu schwitzen 
und bleibt genug Luft für einiges, und in 2006 und für ~18 €.
Und der XMOS is nicht nur ein multithread und multicore (in einige 
Fälle), hat auch Kommkanäle mit FIFOs, Ports mit konfigurierbare Breite 
mit FIFOs, mit clocks, Timers die Teil der Programmiersprache sind !
Aber wie du gesagt hast die können es nicht, deswegen machen es kaputt, 
die Menscheit is doomed doooooooomed :(

[R. M. (n_a_n)]

chris_ schrieb:
>>von R. M. (n_a_n)
>>01.01.2021 10:26
>
>>Wie schon erwähnt, ich hatte eine längere Pause und habe heute die
>>aktuellste Version geholt und gebaut.
>
> Interessant ... könntest Du mal diesen Benchmark hier laufen lassen?:
> Beitrag "Re: STM32 Arduino"
>
> Mich würde der Vergleich zu den genannten Prozessoren interessieren.

chris_ schrieb:
> R. M. (n_a_n)
>>Hallo chris, ich habe momentan die Hardware nicht bei mir in der
>>Wohnung.
>
> Danke für die Antwort. Falls Du mal an die Hardware kommen solltest,
> würde mich genau das Ergebnis für den genannten C-Code interessieren.

Das ist jetzt schon ziemlich OT, aber erst jetzt habe ich die Platine 
wieder verfügbar. Zumindest kann ich die Messung von Andi bestätigen:
time/sample
14µs @160MHz
9µs  @250MHz
In der Praxis ist aber noch viel Luft für Optimierungen.
Ohne jetzt den Original Benchmark zu viel zu verändern und auf C-Ebene 
zu bleiben habe ich mal die Filterkoeffizienten nicht in einem Array 
gehalten sondern als Makros definiert.
das bringt schon 7µs @250MHz.
Vermutlich wirkt sich das bei den anderen Prozessoren auch so aus, ich 
weis es nicht.

[chris_ (Gast)]

>Das ist jetzt schon ziemlich OT, aber erst jetzt habe ich die Platine
>wieder verfügbar. Zumindest kann ich die Messung von Andi bestätigen:
>time/sample
>14µs @160MHz
>9µs  @250MHz

Dankeschön.
Das sieht doch gar nicht schlecht aus. Ich habe nach dieser Art der 
Umsetzung gefragt, weil man oft keine Zeit in Optimierungen stecken will 
oder kann.
Nehmen wir als 8 Cores, käme theoretisch auf

14µs/8 @160MHz
9µs/8  @250MHz

Hat eigentlich schon mal jemand das Arduino-Framework auf den Propeller 
portiert? Das könnte die Verbreitung ordentlich fördern.

[Stefan F. (Gast)]

chris_ schrieb:
> Hat eigentlich schon mal jemand das Arduino-Framework auf den Propeller
> portiert?

Ich wüsste nicht, wie das Sinn ergeben sollte. Das Framework kann nichts 
mit den CPUs anfangen, außer mit ihnen PWM Timer und UART zu 
implementieren. Das wäre wie Perlen vor die Säue geworfen.

[Peter D. (peda)]

Ich würd mal auch sagen, die Nische zwischen schneller als ein üblicher 
MC und deutlich langsamer als ein FPGA ist schon recht schmal.
Das erklärt die geringe Verbreitung des Propeller.

[chris_ (Gast)]

>Ich wüsste nicht, wie das Sinn ergeben sollte. Das Framework kann nichts
>mit den CPUs anfangen, außer mit ihnen PWM Timer und UART zu
>implementieren.

Es gibt die Frameworks für alle möglichen Prozessoren. Aus diesem Grund 
spricht überhaupt nichts gegen den Propeller.
Der große Vorteil: Arduino-Libraries, die keinen hardwarespezifischen 
Code benutzen, können ohne Probleme verwendet werden.

z.B. diese hier:
https://github.com/TKJElectronics/KalmanFilter

;-)

[Nick M. (Gast)]

chris_ schrieb:
> Der große Vorteil: Arduino-Libraries, die keinen hardwarespezifischen
> Code benutzen, können ohne Probleme verwendet werden.

Weitaus schöner daran ist, dass es glücklicherweise keine Arduino-libs 
sein müssen.
Denn platformunabhängiger Code wurde schon lange vorm Arduino 
geschrieben und gepflegt und nicht von den Arduinisti verhunzt.

[chris_ (Gast)]

>Weitaus schöner daran ist, dass es glücklicherweise keine Arduino-libs
>sein müssen.

Das kann sein. Nur gibt es leider einige tausend Arduino-Libs und die 
Portierung kann durchaus einen Haufen Aufwand bedeuten, den man 
vermeiden kann.

Aber ich sehe, die Diskussion läuft:

https://forums.parallax.com/discussion/165942/prop-2-languages-c-c-arduino-ide

"
I think providing an Arduino-compatible HAL would benefit Parallax 
significantly. My guess is that moving to a new IDE is not as difficult 
as porting code to a new HAL. Aiming for Simple Library v2.0 to be 
Arduino compatible would be a very good goal, rather than carrying 
forward the C interface from Simple Library v1. "

https://forums.parallax.com/discussion/170108/what-the-propeller-2-can-learn-from-the-arduino

[Nick M. (Gast)]

chris_ schrieb:
> Aber ich sehe, die Diskussion läuft:

TOLL!!! Ein "me too"-Produkt. Oder Österreichisch: Adabei-Produkt.

Egal. Die sollten die 4-fache Anzahl Arduino-Anschlüsse haben. Arduino 
Quadro. In der Mitte der Platine eine stehende Klinkenbuchse um die man 
das Alles rotieren lassen kann. Dann hat es was mit Propeller zu tun und 
ist was neues.
Abklatsch kann jeder.

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> Das wäre wie Perlen vor die Säue geworfen.
Da kommt der Arduino Basher wieder aus den Büschen gesprungen!

Stefan ⛄ F. schrieb:
> Das Framework kann nichts
> mit den CPUs anfangen, außer mit ihnen PWM Timer und UART zu
> implementieren.
Keine Ahnung von dem Thema!
Aber einen dummen Basher Spruch raus rocken.

An anderer Stelle hast du die Behauptung aufgestellt, Arduino User 
dürfen/sollen nur die Arduino Framework API nutzen.
Nicht bis auf die Hardware durchgreifen.
Denn das wäre nicht "vorgesehen".
Aus der Ecke kommt das wieder, oder?


Stefan ⛄ F. schrieb:
> Ich wüsste nicht, wie das Sinn ergeben sollte.
Das ist genau der Punkt!
Du weißt es nicht!
Und weil du es nicht weißt, ist es Perlen vor die Säue.


Warum bist du nicht ehrlich?
Wenn du sagen würdest:
> Ich habe keinen Bock auf Arduino!
> Darum sehe ich auch keinen Sinn,
> in einer Propeller zu Arduino, Portierung.
> Eigentlich, in keiner einzigen "zu Arduino" Portierung.

Aber aus deiner Arduino Ablehnung ein allgemeines Urteil zu formen:
> Das wäre wie Perlen vor die Säue geworfen.
Ist gründlich daneben.
Das ist weit jenseits von irgendeinem fachlichen Argument!

Siehe:
chris_ schrieb:
> Es gibt die Frameworks für alle möglichen Prozessoren. Aus diesem Grund
> spricht überhaupt nichts gegen den Propeller.

Natürlich wird die Portierung nicht einfach.

Aber deine Vorstellungen/Projektionen/Fantasien sind einfach Irre.
Obwohl, die Vorstellungen darfst du haben. Gerne sogar. Privat.
Aber die öffentliche Projektion ist schlicht falsch.
Da nicht die Realität abbildend, sondern nur deiner Fantasie 
entsprungen.
Die sich daraus ergebene, hier präsentierte Beurteilung, ist gründlich 
daneben.



---
Klar, jetzt kommts wieder(ich höre es schon):
> Du hast mich auf dem Kieker.

Oder:
> Wäre besser, wenn du aus dem Forum verschwinden würdest.


Einsicht, in den Irrtum, darf ich von dir nicht erwarten.

[Stefan F. (Gast)]

Arduino Fanboy D. schrieb:
> Da kommt der Arduino Basher wieder aus den Büschen gesprungen!

Ich bashe Arduino schon lange nicht mehr.

> An anderer Stelle hast du die Behauptung aufgestellt, Arduino User
> dürfen/sollen nur die Arduino Framework API nutzen.

Wo denn?

> Und weil du es nicht weißt, ist es Perlen vor die Säue.

Ja genau, das ist meine Meinung. Stell dir vor, auch ich  darf eine 
Meinung haben. Ich darf sie auch öffentlich kund tun, denn Deutschland 
ist ein freies Land und dieses Diskussionsforum dient unter anderem 
dazu, Meinungen zu diskutieren. Wenn dem nicht so wäre, wärst du längst 
lebenslänglich weg gesperrt worden.

> Warum bist du nicht ehrlich?
> Wenn du sagen würdest:
>> Ich habe keinen Bock auf Arduino!
>> Darum sehe ich auch keinen Sinn,
>> in einer Propeller zu Arduino, Portierung.
>> Eigentlich, in keiner einzigen "zu Arduino" Portierung.
> Klar, jetzt kommts wieder(ich höre es schon):
>> Du hast mich auf dem Kieker.
>> Wäre besser, wenn du aus dem Forum verschwinden würdest.

Bitte unterlasse gefälschte bzw. frei erfundene Zitate!

Du handelst hier wie meine Schwiegermutter. Die denkt sich auch mit 
großem Eifer Dinge aus, die andere sagen oder tun könnten, um sich dann 
über die Person aufregen zu können und sie genau für diese frei 
erfundenen Unterstellungen zu verurteilen.

Bist du auch schon so senil?

[Einer K. (Gast)]

Stefan ⛄ F. schrieb:
> wie meine Schwiegermutter
Du diffamierst hier deine Schwiegermutter öffentlich!
Dass du zu solchen Mitteln greifen musst, ist aus meiner Sicht mehr als 
armselig.

Schämen, solltest du dich!

[MCUA (Gast)]

> Ich würd mal auch sagen, die Nische zwischen schneller als ein üblicher
> MC und deutlich langsamer als ein FPGA ist schon recht schmal.
Sofern man (wegen der bekannten Nachteile des Propeller) von Nische 
überhaupt sprechen kann.


> Es gibt die Frameworks...
Die Geschindigkeits-Nachteile von Frameworks sind aber bekannt.
Und schon garnicht kann ein Framework Nachteile einer CPU ausbügeln.

[c-hater (Gast)]

MCUA schrieb:

> Die Geschindigkeits-Nachteile von Frameworks sind aber bekannt.

Richtig: Jede Abstraktion kostet mindestens tendenziell Performance. 
Auch wenn einige C/C++-Apologeten immer mal wieder behaupten, dass ihre 
bevorzugte Sprache gegen solche Grundgesetze der Informatik nicht nur 
immun ist, sondern sie sogar in ihr Gegenteil verkehren kann: Das ist 
und bleibt natürlich Quatsch.

Und davon, dass man mehrere solcher Abstraktionen übereinander stapelt, 
wird es natürlich niemals besser, sondern (im allerbesten Fall) nur 
nicht wesentlich schlechter...

[Einer K. (Gast)]

c-hater schrieb:
> Auch wenn einige C/C++-Apologeten immer mal wieder behaupten, dass ihre
> bevorzugte Sprache gegen solche Grundgesetze der Informatik nicht nur
> immun ist, sondern sie sogar in ihr Gegenteil verkehren kann
Was soll der Blödsinn?
Wer sagt das?

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

Arduino Fanboy D. schrieb:
> Was soll der Blödsinn?
> Wer sagt das?

Passt schon. Mancher Code ist nach der Optimierung durch einen Compiler 
schneller als subptimal geschriebener Assembler-Code, selbst bei 
gleichem Algorithmus. Besonders wenn der Asm-Code nicht speziell für den 
eingesetzten Prozessor geschrieben wurde, unter Kenntnis all seiner 
teils mässig oder nicht dokumentierten Stärken und Schwächen.

Wer wie c-hater sich die Mühe macht, alle in Frage kommenden Prozessoren 
in- und auswendig zu kennen, und für jeden davon das Programm im 
relevanten Kern neu schreibt, für den gilt das natürlich nicht. ;-)

[c-hater (Gast)]

(prx) A. K. schrieb:

> Passt schon. Mancher Code ist nach der Optimierung durch einen Compiler
> schneller als subptimal geschriebener Assembler-Code

Das kann natürlich sehr gut passieren. Aber der Goldstandard ist 
optimaler Assemblercode. Jeder sinnvolle Vergleich kann und muss sich 
genau darauf beziehen. Alles andere ist Selbstbetrug.

> Wer wie c-hater sich die Mühe macht, alle in Frage kommenden Prozessoren
> in- und auswendig zu kennen

Das ist wohl kaum möglich, schon garnicht in Bezug auf jedes beliebige 
Problem. Auch für mich natürlich nicht.

Aber auch in C/C++ geht das natürlich nicht. Denn die Makros der 
Codegeneratoren haben von dem konkreten Problem auch keine Ahnung, genau 
genommen wissen sie über das Gesamtproblem sogar immer sehr viel 
weniger als der Programmierer.

Da müssen dann Profiling-Iterationen folgen. Die allerdings in Assembler 
viel einfacher sind. Da muss man nicht immer überlegen, wie man 
irgendeinem konkreten Comiler nun beibiegt, dass diese oder jene 
Optimierung hier die bessere Wahl wäre (was natürlich bei einem anderen 
Compiler sicher nicht funktioniert und oft nichtmal beim gleichen 
Compiler in einer anderen Version). Nö, man schreibt die für das 
konkrete Problem als besser erkannte Code-Variante einfach hin und der 
Drops ist gelutscht.

[Stefan F. (Gast)]

c-hater schrieb:
> Das kann natürlich sehr gut passieren. Aber der Goldstandard ist
> optimaler Assemblercode. Jeder sinnvolle Vergleich kann und muss sich
> genau darauf beziehen. Alles andere ist Selbstbetrug.

Es wäre Selbstbetrug, davon auszugehen, dass handgeschriebener Assembler 
Code immer perfekt ist.

Alle höheren Programmiersprachen wären in diesem Fall sinnlos. Ihr 
Erfolg zeigt, dass sie sinnvoll sind.

[Nick M. (Gast)]

Stefan ⛄ F. schrieb:
> Es wäre Selbstbetrug, davon auszugehen, dass handgeschriebener Assembler
> Code immer perfekt ist.

Du hast scheinbar die unangenehme Eigenschaft, den Leuten die Worte im 
Mund umzudrehen.
c-Hater hat vom optimalen Assembler gesprochen. Nicht vom 
handgeschriebenen Assembler. Das ist ein kleiner aber feiner 
Unterschied!

Stefan ⛄ F. schrieb:
> Alle höheren Programmiersprachen wären in diesem Fall sinnlos. Ihr
> Erfolg zeigt, dass sie sinnvoll sind.

Wie kommst du jetzt zu der sinnlosen Erkenntnis?

[Stefan F. (Gast)]

Nick M. schrieb:
> Wie kommst du jetzt zu der sinnlosen Erkenntnis?

Mit dir diskutiere ich nicht.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> Es wäre Selbstbetrug, davon auszugehen, dass handgeschriebener Assembler
> Code immer perfekt ist.

Deswegen nimmt das auch kein gestandener Assemblerprogrammierer an. Der 
weiß, das er niemals perfekt ist und das bei genauerer Betrachtung immer 
noch der eine oder andere Takt rauszukitzeln wäre.

Umso erstaunlicher ist die Attitüde der C/C++-Programmierer. Die bauen 
ja nur auf Bausteine auf, die mal irgendein Assemblerprogrammierer in 
den Codegeneratoren verewigt hat. Dieser Programmierer unterlag 
grundsätzlich erstmal denselben Einschränkungen, denen auch jeder andere 
Assemblerprogrammierer ausgesetzt ist.

ZUSÄTZLICH musste er aber bei der Gestaltung seiner Bausteine mit dem 
Problem der sehr unvollständigen Information klarkommen. Der 
Codegenerator weiß nämlich fast nichts über das Gesamtwerk, denn er 
arbeitet auf der Ebene von Funktionen...

> Alle höheren Programmiersprachen wären in diesem Fall sinnlos.

Nein, das sind sie natürlich nicht. Das hat auch niemals jemand 
behauptet. Sie produzieren halt in sehr vielen Fällen hinreichend 
schnellen Code. Aber eben nicht in allen Fällen. Immer dann, wenn's eng 
wird, dann hilft Assembler.

Und genau dieser, in unendlich vielen Fällen nachgewiesene, Sachverhalt 
zeigt, dass die Lüge, dass C/C++ schon alles optimal macht eben genau 
das ist: ein Lüge.

Und sie wird auch durch gebetsmühlenartige Wiederholung nicht wahrer.

[Nick M. (Gast)]

Stefan ⛄ F. schrieb:
>> Wie kommst du jetzt zu der sinnlosen Erkenntnis?
>
> Mit dir diskutiere ich nicht.

Die für dich bis jetzt einzige sinnvolle Erkenntnis!

[Stefan F. (Gast)]

c-hater schrieb:
> Sie produzieren halt in sehr vielen Fällen hinreichend
> schnellen Code. Aber eben nicht in allen Fällen. Immer dann, wenn's eng
> wird, dann hilft Assembler.

Ja. Ich bin positiv überrascht, das von dir in so klaren Worten zu 
lesen.

[Nick M. (Gast)]

c-hater schrieb:
> Sie produzieren halt in sehr vielen Fällen hinreichend
> schnellen Code. Aber eben nicht in allen Fällen. Immer dann, wenn's eng
> wird, dann hilft Assembler.

Das genügt ja auch. Meistens.

c-hater schrieb:
> dass die Lüge, dass C/C++ schon alles optimal macht eben genau
> das ist: ein Lüge.

Sagt das eigentlich ein halbwegs vernünftiger C-Programmierer? Ich 
nicht! Der C-Programmierer greift dann weiter oben an und feilt an den 
Algorithmen. Und dann ist es meistens erledigt. Wenn das nicht genügt 
kommt spätestens jetzt der Profiler und man kann qualifiziert und 
geziehlt zum Assembler übergehen.

Ich seh das alles nicht so verbissen.

[MCUA (Gast)]

> Besonders wenn der Asm-Code nicht speziell für den
> eingesetzten Prozessor geschrieben wurde,
Das ist dann Quatsch-Comedy.

Abstraktion ist immer langsamer, weil untere Ebenen auch bearbeitet 
werden müssen.
Das Programmiersprachen benutzt werden, sagt nichts drüber aus, dass das 
Ergebnis auch effizienter ist.
(klar kann man auch völlig unsinnig in ASM schreiben)
Der Compiler (was ja nichts anderes als ein vorgefertigtes Stück 
Software ist) hat jedoch definitiv vom wirklichen Problem keine Ahnung.

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

MCUA schrieb:
> Der Compiler (was ja nichts anderes als ein vorgefertigtes Stück
> Software ist) hat jedoch definitiv vom wirklichen Problem keine Ahnung.

Umso verblüffender ist, wenn er dann ab und zu ein Teilproblem erkennt 
und dafür einen besseren Algorithmus einsetzt. Beispielsweise wenn er 
eine verschachtelten Rechenschleife mit vollständig bekannten Daten 
durch "return 42;" ersetzt. ;-)

[chris_ (Gast)]

>von c-hater (Gast)
>MCUA schrieb:

>> Die Geschindigkeits-Nachteile von Frameworks sind aber bekannt.

>Richtig: Jede Abstraktion kostet mindestens tendenziell Performance.
>Auch wenn einige C/C++-Apologeten immer mal wieder behaupten, dass ihre
>bevorzugte Sprache gegen solche Grundgesetze der Informatik nicht nur
>immun ist, sondern sie sogar in ihr Gegenteil verkehren kann: Das ist
>und bleibt natürlich Quatsch.

Das ist wohl war. Handoptimierter Assemblercode kann fast in jedem Fall 
schneller sein als vom C-Compiler erzeugter Code, der immer irgendwelche 
Generalisierungen enthält.
Aber es wäre natürlich etwas aufwendig die oben erwähnte Kalmam-Filter 
Library für den Beschleunigungssensor auf die jeweilige 
Prozessorarchitektur anzupassen. Deshalb ist es so schön, dass das 
Arduino-Framework so viele Libraries anbietet, mit denen man in wenigen 
Schritten einen funktionierenden Prototypen basteln kann ( oft, aber 
natürlich nicht immer ).
Viel schlimmer ist die Verwendung von Java auf dem PC. Da wird die 
Leistung in den Wind geblasen ( OK ich weiss es gibt Jit-Compiler ).
Aber Python nähert sich ja auch schon den Mikrocontrollern ... für den 
Propeller gibt es MicroPython.

[c-hater (Gast)]

Nick M. schrieb:

> Sagt das eigentlich ein halbwegs vernünftiger C-Programmierer?

Nein, natürlich nicht. Das Problem ist nur: es gibt ganz offensichtlich 
Unmassen C/C++(only)-Programmierer, die nichtmal in die Kategorie 
"halbwegs vernünftig" fallen.

Die sind es, die diese Lüge immer und immer wieder als Schutzbehauptung 
verbreiten, um ihre eigene dramatische Inkompetenz zu bemänteln.

Und genau das ist, was mir so dermaßen stinkt, dass ich mich gezwungen 
gesehen habe, eigens eine Persona zu erfinden, um dagegen argumentativ 
vorzugehen.

Natürlich mit recht wenig Erfolg bezüglich genau dieser Zielgruppe, aber 
hoffentlich mit etwas mehr Erfolg bezüglich des Nachwuchses. Wenigstens 
einige von denen glauben dann hoffentlich diese Lüge nicht mehr 
unbesehen und verschaffen sich ein eigenes Bild, indem sie selber 
Assembler lernen und anwenden...

[MCUA (Gast)]

.. dann wurde die "verschachtelte Rechenschleife" schon falsch 
eingegeben.
Die Eingabemöglichkeiten in einen Compiler sind extrem! begrenzt.

[Einer K. (Gast)]

MCUA schrieb:
> Abstraktion ist immer langsamer, weil untere Ebenen auch bearbeitet
> werden müssen.
Das ist falsch.

Da die Abstraktion vor der Komilezeit erfolgt, und im besten Fall zur 
Komilezeit aufgelöst wird, ist die Aussagen, dass immer 
Laufzeitnachteile zu erwarten sind falsch.

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

c-hater schrieb:
> Das Problem ist nur: es gibt ganz offensichtlich
> Unmassen C/C++(only)-Programmierer, die nichtmal in die Kategorie
> "halbwegs vernünftig" fallen.

Stimmt. Und genau diese Leute werden also bessere Programme auswerfen, 
wenn sie statt dessen Assembler nutzen. ;-)

[chris_ (Gast)]

c-hater
>Natürlich mit recht wenig Erfolg bezüglich genau dieser Zielgruppe, aber
>hoffentlich mit etwas mehr Erfolg bezüglich des Nachwuchses.

Der Nachwuchs? Vergiss es. Ich habe mich vor kurzem mit den jüngeren 
Kollegen unterhalten. Die sind von der Bitnahen Assemblerwelt Lichtjahre 
entfernt.
Bei uns werden für's LED-Blinken mittlerweile STM32H7 eingesetzt ...

[Stefan F. (Gast)]

(prx) A. K. schrieb:
> Umso verblüffender ist, wenn er dann ab und zu ein Teilproblem erkennt
> und dafür einen besseren Algorithmus einsetzt. Beispielsweise wenn er
> eine verschachtelten Rechenschleife mit vollständig bekannten Daten
> durch "return 42;" ersetzt. ;-)

Oder wenn der Java Compiler eine Reihe von String Konkatenierungen durch 
die StringBuilder Klasse und ihre Methoden ersetzt.

Aus

String s="Hallo ";
if (vorname!=null)
{
    s+=vorname;
    s+=" ";
}
s+=nachname;
return s+",";

(Das ist deswegen blöd, weil Strings unveränderbar sind, was hier zum 
Anlegen von insgesamt 5 Objekten führt)

Daraus macht er:

StringBuilder sb("Hallo");
if (vorname!=null)
{
    sb.append(vorname);
    sb.append(' ');
}
sb.append(nachname);
return sb.append(',').toString();

Aber auch der avr-gcc hat solche Tricks drauf. Zum Beispiel wandelt er

printf("Hallo\n");

in

puts("Hallo");

um.

[MCUA (Gast)]

>> Abstraktion ist immer langsamer, weil untere Ebenen auch bearbeitet
>> werden müssen.
> Das ist falsch.
> Da die Abstraktion vor der Komilezeit erfolgt, und im besten Fall zur
> Komilezeit aufgelöst wird, ist die Aussagen, dass immer
> Laufzeitnachteile zu erwarten sind falsch.
Ja es wird zur Compilezeit gemacht.
Und?
Mit Sicherheit wird es nicht schneller...
... also wird es (in Realität) langsamer.
(und wenn ich mir anhöre, wieviele Takte ein Pin-Set-Befehl bei manchen 
"Frameworks" braucht, wird mir schlecht)

[Stefan F. (Gast)]

chris_ schrieb:
> Viel schlimmer ist die Verwendung von Java auf dem PC. Da wird die
> Leistung in den Wind geblasen ( OK ich weiss es gibt Jit-Compiler ).

C Programme sind etwa doppelt so schnell wie Java. Bei C++ ist der 
Unterschied noch geringer, also nicht so groß, wie man (ich) spontan 
vermuten würde.

[Nick M. (Gast)]

c-hater schrieb:
> Natürlich mit recht wenig Erfolg bezüglich genau dieser Zielgruppe, aber
> hoffentlich mit etwas mehr Erfolg bezüglich des Nachwuchses.

Glaubst du, dass die Jüngeren das besser verstehen? Die freuen sich doch 
eher über Python auf dem Propeller.
Für die Jungen ist i.A. C völlig nutzlos. Die können Libraries 
zusammenstöpseln. Das Ergebnis ist dann ein Arduino der vor einem 
Raspberry hängt, weil der Arduino schneller zählen kann (Parallel-Thread 
Fluxgate; aber keiner der Teilnehmer).

Ich versteh den K(r)ampf sowieso nicht. Jede Sprache hat seinen Platz. 
Das Wissen wann was sinnvoll und wirtschaftlich einzusetzen ist sollte 
man von einem Entwickler verlangen können.

[Stefan F. (Gast)]

c-hater schrieb:
> Die sind es, die diese Lüge immer und immer wieder als Schutzbehauptung
> verbreiten, um ihre eigene dramatische Inkompetenz zu bemänteln.
>
> Und genau das ist, was mir so dermaßen stinkt, dass ich mich gezwungen
> gesehen habe, eigens eine Persona zu erfinden, um dagegen argumentativ
> vorzugehen.

Merkt man. Aber du kannst die Welt nicht verbesern. Akzeptiere sie 
lieber, dann lebst du glücklicher.

[MCUA (Gast)]

>> Das Problem ist nur: es gibt ganz offensichtlich
>> Unmassen C/C++(only)-Programmierer, die nichtmal in die Kategorie
>> "halbwegs vernünftig" fallen.
> Stimmt. Und genau diese Leute werden also bessere Programme auswerfen,
> wenn sie statt dessen Assembler nutzen. ;-)
Nein, die sind auf Compiler angewiesen.

[Andreas S. (andreas) (Admin)]

Bitte kommt zurück zum Thema.

[Andi (Gast)]

Gerade beim Propeller, wo man oft Softwareperipherals schreibt, ist ein 
optimierender Compiler manchmal sehr störend. Da muss man ein bestimmtes 
Timing einhalten, das der Compiler nicht kennt, und wenn da einfach 
Schleifen optimiert und Befehle in eine andere Reihenfolge gebracht 
werden führt das eben dazu das es nicht mehr funktioniert.
Auch ist höchste Geschwindigkeit dabei nicht immer das Ziel. Konkretes 
Beispiel: Schreibe ich eine I2C Routine in Spin weiss ich, der Clock 
wird nicht schneller sein als 400 kHz, da Spin Bytecode erzeugt, der 
dann interpretiert wird. Übersetzte ich den gleichen Code in C wird er 
viel zu schnell sein, und ich muss überall Delays einbauen.

[chris_ (Gast)]

Andi (Gast)
>Gerade beim Propeller, wo man oft Softwareperipherals schreibt, ist ein
>optimierender Compiler manchmal sehr störend.

Deshalb gibt es ja beim Propeller für die unterschiedlichen 
Peripherieemulationen fertige Code Blöcke. Diese bindet man dann in 
eigene Projekte ein, so wie man auch eine seriellen Treiber in eigene 
Projekte einbindet und nicht jedes mal neu schreibt.
Das Prinzip schnelle Signalverarbeitungsblöcke als Module zu 
programmieren und dann mit einer Skript artigen Sprache zu verbinden, 
ist weit verbreitet ( z.B OpenCV und Python oder Lua als Script Sprache 
in Spieleengines ).
Aus diesem Grunde ist ein Arduine-Framework für den Propeller extrem 
sinnvoll falls dort die Peripherie schon ins Framework eingebunden ist.

[Olaf (Gast)]

> Das Prinzip schnelle Signalverarbeitungsblöcke als Module zu
> programmieren und dann mit einer Skript artigen Sprache zu verbinden,

Interessant finde ich das es das Prinzip schon sehr lange gibt. Ich bin 
da vor 20Jahren das erstemal drauf gestossen. Und zwar in Form der TPU 
eines 68332.

https://www.mikrocontroller.net/articles/MC68332#TPU

Hier mal eine Anwendung:
https://www.jstor.org/stable/44611720?seq=1

Es hat mich immer gewundert das sich diese geniale Idee nicht mehr 
verbreitet hat. Daher denke ich das der Durchnittsprogrammierer dafuer 
einfach nicht bereit ist. Das uebersteigt seine Vorstellung. Man sieht 
ja auch wie oft hier jemand aufschlaegt und jammert das er eine fertige 
Libarie fuer irgendeine banale Funktion eines STM32 braucht. Oder das 
man auch nur darueber nachdenkt sowas wie arduino auf so einem System zu 
implementieren.

Im professionellem Umfeld sehe ich ausserdem das grosse Problem der 
Inkompatibilitaet. In der Firma ziehen wir ohne Probleme auch 
umfangreichste Projekte von einem Mikrocontroller eines Herstellers auf 
einen anderen um wenn das aus Hardware oder Kostengruenden notwendig 
ist. Das wird dir bei einem Propeller ziemlich schwer fallen. Und es ist 
vermutlich auch das Problem das den PSoC von Cypress immer etwas 
behindert hat.
Daher denke ich das Hauptproblem des Propeller, neben seiner schlechten 
Dokumentation, ist vor allem:

Wat de Buer nich kennt, dat frett he nich

Olaf

[chris_ (Gast)]

>Interessant finde ich das es das Prinzip schon sehr lange gibt. Ich bin
>da vor 20Jahren das erstemal drauf gestossen. Und zwar in Form der TPU
>eines 68332.
Auch interessant ist, dass sie die TPUs bis in die modernen PPC-MCUs 
übernommen haben. Sie sind mir zum ersten mal vor ca. 8 Jahren 
aufgefallen:
https://de.wikipedia.org/wiki/Liste_der_Freescale-Produkte

[MCUA (Gast)]

> Bitte kommt zurück zum Thema.
20 Beiträge gelöscht

[Einer K. (Gast)]

MCUA schrieb:
> 20 Beiträge gelöscht
Ja, ist doch gut so!
Die Java Nebelkerze gestartet, damit eine Eskalation ausgelöst und jetzt 
ist der Dreck weg.

Alles ok so.

Es wäre natürlich schöner, wenn .......

[MCUA (Gast)]

Da ging es nicht nur um Java

[Einer K. (Gast)]

MCUA schrieb:
> Da ging es nicht nur um Java
Ja, das stimmt!
Irgendwelche Überlegenheitsfantasien waren da auch im Spiel.

Das alles macht doch in einer "Propeller Diskussion" wenig Sinn.

[mh (Gast)]

Andi schrieb:
> Gerade beim Propeller, wo man oft Softwareperipherals schreibt, ist ein
> optimierender Compiler manchmal sehr störend. Da muss man ein bestimmtes
> Timing einhalten, das der Compiler nicht kennt, und wenn da einfach
> Schleifen optimiert und Befehle in eine andere Reihenfolge gebracht
> werden führt das eben dazu das es nicht mehr funktioniert.

Wenn die Software, nicht mehr funktioniert, wenn der Compiler optimiert, 
liegt das am Entwickler und nicht an der Sprache oder dem Compiler. Es 
gibt klare Regeln an die man sich halten muss und die muss der 
Entwickler lernen.

[Nick M. (Gast)]

mh schrieb:
> Andi schrieb:
>> Gerade beim Propeller, wo man oft Softwareperipherals schreibt, ist ein
>> ...
>
> Wenn die Software, nicht mehr funktioniert, wenn der Compiler optimiert,
> liegt das am Entwickler und nicht an der Sprache oder dem Compiler.

Das gilt aber nicht bei zeitkritischen Routinen. Wenn eine neue 
Compiler-Version oder eine andere Optimierungsoption einen Zyklus mehr 
oder weniger braucht kann ein zeitkritisches Interface einfach nicht 
mehr funktionieren. Auch wenn alle Signale rein von den Pegeln her 
stimmen.

[c-hater (Gast)]

Andi schrieb:

> Auch ist höchste Geschwindigkeit dabei nicht immer das Ziel.

Das ist ein weiterer wesentlicher Grund, der an vielen Stellen für 
Assembler spricht: berechenbares Timing.

Selbst in modernen Architekturen, die oft schon auf Hardware-Ebene durch 
Caches und Out-Of-Order-Pipelines das Timing verwürfeln können ist es 
fast immer möglich, mit entsprechenden Assembler-Instruktionen dann doch 
wieder ein berechenbares Timing zu produzieren. Das ist natürlich 
typischerweise für den theoretischen Durchsatz suboptimal, aber für das 
konkrete Problem optimal.

Solche Sachen laufen letztlich auf die Entscheidung hinaus: geht nicht 
(liefere das falsche/unbrauchbare Ergebnis aber maximal schnell) oder 
geht.

Jedem normalen Programmierer fällt da die Wahl dann doch sehr leicht...

Wenn er die Wahl hat, weil er mehr als nur C/C++ kann...

[Stefan F. (Gast)]

c-hater schrieb:
> Das ist ein weiterer wesentlicher Grund, der an vielen Stellen für
> Assembler spricht: berechenbares Timing.

Ja. Wenn man Schnittstellen in Software implementiert ist das sicher ein 
ganz wichtiger Aspekt.

Als PC Programmierer bin ich eher gewohnt, mit Hochsprachen und 
Frameworks Hardwaremodule zu programmieren, die das Timing selbst 
erzeugen. Das kann in ein einfachen z.B. ein PCA9685 (16 Channel PWM) 
sein.

Wenn ich nun den PCA9685 zum Beispiel durch einen Mikrocontroller 
ersetzen würde, der nur einfache dumme I/O Pins hat, dann würde wohl 
kaum ein Weg an Assembler vorbei führen. Wie soll er sonst exakte 
Timings machen?

Und wenn ich meine PWM Signale direkt mit dem PC erzeugen wollte, müsste 
ich einen Parall-Port verwenden und das ganz sicher auch in Assembler 
ohne Windows programmieren.

Wenn man nun im Propeller diverse I/O Schnittstellen in Software 
implementieren muss, ist da sicher viel Assembler mit dabei. 
Wahrscheinlich viel mehr, als man heute von anderen Mikrocontrollern 
gewohnt ist.

So sehr ich unsere Compiler und Hochsprachen schätze, eins erwarte ich 
von ihnen überhaupt nicht: Exakte Timings erzeugen zu können.

[c-hater (Gast)]

Stefan ⛄ F. schrieb:

> So sehr ich unsere Compiler und Hochsprachen schätze, eins erwarte ich
> von ihnen überhaupt nicht: Exakte Timings erzeugen zu können.

Deswegen verspricht das ja auch ehrlicherweise keine dieser Sprachen.

> Als PC Programmierer bin ich eher gewohnt, mit Hochsprachen und
> Frameworks Hardwaremodule zu programmieren, die das Timing selbst
> erzeugen.

Solange du entsprechende Hardware zur Verfügung hast, ist das ja auch 
der normale Weg. Niemand (schon garkein gelernter Asm-Programmierer) 
kommt auf die abstruse Idee, verfügbare und für den Zweck auch nur 
halbwegs brauchbare Hardware nicht irgendwie nutzbringend zu verwenden.

Nur manchmal gibt es halt keine geeignete Hardware. Oder es gibt sie 
zwar, sie wird aber für einen anderen, noch timing-kritischeren Zweck 
benötigt.

[Carl D. (jcw2)]

> schon garkein gelernter Asm-Programmierer

Ist das ein anerkannter Lehrberuf?

[c-hater (Gast)]

Carl D. schrieb:

> Ist das ein anerkannter Lehrberuf?

Nein.

Aber OK: Gehirnchirurg ist auch kein anerkannter Lehrberuf. Es soll 
trotzdem welche geben, die sich damit auskennen und zu durchaus 
nützlichen Ergebnissen kommen (wenn auch nicht in jedem Fall)...

[Carl D. (jcw2)]

c-hater schrieb:
> Carl D. schrieb:
>
>> Ist das ein anerkannter Lehrberuf?
>
> Nein.
>
> Aber OK: Gehirnchirurg ist auch kein anerkannter Lehrberuf. Es soll
> trotzdem welche geben, die sich damit auskennen und zu durchaus
> nützlichen Ergebnissen kommen (wenn auch nicht in jedem Fall)...

Die haben aber eine medizinische Ausbildung hinter sich.

Zudem versuchen Mediziner nicht jedes Problem mit einer Gehirnoperation 
zu lösen. Manchmal benutzen sie z.B. zum bekämpfen von Kopfschmerzen 
lieber weniger ultimative Mittel wie Acetylsalicylsäure. Sowas wäre aus 
Sicht eines "echten Hirnchirurgen" völlig inakzeptabel.

Zum Thema: Propeller ist ein Konzept, das Peripherie durch Software 
ersetzt. Quasi Microcode, der in jeden der Cogs geladen werden kann. Um 
diese programmierte "HW" zu "scripten", wurde Microcode für den 
SPIN-Interpreter im ROM hinterlegt. Damit können auch "verweichlichte 
Nichtskönner" (wie mancher/einer hier gerne zum Ausdruckt bringt) diese 
Teil benutzen. Der Ansatz könnte auch der Tatsache geschuldet sein, daß 
damit die HW einfacher aufgebaut sein könnte, was der Größe des 
Entwicklungsteams (Prop1 -> einer) entgegen kommt. Alle, die damit ein 
Problem haben sollten das Ding einfach nicht beachten.
Ich hab hier einen rumliegen, der für ein Projekt gedacht ist, das es 
früher mal im Netz gab: eine "Emulation" einer Hammond B3. Klingt nach 
den mp3's nicht schlecht. Ich hab auch mal versucht den Code zu 
analysieren, die B3 läuft quasi auf einem Kern, ein weiterer bildet 
einen Leslie-Turm nach, einer wartet auf MIDI-Kommandos, ...
Ich benutze aber trotdem auch andere "Rechner", wo diese besser geeignet 
sind.

[Nick M. (Gast)]

Carl D. schrieb:
> Zudem versuchen Mediziner nicht jedes Problem mit einer Gehirnoperation
> zu lösen.

Gehirnchirurgen lösen Probleme die mit Gehirnchirugie lösbar sind.
Gehirnchirurgen lösen in der Regel keine Probleme die der Orthopäde mit 
einem Gipsverband löst.
Nicht alles was hinkt ist ein Vergleich.

[Pille (Gast)]

c-hater schrieb:
> Stefan ⛄ F. schrieb:
>
>> Es wäre Selbstbetrug, davon auszugehen, dass handgeschriebener Assembler
>> Code immer perfekt ist.
>
> Deswegen nimmt das auch kein gestandener Assemblerprogrammierer an. Der
> weiß, das er niemals perfekt ist und das bei genauerer Betrachtung immer
> noch der eine oder andere Takt rauszukitzeln wäre.

Na und? Deine Haterei geht einem wirklich mit der Zeit auf den Wecker.
Neimand, ich meine absolut gar Keiner, verbietet jemand Anderem das 
Werkzeug zu benutzen das er für am besten geeignet für den Job hält.
>
> Umso erstaunlicher ist die Attitüde der C/C++-Programmierer. Die bauen
> ja nur auf Bausteine auf, die mal irgendein Assemblerprogrammierer in
> den Codegeneratoren verewigt hat.

Dein Fehler liegt bei "nur". Teilweise bauen die auch auf Bausteine auf 
die irgendwann mal von Fortran Programmierern geschaffen wurden 
(numerische Bibliotheken). Sie bauen halt auf Bausteinen auf die auch 
Jemand Anderes geschaffen haben kann.

> Dieser Programmierer unterlag
> grundsätzlich erstmal denselben Einschränkungen, denen auch jeder andere
> Assemblerprogrammierer ausgesetzt ist.
>
> ZUSÄTZLICH musste er aber bei der Gestaltung seiner Bausteine mit dem
> Problem der sehr unvollständigen Information klarkommen. Der
> Codegenerator weiß nämlich fast nichts über das Gesamtwerk, denn er
> arbeitet auf der Ebene von Funktionen...

Ich möchte Dich mal sehen wenn Du einen X-Server in Assembler schreiben 
sollst, über Performance redet da erst mal Niemand, Interessant wäre ob 
Du die Funktion alleine gewährleisten könntest.
>
>> Alle höheren Programmiersprachen wären in diesem Fall sinnlos.
>
> Nein, das sind sie natürlich nicht. Das hat auch niemals jemand
> behauptet. Sie produzieren halt in sehr vielen Fällen hinreichend
> schnellen Code. Aber eben nicht in allen Fällen. Immer dann, wenn's eng
> wird, dann hilft Assembler.

Es sollte nicht eng werden, denn die von C Programmierern ja ständig 
benutzen Bausteine schließen überhaupt nicht aus das man Assembler 
Routinen für zeitkritische Stellen einbaut, aber beispielsweise halt 
komplexe GUI Funktionen benutzt die Jemand in C oder in wasweisich 
geschrieben hat.
Bitte erst mal die Funktion gewährleisten, danach über Performance 
reden!
"If it doesn't fit, use a bigger hammer!" ist doch der Grundsatz nach 
dem heute Programmierung läuft, jede beschissene Textverarbeitung 
fordert heute Gigabytes an RAM und mehrere GHz als Taktfrequenz um genau 
das zu tun was auf einem IBM XT mit 640K und 4,77Mhz möglich war.

>
> Und genau dieser, in unendlich vielen Fällen nachgewiesene, Sachverhalt
> zeigt, dass die Lüge, dass C/C++ schon alles optimal macht eben genau
> das ist: ein Lüge.

Das hat Niemand behauptet, es wird nur erklärt das die Performance im 
Vergleich zu handoptimiertem Assembler so schlecht gar nicht ist.
Was wofür eingesetzt wird entscheidet doch kein "Gut oder Böse", sondern 
wieviel Aufwand man in die Hardware und wie viel in die Software stecken 
will.
Jemand der länglich einen Atmga16 mit Assembler auswringt um damit 
unbedingt seine Anwendung durchziehen zu wollen ist doch nur als krank 
zu bezeichnen wenn weltweit für deutlich geringere Preise um ein 
vielfaches schnellere 32Bit MCUs verfügbar sind, die selbst bei 
Programmierung mit Basic Interpreter um ein Vielfaches schneller sind, 
als der handoptimierte AVR.

Kannst Du Deine Agitation an jeder möglichen und unmöglichen Stelle also 
bitte mal einstellen? Es nervt nur noch, universell wahr sind Deine 
Behauptungen aber auch nicht.
>
> Und sie wird auch durch gebetsmühlenartige Wiederholung nicht wahrer.

Was auch auf Deine Behauptungen exakt paßt.

Pille

[Pille (Gast)]

Nick M. schrieb:
> Carl D. schrieb:
>> Zudem versuchen Mediziner nicht jedes Problem mit einer Gehirnoperation
>> zu lösen.
>
> Gehirnchirurgen lösen Probleme die mit Gehirnchirugie lösbar sind.
> Gehirnchirurgen lösen in der Regel keine Probleme die der Orthopäde mit
> einem Gipsverband löst.
> Nicht alles was hinkt ist ein Vergleich.

Das Trifft aber auch auf das ultimative "besser" von Assemblercode zur 
Programmierung zu.

Ich kenne Wissenschaftler die nach wie vor Fortran nutzen und das Zeug 
auf Vectorrechnern durchdrehen. Wie Ihr Fortran auf die Maschine 
paßt..darum mögen sich doch bitte die Compiler auf den 
Konzentrator-Workstations kümmern..

Pille

[Nick M. (Gast)]

Pille schrieb:
> Das Trifft aber auch auf das ultimative "besser" von Assemblercode zur
> Programmierung zu.

Prinzipbedingt kann handoptimierter Assemblercode besser sein als das 
was ein C-Compiler generiert hat.
Die Betonung liegt auf kann.
Ausser:
Irgendwann kommt mal einer drauf mit dem Monte-Carlo-Verfahren so lange 
Assembler-code zu produzieren bis er den schnellsten Code gefunden hat. 
So lang will ich aber nicht warten. :-)

Zum Assembler mit/statt/gegen C bleib ich dabei:
Beitrag "Re: Wofür Propeller von Parallax ?"

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

Nick M. schrieb:
> Irgendwann kommt mal einer drauf mit dem Monte-Carlo-Verfahren so lange
> Assembler-code zu produzieren bis er den schnellsten Code gefunden hat.
> So lang will ich aber nicht warten. :-)

Musst nicht warten. Gibts schon seit Jahrzehnten:
https://www.gnu.org/software/superopt/
https://en.wikipedia.org/wiki/Superoptimization

[Nick M. (Gast)]

(prx) A. K. schrieb:
> Musst nicht warten. Gibts schon seit Jahrzehnten:

Mein Schicksal. Ich erfind immer Sachen die es schon gibt. :-(
Danke für die Links.

[Pille (Gast)]

Nick M. schrieb:
> Pille schrieb:
>> Das Trifft aber auch auf das ultimative "besser" von Assemblercode zur
>> Programmierung zu.
>
> Prinzipbedingt kann handoptimierter Assemblercode besser sein als das
> was ein C-Compiler generiert hat.
> Die Betonung liegt auf kann.
> Ausser:
> Irgendwann kommt mal einer drauf mit dem Monte-Carlo-Verfahren so lange
> Assembler-code zu produzieren bis er den schnellsten Code gefunden hat.
> So lang will ich aber nicht warten. :-)
>
> Zum Assembler mit/statt/gegen C bleib ich dabei:
> Beitrag "Re: Wofür Propeller von Parallax ?"

Genauer gesagt meinst Du: "Es wurde von Dir zwar Alles schon gesagt, nur 
von mir noch nicht"?

Pille

[Ale (Gast)]

Dann wollen das die C Quellen "MISRA" compliant sind und wenn man ein 
bisschem assembler benutzt hat weil es schneller/kleiner muss wird 
schief angeguckt.