The sed string was more of a meta comment about how you were recreating gcc attributes in zig. I don’t mind either syntax, and I like the idea too. I actually like the c++ (eg) [[layout:c]] syntax the best.
re: slices on the stack. If I remember they were passed on the stack fine. I haven’t looked too in depth, but I think zig just follows the sysv spec. Zig could just use fastcall and thiscall for its base and make some changes from there. I was specifically looking at reutrns and noticed the slices were coming back on trhe stack.
I hear adding new calling conv to llvm isn’t trivial. I’ve disliked the idea of ZFS going and doing their own backend and codegen, but maybe making it easier to experiment with different calling conventions could be a big bonus.
I’ve used the techniques described here with great success when targeting resource-constrained MCUs; and like @nyc has suggested, putting the link pointer at the beginning of my Elem structure just made everything easier.
In my world, however, it’s often the case that ALL memory is statically allocated – which is to say that my arbitrarily complex “web” of nodes is “pre-wired”.
But then I ran into a limitation discussed in this post, where (very!!) ancient issue #131 describes the problem.
[[ good news and bad news here? @mlugg does have this on his (full!) plate; but it’s currently targeted for 0.14.0 from what I can understand ]]
In the meanwhile, I’m continuing to evaluate alternatives to (efficiently!) implementing these sorts of statically-declared (recursive) web of nodes.
What about “intrusive” types? I see Zig community members also periodically using those types. I’m wondering if I should consider building an intrusive version of my data structure.
On HN an article on Starcraft poped up and, in the comment section, one of the original Starcraft coder (Patrick Wyatt) commented which prompted another commenter to point at his blog which talks about intrusive list.
]]