PropGCC … *Jubel!* … *KREISCH!* … *in_Ohnmacht_fall* …

[yeti]

Frage : Hat schon jemand einen vernüftigen SPI-Treiber im PropGCC entdeckt, ich finde da vor lauter Ordnern und Dateien nichts.

blittled erwähnte im Thread Device IO Library an SPI-Routinen zu schreibem.

[TuxFan]

...blittled erwähnte im Thread Device IO Library an SPI-Routinen zu schreibem.

Danke.
Ist ja Einiges los im C-Lager. Das was ich bis jetzt so entdeckt habe läßt hoffen, auch hinsichtlich Hardwareoffenheit für verschiedene Board-Typen mit unterschiedlichen Speicherkonzepten.
Nur die Demoprogramme ans laufen zu kriegen scheint nicht so leicht zu sein. Die lmm-Demo für den C3, bei mir SoMProp + C3-SPI-Bus-Anhänger, lief von ca.50 Versuchen nur ein mal. Dabei benutze ich die orginal PropGCC-bin-Programme aus dem Download. Compilieren läuft ohne Fehlermeldungen aber beim Laden findet er die serielle Schnittstelle nicht, auch nicht bei explizierter Angabe zigmalem Kabelwehsel etc.
Bis alles richtig läuft wird es wohl ein steiniger Weg.

Gruß
TuxFan

[yeti]

Nur die Demoprogramme ans laufen zu kriegen scheint nicht so leicht zu sein. Die lmm-Demo für den C3, bei mir SoMProp + C3-SPI-Bus-Anhänger, lief von ca.50 Versuchen nur ein mal. Dabei benutze ich die orginal PropGCC-bin-Programme aus dem Download. Compilieren läuft ohne Fehlermeldungen aber beim Laden findet er die serielle Schnittstelle nicht, auch nicht bei explizierter Angabe zigmalem Kabelwehsel etc.
Bis alles richtig läuft wird es wohl ein steiniger Weg.

Ich benutz nur selbstkompilierte PropGCCs.
Das Gehampel mit der blockierenden Schnittstelle hatte ich doch auch schon erwähnt.
Aber die kriegen das noch in den Griff... da bin ich hemmungslos optimistisch!

[yeti]

Hi, we decided to push Beta start to the first week of March.
My initial post estimate in this thread was a little "aggressive".

Standard Library bugs have been found in the meanwhile.
We will be posting another release soon.

Keine Atempause, Geschichte wird gemacht!
Es geht voran!

[Nadji]

klingt gut

[yeti]

Was Drolliges aus'm großteichjenseitigen Forum...

On a number of occasions I've written a spin program knowing it would be changed into asm at some stage. I tend to write the spin code in an "asm" sort of way. For instance - if there are multiple and/or/bitshifts in a line of spin, split it up into individual lines. And if you have a variable multiplied by 2 or 4 etc, use a bitshift instead. There is some fascinating maths involved in multiplying any number by a constant using bitshifts only - and this sort of coding works out faster.

The thing is that using tricks like reducing "n x 15" to "n bitshift left 4 places and subract n from the answer" are not the sort of things an automatic translation program can do very easily.

I believe the very clever C programmers have got code that you can tell the compiler whether to put it in hub or cog.

If you like, maybe post some of your spin code and we can think about how to convert it to asm?

...vs...

I'm often surprised by the optimizations gcc performs . Here's a log of converting a simple .spin function to PASM, automatically:

Code: Alles auswählen

$ cat test.spin
PUB mul15(n)
  return n*15
$ spin2cpp test.spin
$ propeller-elf-gcc -mcog -O3 -S -o test.pasm test.cpp
$ cat test.pasm
    .text
    .balign    4
    .global    __ZN8testSpin5Mul15Ei
__ZN8testSpin5Mul15Ei
    mov    r0, r1
    shl    r0, #4
    sub    r0, r1
    jmp    lr

This is under Linux, so the "$" is a command prompt and "cat" is the program to type a file out. The weird name "_ZN8testSpin5Mul15Ei" is due to the way C++ encodes type information in function names. Also note that I did give -O3 to propeller-elf-gcc to tell it to optimize for speed as much as it can; if it's optimizing for space (the normal case in the Propeller world) it'll generate a call to a multiply routine instead because that takes less space than the shift and sub.

Of course the .pasm isn't a complete program, you'd need the register declarations and some interface code. Giving the "-mspin" argument to propeller-elf-gcc will make it output a lot of that for you. Also, it's using the normal C calling convention (where return addresses are stored in the "lr" register) instead of the PASM calling convention (where you return with "ret"); there are ways to force gcc to use that, but they require editing the .cpp file that spin2cpp creates.

Eric

<ulbricht-stimme> Niemand hat gesagt daß GCC es sich einfach macht! </ulbricht-stimme>

Sowas kann einem den ganzen Tag retten!

...ob das zu ner Fortsetzungsstory wird?

Ein Dreifachhoch auf GCC!

[yeti]

Bescheid!
v0.2.3 ist da...

[hoeppie]

Wow, da hat sich ja einiges getan:

https://sites.google.com/site/propellergcc/downloads

SimpleIDE v0-7-2
Propeller-GCC v0-3-4 (propellergcc_v0_3_4)

Schon jemand weiter getestet?

Gruß Höp

[yeti]

Hat schon jemand PropGCC erfolgreich unter Debian/Jessie gebaut?
...ohne ein Downgrade irgendwelcher Debianpakete?

----------8<----------{2015-01-22}---------->8----------

Im Hintergroßteichjenseitslerpropellerforum erhält man auf Hilfeschreie zu Fehlern beim Selberbacken von PropGCC auf neueren Systemen oft einen Tip, wie den Folgenden:

The build instructions on the wiki have a note about this error - you'll need to downgrade you version of texinfo
https://code.google.com/p/propgcc/wiki/PropGccBuild

Leider hängt am installierten "texinfo" oftmals noch ein ganzer Rattenschwanz anderer Dinge, die beim Deinstallieren der aktuellen Version dann mit rausfliegen. Meist wird man das nicht wirklich wollen!

Aber es geht auch anders...

Einfach erst ein hinreichend altes "texinfo" in den Zielpfad von PropGCC (deFAULt: "/opt/parallax") installieren und das "bin"-Dir dieses Subtrees beim Bauen von PropGCC vorne in "$PATH" stehen haben.

Ich hatte "texinfo-4.13a" zufällig gerade schon in einem anderen Pfad in "/opt" griffbereit, das geht ebenso und lohnt sich natürlich, wenn man Crosscompiler für mehrere µCs selber baut, die allesamt nach dem älteren "texinfo" schreien...

Auf Jessie war dann noch eine weitere kleine Operation am Makefile notwendig, ohne die das Bauen von "binutils" und "gdb" auf die Nase knallen:

Code: Alles auswählen

diff -r e78266d5cbc7 Makefile
--- a/Makefile  Thu Oct 30 14:16:26 2014 -0500
+++ b/Makefile  Thu Jan 22 05:16:07 2015 +0100
@@ -91,7 +91,7 @@
 #
 VERSION=$(shell cat release/VERSION.txt | grep -v '^\#')
 # better revision command. thanks yeti.
-HGVERSION=$(shell hg tip --template '{rev}\n')
+HGVERSION=$(shell hg identify -n)
 
 PROPGCC_VERSION=$(VERSION)_$(HGVERSION)
 
@@ -165,7 +165,7 @@
 
 $(BUILD)/binutils/binutils-configured: $(BUILD)/binutils/binutils-created
        @$(ECHO) Configuring binutils
-       @$(CD) $(BUILD)/binutils; $(ROOT)/binutils/configure --target=propeller-elf --prefix=$(PREFIX) --disable-nls --disable-shared $(CONFIG_OPTIONS)
+       @$(CD) $(BUILD)/binutils; $(ROOT)/binutils/configure --target=propeller-elf --prefix=$(PREFIX) --disable-nls --disable-shared $(CONFIG_OPTIONS) --disable-werror
        @$(TOUCH) $@
 
 #######
@@ -231,7 +231,7 @@
 
 $(BUILD)/gdb/gdb-configured:   $(BUILD)/gdb/gdb-created
        @$(ECHO) Configuring gdb
-       @$(CD) $(BUILD)/gdb; $(ROOT)/gdb/configure $(CFGCROSS) --target=propeller-elf --prefix=$(PREFIX) --with-system-gdbinit=$(PREFIX)/lib/gdb/gdbinit $(WITH_CURSES)
+       @$(CD) $(BUILD)/gdb; $(ROOT)/gdb/configure $(CFGCROSS) --target=propeller-elf --prefix=$(PREFIX) --with-system-gdbinit=$(PREFIX)/lib/gdb/gdbinit $(WITH_CURSES) --disable-werror
        @$(TOUCH) $@

 ###########

Die Änderung an "HGVERSION" ist sinnvoll, denn sonst wird die Revisionsnummer des GIT-Repos und nicht die gerade in der lokalen Kopie aktive Revisionsummer herangezogen. Die so ersetzte Variante stammt zwar auch von meinem Kompost und stammte aus Zeiten, zu denen man sich nur für die aktuellste Revision interessierte, da keine interessanten konkurrierenden Branches im selben Repo steckten.

Die beiden anderen Pflaster fügen "--disable-werror" zu den Backzutaten von "binutils" und "gdb" hinzu und sind der lebenswichtigere Teil.

[yeti]

Das Ende ist nah!
...oder war's "ist da"?

...die GCC-Subforen im hintergroßteichigen Propellerforum sind mit den allgemeinen Propellerthemen in eine Riesenschüssel gerührt worden...
Das stellt nun unwidersprechbar SPIN und C auf dieselbe Stufe... sag ich mal frech...

Über die Konsequenzen dessen muß ich jetzt erstmal ausgiebig nachdenken... :-P