Forum: Compiler & IDEs Makefile und flags für Raspberry 4 64bit


von An B. (anbad)


Lesenswert?

Hallo,
könnte mir jemand bitte helfen, die Makefile.arm umzuschreiben für 
Raspberry 4 mit 64bit Betriebsystem?
Ich muss zugegeben, ich habe keine Ahnung, wie man das macht. Ich habe 
zwar jetzt über mehrer Tage immer wieder mal probiert mich reinzufuxen, 
aber ich bekomme es nicht hin.

https://github.com/baycom/tfrec

Makefile.arm:
------------------------------------------------------------------------ 
-----------
PACKAGES= librtlsdr

CXX=g++

PROFILING=
DEFINES=
PKG_INCLUDES= $(shell pkg-config --cflags $(PACKAGES))
PKG_LIBS= $(shell pkg-config --libs $(PACKAGES))

CXXFLAGS=-O3 $(PROFILING) -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard 
-ftree-vectorize -ffast-math \
              -std=c++0x -Wall \
              -Wno-unused-function  -Wno-unused-variable 
-Wno-unused-but-set-variable \
              -Wno-write-strings

INCLUDES= $(PKG_INCLUDES)

LIBS=-lm $(PKG_LIBS) -lpthread
LDFLAGS=$(PROFILING) -rdynamic

CFILES=main.cpp engine.cpp  dsp_stuff.cpp fm_demod.cpp decoder.cpp 
crc8.cpp \
        tfa1.cpp tfa2.cpp utils.cpp sdr.cpp whb.cpp crc32.cpp

OBJS = $(CFILES:.cpp=.o)

all: tfrec

tfrec: $(OBJS)
         $(CXX) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)

.cpp.o:
        $(CXX) $(CXXFLAGS) $(DEFINES) $(INCLUDES) -c $<

ifneq ($(MAKECMDGOALS),clean)
include .depend
endif

.depend: Makefile
        touch .depend
        makedepend $(DEF) $(INCL)  $(CFLAGS) $(CFILES) -f .depend 
>/dev/null 2>&1 || /bin/true

clean :
        $(RM) $(OBJS) *~
        $(RM) tfrec
        $(RM) .depend

gcc -c -Q -mcpu=native --help=target:
------------------------------------------------------------------------ 
---

 -mabi=                                lp64
  -march=                               armv8-a
  -mbig-endian                          [disabled]
  -mbionic                              [disabled]
  -mbranch-protection=
  -mcmodel=                             small
  -mcpu=                                cortex-a72
  -mfix-cortex-a53-835769               [enabled]
  -mfix-cortex-a53-843419               [enabled]
  -mgeneral-regs-only                   [disabled]
  -mglibc                               [enabled]
  -mharden-sls=
  -mlittle-endian                       [enabled]
  -mlow-precision-div                   [disabled]
  -mlow-precision-recip-sqrt            [disabled]
  -mlow-precision-sqrt                  [disabled]
  -mmusl                                [disabled]
  -momit-leaf-frame-pointer             [enabled]
  -moutline-atomics                     [enabled]
  -moverride=<string>
  -mpc-relative-literal-loads           [enabled]
  -msign-return-address=                none
  -mstack-protector-guard-offset=
  -mstack-protector-guard-reg=
  -mstack-protector-guard=              global
  -mstrict-align                        [disabled]
  -msve-vector-bits=<number>            scalable
  -mtls-dialect=                        desc
  -mtls-size=                           24
  -mtrack-speculation                   [disabled]
  -mtune=                               cortex-a72
  -muclibc                              [disabled]
  -mverbose-cost-dump                   [disabled]

  Known AArch64 ABIs (for use with the -mabi= option):
    ilp32 lp64

  Supported AArch64 return address signing scope (for use with 
-msign-return-address= option):
    all non-leaf none

  The code model option names for -mcmodel:
    large small tiny

  Valid arguments to -mstack-protector-guard=:
    global sysreg

  The possible SVE vector lengths:
    1024 128 2048 256 512 scalable

  The possible TLS dialects:
    desc trad

von Εrnst B. (ernst)


Lesenswert?

Hab grad keinen RPi im Zugriff um's zu testen, aber ich würde damit 
anfangen

"-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard"

aus den CXXFLAGs zu entfernen.
Dann sollte es kompilieren & laufen, wenn auch evtl. mit suboptimaler 
Performance.

wenn's nicht reicht, -march=host oder so versuchen.

von An B. (anbad)


Lesenswert?

Εrnst B. schrieb:
> Dann sollte es kompilieren & laufen, wenn auch evtl. mit suboptimaler
> Performance.

Hallo,
hat funktioniert. Prima!! Tausend Dank.

Zwei Fragen aber dennoch:
1) Was bedeutet "suboptimaler Performance"? Betreffend des 
Compiling-Process oder betreffend der erstellten Ausgabedatei, die dann 
später schlechter performt?
2) Ich verstehe es so, dass die CXXFLAGS Angaben zum Raspberry 4 sind; 
Software und Hardware, korrekt? Wo kann ich nachlesen, was das alles zu 
bedeutet hat. Ich habe da schon im Internet gesucht, aber nix wirklich 
gefunden, so dass ich als Laie das verstehe.

Trotzdem schon mal tausend Dank. Es läuft soweit. Mal sehen, werde jetzt 
ein paar Tage es laufen lassen. Mal schauen, ob die Datei dauerhaft 
funktioniert.

vg

von Εrnst B. (ernst)


Lesenswert?

An B. schrieb:
> 1) Was bedeutet "suboptimaler Performance"? Betreffend des
> Compiling-Process oder betreffend der erstellten Ausgabedatei, die dann
> später schlechter performt?

letzteres.

An B. schrieb:
> Ich verstehe es so, dass die CXXFLAGS Angaben zum Raspberry 4 sind;

Es sind Optionen für den Compiler, u.A. welche 
Hardware/Coprozessoren/Beschleunigungsfunktionen/.... er 
voraussetzen&verwenden darf.

An B. schrieb:
> Es läuft soweit.

Sollte es. Evtl. etwas langsamer als möglich (=> verbraucht mehr 
CPU-Leistung und damit Strom), aber solange die CPU nicht am Anschlag 
ist ("top" betrachten) sollte das völlig egal sein.

Die wichtigsten Optimierungen kommen eh durch das "-O3", und das ist ja 
drinnen geblieben.

von An B. (anbad)


Lesenswert?

Εrnst B. schrieb:
> Sollte es. Evtl. etwas langsamer als möglich (=> verbraucht mehr
> CPU-Leistung und damit Strom), aber solange die CPU nicht am Anschlag
> ist ("top" betrachten) sollte das völlig egal sein.

Das Script dient dazu einem SDR-Receiver es zu ermöglichen 
Billig-Funksender empfangen zu können. D.h. das Script auf einem 
Raspberry läuft 24/7. Ich kann im Moment zwar keine erhöhte CPU 
feststellen. Der SDR-Receiver und auch USB-Hub (für Stromliefdrung) 
werden sehr war, fast heiß. Jetzt bin ich mir nicht sicher, ob das vlt. 
(auch) am weniger guten kompelierten Script liegt.

Wir kommst Du auf: "-march=host oder so versuchen."? Wo hast Du das her? 
Wie kann ich das lernen (um das Compiling verbessern zu können)?

vg

von Εrnst B. (ernst)


Lesenswert?

An B. schrieb:
> Wir kommst Du auf: "-march=host oder so versuchen."? Wo hast Du das her?
> Wie kann ich das lernen (um das Compiling verbessern zu können)?

https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/AArch64-Options.html#g_t-march-and--mcpu-Feature-Modifiers

-march=native oder -mtune=native würden den Compiler erkennen lassen, 
auf welchem System er läuft, und entsprechend optimieren.

(Unterschied: bei -mtune bleibt das binary trotzdem zu anderen CPUs 
kompatibel, -march kann deshalb besser/aggresiver optimieren)

von An B. (anbad)


Lesenswert?

Hallo,
habe es jetzt mit -march=native compiled. Und tatsächlich, das USB-Hub 
scheint bei weitem nicht mehr so heiß zu laufen und auch der 
SDR-Receiver wird weniger heiß.
Aber, wenn ich mich jetzt nicht irre, braucht der SDR-Rceiver jetzt ca. 
170 mA mehr an Strom. Das ist ja auch OK. Besser als das alle so heiß 
wird.
Werde die Tage nochmals testen. Vlt., so wie ich gesehen habe, anstatt 
der navtive-Erkennung kann man ja glaube ich, auch direkt das System 
angeben... arch8-a oder so.
Ich muss jetzt mal schauen, ob man die Systemlast der compiled-Datei 
sich anzeigen lassen kann. Dann würde ich mal die Datei so und anderes 
laufen lassen.
Auf jeden Fall hast Du mir viel geholfen.
Tausend Dank, auch für das LINK zur Help des Compilers.
vg

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.