writing C++ wrappers around SDL code so i can use them in LRDL becomes a strain.
i want to talk to SDL directly. but for that, i need to generate declarations from SDL header files. i do have the generator from a previous prototype (written in python), just need to change the target syntax a little.
but i first need LRDL to support C pointers, enums, arrays, structs and unions, so we have full C ABI support.
altering the header translator turns out to be a bit more involved, since before there were no pointer types, which made it easier to deal with recursive references.
so now i have to restructure a bit, and also support more types...
host table impls need to implement SDL_gpu upload/download locally; no global system.
tables accessed from gpu cases need a parallel implementation in slang; slang has limited support for generics - what i can't get to work there, i'll do with macros.
the language is asking a lot of the compiler. the existing code generator is not suited to generate code for two different targets simultaneously.
for instance: tables need to be properly tagged where they are accessed, so we declare them in the right places. not every generated compute shader needs all of the tables, so we need to generate only the ones used by that shader.
i don't like how chaotic the compiler code is becoming already.
yesterday i thought i'm going to port analysis / code generator to soufflé datalog and embed the engine in the compiler again, with the goal of encoding complex processing in an easier to maintain format.
but the compiler is already far enough to replace parts of itself.
so instead, i'll port analysis and code generator to LRDL, and generate C++ source code from it. (i call this process "retconning")
presently, tables hold back new insertions until update() has been called on them, which happens before the first read.
however, tables can practically already mutate on insert, because the scheduling already ensures that reads occur only after all insertions - with one exception: cues, which are backedge insertions that need to be scheduled for the next iteration.
therefore update() needs to be called only at the end of an iteration.
changed when table updates happen and refactored the most important containers for it (they can now take a more efficient route for simple insertions).
the fibonacci test seemed a little dissatisfying since it can only linearly complete the table, so i added this other iterative example which can be parallelized per iteration.