Also, if I sv_2mortal(ST(0)); before returning ST(0) I get the "Attempt to free unreferenced scalar" warning again.

XSPP (I know your using something different), if you make a XS func with SV * as the return type, rather than void and PPCODE:, XSPP will throw in a sv_2mortal secretly on the "return" SV *. I always put " XSOPT => ' -nolinenumbers '," in my makefile.pl since the #line preprocessor that XSPP puts in drive my C debugger mad.

I'm not sure if the count check makes sense

Yes, it's something I've just copied verbatim from the perlcall examples, without any appreciation of it's siginificance. The error message is "Big trouble", which would be a very appropriate message if G_SCALAR is supposed to force the count as you say ;-)

I reread the perl source code, egh, the count check makes sense, see perl.c#l2736 in perl.git and pp_hot.c#l2776 in perl.git, sometimes perl fixes up the stack, often it doesn't, I guess from reading the code. If adder() is something you wrote and control, put the count check in a assert, the runtime overhead isn't worth it. PL_sv_count tip is great. I never knew that before. I also think (its been a while since the first and last time I did it), if you leave out the PUSHMARK, the callee will inherit your XSUB's stack/@_, sometimes its what you want. I generally keep the SAVE/FREETMPS out, I know the caller/entersub will clean up the mortals for me normally. By batching more mortals together for freeing, I will presume its faster than 2 separate SV freeing sessions because of CPU caching. Of course follow the event loop warning in perlcall. The ax fixup I can't comment on.