07:31:04 kevin joined the channel
08:00:04 XanClic joined the channel
09:28:13 Biolunar joined the channel
09:51:17 Tufel joined the channel
10:07:04 Tufel: Huhu
10:08:42 xq: heya
10:24:09 Tufel: Mh joar, ich hab da ne ziemlich verrückte Frage. Und zwar möchte ich ne Funktion implementieren, an welche man einen Funktionspointer und eine Bytearray übergibt. In der Bytearray sind dabei die Übergabeparameter dekodiert.
10:24:59 Tufel: Kennt jemand ne möglichkeit so ne Funktion nur mit C bzw. C++ zu implementieren ohne dabei Assembler zu verwenden?
10:36:48 XanClic: kommt sicher auf die Calling Convention an, und ob das nur Integerparameter sind, und so
10:37:51 XanClic: aber man könnte sowas wie const size_t *p = parambuf; (((void (*)(size_t, size_t, size_t, size_t))funcptr)(p[0], p[1], p[2], p[3]); probieren
10:38:05 XanClic: mit switch-case für Parameterzahl
10:38:36 xq: Tufel: C-only nicht legal
10:38:41 xq: dafür brauchst du inline assembly
10:38:52 xq: gibt libraries, die sowas erlauben
10:39:01 xq: das wichtigste ist, dass die C-Abi fucked sein kann
10:39:06 xq: (float wird als double übergeben und sowas)
10:46:05 Tufel: Mh eine Switch-Case wäre mit am liebsten. Problem ist halt, dass man das nachher für jeden beliebigen Funktionspointer nutzen können soll.
10:46:30 Tufel: Ne Switch-Case wäre wahrscheinlich zu unflexibel.
10:47:20 Tufel: Mh gibts da dann wenigstens was in C++? Hatte schon die Idee irgendwas mit std::apply zu basteln.
10:47:21 XanClic: Du kannst den Caller auch zwingen, dass der Buffer 16 Elemente groß ist, und dann immer 16 Parameter passen :-P
10:47:46 XanClic: Aber wie gesagt, hängt auch ohne Assembler von der Calling Convention ab, obs funktioniert, und welche Parameter das tatsächlich sind
10:48:57 Tufel: Mh stimmt, wenn der Aufrufer den Stack bereinigt, können auch paar mehr Parameter übergeben werden.
10:49:15 xq: Tufel: C++ kann nur "known type "function pointer aufurfen
10:49:43 Tufel: Mh ok
10:50:02 xq: also du kannst nichts bauen, was "void* fn, void * params" aufruft
10:50:18 xq: calling convention muss sowieso bekannt sein
10:50:46 xq: https://dyncall.org/
10:50:48 xq: guck mal hier
10:51:01 Tufel: Ja, wenn die calling convention bekannt sein müssen, dann kann man eigentlich auch gleich inline-assembler nutzen
10:51:23 xq: woher soll der compiler ohne bekannte callconv wissne, was er tun soll?
10:53:27 Tufel: Mh dieses dyncall sieht auf jedenfall ziemlich interessant aus
10:53:43 xq: das tut genau das, was du willst
10:53:49 xq: mit *sehr viel* inline assembler :D
10:55:53 Tufel: Ja das mit den callconv so gemeint, dass die C-Lösung schon unabhängig von der Callconv funktionieren sollte.
10:56:31 Tufel: Mh wobei, gibts dieses dyncall auch für Embedded Systeme? XD
10:58:11 Tufel: Mh ja ich hab so langsam das Gefühl, dass an inline-Assembler kein Weg vorbei führt :|
11:30:27 kevin: Tufel: Was ist denn dein wirkliches Ziel?
11:30:48 kevin: Ich nehme an, dass Funktionspointer + Bytearray mehr Mittel zu einem Zweck ist und nicht Selbstzweck, oder?
12:04:59 Tufel: Naja, es geht um ein Testframework
12:05:20 Tufel: Wobei die Testlogik auf nem Hostsystem ist
12:06:12 Tufel: Das Hostsystem ruft dann über einen RPC-Service Funktionen auf einem Embedded-Device auf
12:06:39 Tufel: So ist zumindest mein aktuelles Konzept
12:11:51 xq: Tufel: was für ein System?
12:12:59 Tufel: Das Embedded-Device ist ein STM32H7
12:13:46 Tufel: Das Hostsystem ist ein Linux-System
12:14:56 Tufel: Die beiden Systeme kommunizieren mit UART untereinander
12:15:08 xq: guck dir mal den UART-bootloader vom STM32 an
12:15:15 xq: wir benutzen nen LPC1768
12:15:21 xq: mit dem könntest du das ganze sehr elegant lösen:
12:15:37 xq: der bootloader erlaubt dir, dinge in den ram zu kopieren und code anzuspringen
12:15:47 xq: damit kannst du nen thunk rüberschieben, der die funktion aufruft
12:18:16 Tufel: Ja das klingt ziemlich cool. Ich schau mir das mal an
12:18:58 xq: wenn der STM sowas kann, wäre das doch das, was du willst
12:29:24 Tufel: Ansich schon. Aber ich muss mir erstmal ein wenig genauer anschauen.
12:29:47 Tufel: Weiß nähmlich grad garnicht, was für nen Bootload ich eigentlich verwende
12:37:03 xq: ist wurst, die dinger haben einen eingebauten
12:37:14 xq: aber so die idee "thunk compilieren und rüberschieben" fände ich ganz nice
14:08:13 Tufel: Ja insgesamt würde die Idee schon stark von meinem Ursprünglichen Konzept abweichen. Aber die Idee ist auf jeden Fall ziemlich cool.
14:08:46 Tufel: Aber ich glaub, mein Konzept muss ich sowieso nochmal überdenken
14:40:10 xq: ich spiel ja mit dem gedanken, mal nen optimierten bootloader zu bauen, der komprimierte daten übertrgt
15:09:36 Tufel: Joar, nützlich wäre sowas auf jeden Fall. Besonders wenn man den Bootloader zum Testen nutzt
15:11:25 xq: naja, dann nicht :D
15:11:35 xq: da hast du keine groß genugen datenmengen
17:15:56 Tufel joined the channel
18:01:26 Tufel joined the channel
18:57:21 Tufel: Ich geh mal offline. bb
18:59:02 Paddy joined the channel
20:26:50 CubeCoder joined the channel
20:26:57 CubeCoder: moin
20:33:13 Paddy: Moin
20:36:56 CubeCoder: wie gehts wie stehts?
20:56:16 Paddy: Jo, ganz okay. In Bezug auf on-topic-Themen bin ich zwiegespalten, ob ich die tyndur-Patches bearbeiten soll oder nicht, wenn ich doch gerade 42 ungelesene Mails im tyndur-devel-Order habe.
20:57:09 CubeCoder: wenns nur das ist :D
20:58:37 Paddy: Treibst du noch ab und zu was OS-Dev-mäßiges?
21:00:21 CubeCoder: ne sonst wäre ich öfter hier gewesen wollte mich aber wieder bisschen reinarbeiten :D
21:01:03 CubeCoder: will jetzt erstmal assambler verstehen ich glaube danach wird es einfacher als letztes mal
21:01:20 Paddy: Das könnte helfen, ja