This doesn't seem like something that should require generating assembly to solve. Couldn't `CALLBACK` just return a table, which contains both the userdata pointer to `REAL_CALLBACK` and a value for `findex`, eliminating the global variable? Then `Add` could extract that. You could even make the table returned by `CALLBACK` callable in Lua with a metatable.
Or, if you're worried about performance/memory, you could allocate a struct for `CALLBACK` to return as userdata, containing the function pointer and `findex`. If you made a little allocator for these it would be extremely fast.
I'm sure I'm missing things, but the solution you chose feels like the nuclear option.
Lua has its own allocator, which will also collect for you. lua_newuserdata. At the expense of having to set executable yourself, but without all the inbuilt inefficiencies the article points out.
I wonder if there would be a way to piggyback on top of GCC's nested function extension. It does something a little bit similar, with the dynamically generated functions.
7 comments
[ 2.8 ms ] story [ 23.5 ms ] threadOr, if you're worried about performance/memory, you could allocate a struct for `CALLBACK` to return as userdata, containing the function pointer and `findex`. If you made a little allocator for these it would be extremely fast.
I'm sure I'm missing things, but the solution you chose feels like the nuclear option.
https://news.ycombinator.com/item?id=46228597
https://news.ycombinator.com/item?id=46259334
Also talking about the Knuth boy/man test: https://news.ycombinator.com/item?id=46020151
Not a bad thing, but that really question if there is some active micro-
Lua has its own allocator, which will also collect for you. lua_newuserdata. At the expense of having to set executable yourself, but without all the inbuilt inefficiencies the article points out.
https://luajit.org/ext_ffi_semantics.html