STM32G431: Compilerunterstützung für Mathematical hardware accelerators

[[e-mail] (Gast)]

Hallo,

unterstützt die eabi-Toolchain schon die Mathematical hardware 
accelerators für STM32G431?

[Gerd E. (robberknight)]

[e-mail] schrieb:
> unterstützt die eabi-Toolchain schon die Mathematical hardware
> accelerators für STM32G431?

Du meinst die CORDIC- und FMAC-Einheiten, korrekt?

Ich fürchte da wird eine "Compilerunterstützung" schwer. Denn die sind 
nicht Teil des CPU-Kerns, sondern das sind separate Hardwareeinheiten, 
die parallel zur CPU laufen. Der Compiler kann also keine Befehle 
erzeugen mit denen die angesteuert werden.

Du musst die stattdessen wie andere Peripherieeinheiten über Register 
ansteuern. Daher sehe ich die eher als Thema für eine spezielle 
Bibliothek als für den Compiler. Leider.

[[e-mail] (Gast)]

Gerd E. schrieb:
> Du meinst die CORDIC- und FMAC-Einheiten, korrekt?

Ja. Danke.

Habe mir mal das Referenz Manual kurz angeschaut. Das geht, wie gesagt, 
in die Richtung spezieller Libraries.

[Irgend W. (Firma: egal) (irgendwer)]

[e-mail] schrieb:
> Habe mir mal das Referenz Manual kurz angeschaut. Das geht, wie gesagt,
> in die Richtung spezieller Libraries.
ST bietet dafür ja einiges an. Z.B.:

- 
https://github.com/STMicroelectronics/STM32CubeG4/blob/master/Projects/NUCLEO-G474RE/Examples_LL/CORDIC/CORDIC_CosSin/readme.txt
- 
https://www.st.com/resource/en/application_note/dm00614795-getting-started-with-the-cordic-accelerator-using-stm32cubeg4-mcu-package-stmicroelectronics.pdf

[QQ (Gast)]

Gerd E. schrieb:
> Ich fürchte da wird eine "Compilerunterstützung" schwer. Denn die sind
> nicht Teil des CPU-Kerns, sondern das sind separate Hardwareeinheiten,
> die parallel zur CPU laufen. Der Compiler kann also keine Befehle
> erzeugen mit denen die angesteuert werden.
> Du musst die stattdessen wie andere Peripherieeinheiten über Register
> ansteuern. Daher sehe ich die eher als Thema für eine spezielle
> Bibliothek als für den Compiler. Leider.

Ich kenne mich mit den Interna von Compilern nicht aus, aber wäre es 
nicht möglich eine Art "virtuelle Befehle" zu zu implementieren, die 
eben in eine Befehlsfolge übersetzt wird? Paralellitäten sollten so doch 
sogar effizienter vom Compiler lösbar sein, vor Allem wenn gewisse 
Registerzugriffe in beliebiger Reihenfolge stattfinden können?

[Gerd E. (robberknight)]

QQ schrieb:
> aber wäre es
> nicht möglich eine Art "virtuelle Befehle" zu zu implementieren, die
> eben in eine Befehlsfolge übersetzt wird?

Du bekommst das selbe Problem das Hardware-FPUs jetzt schon haben, nur 
noch in viel schlimmer: Du musst beim Aufruf anderer Funktionen den 
Zustand der Einheiten sichern und beim Rücksprung wiederherstellen.

Vor allem ist das auch nötig wenn Du in einen Interrupt springst. Die 
nötigen Befehle um das zu machen erhöhen Deine Interruptlatenz sehr 
deutlich. Schon mit Hardware-FPUs ist das ein Problem. Wenn es auf 
Interruptlatenz ankommt, ist es nicht unüblich auf die Hardware-FPU ganz 
zu verzichten, einfach nur um die FPU-Register nicht mit sichern und 
wiederherstellen zu müssen.

Das Sichern der zusätzlichen Register bedeutet dann am Ende auch eine 
neue ABI, Du kannst Programme die mit und ohne diese Option compiliert 
wurden nicht mehr miteinander mischen.

Ich denke der ganze Aufwand lohnt sich einfach nicht. Über eine 
Bibliothek kannst Du das einfacher und gezielter ansteuern, ohne gleich 
ganze Fundamente wie die ABI über den Haufen werfen zu müssen. Bei 
Grafikkarten und Rechenbeschleunigern für PCs wird das ja auch so 
gemacht, da gibt es OpenCL, CUDA etc. um die einzubinden und keinen 
neuen Compiler.