Gregory's Server@bd nono, I don't want to create a copy of the stack..
Like, I mean, I think we should create a new Uxn for the thread, instead of shoving the audio stacks into the main uxn instance that's evaluating the program.
|
6 comments
 @bd It depends, why are the stacks global? Are they mapped to the ram someplace?  @neauoire not really, just how I organized it for simplicity as this implementation came as a port of my ARM ASM core. I can wrap it in a struct, makes no difference @bd aah okok :) I'm just trying to find a way to explain this as simply as possible for the docs. There's antecedants where I use devices to call threads with new uxn instances with private stacks, and if the audio logic uses something similar that makes explaining this more standard than, also since the code is a source of documentation, I wouldn't want audio things in the uxn core since there's device facilities already. I'm just trying to make sense of it in my head so I can explain it too @neauoire no worries, I feel you I can clean up the code and move a few things around. Also I’ll try to help in writing the docs as I mentioned. Just want to make sure we are on the same page haha If all is good I’ll do the sdl port and there I’ll try to use the same general structure in place. Will keep an instance of audio specific UXN struct on the audio .c files @bd perfect, yeah, as much portable code as possible the better, you'll see that the sdl/x11 port have a special structure where it reuses as much device code as possible. Everything looks good on my end with the new audio device. |
@neauoire the new UXN core fast implementation takes the PC vector and two stack pointers, one for wst and other for rst. Ram and stacks are globals. For the sdl implementation we can have a new instance of the UXN struct as you say, since the evaluation function takes a struct iirc.
In either case the behavior is the same right? Or am I missing something?