Add count-trailing-zero libcalls

[calc84maniac]

I've implemented optimized count-trailing-zero libcalls, and I have an ez80-clang commit ready to push to make it use them. They've also been added to ez80_builtin implementations where applicable, and tested via ez80_builtin/stdbit tests.

[runer112]

This unfortunately breaks the optimization of the first trailing one functions relying on this to produce an output of 8 for an input of 0, but it might be worth it?

Suggested change

	tst a, 030h
	jr z, .high2
	dec a
	and a, 014h
	ret po
	ld a, 5
	ret
	.high2:
	add a, a
	sbc a, -8
	ret p
	ld a, 6
	ret
	add a, a
	add a, a
	jr z, .high2
	add a, a
	add a, a
	sbc a, -5
	ret
	.high2:
	sbc a, -7
	ret

[runer112]

I guess this change would also hurt for maybe eventually implementing std::countr_zero, wouldn't it...

[calc84maniac]

Unfortunately, that assumption is also made by the compiler (this libcall implements CTTZ which is output by __builtin_ctz intrinsics on the Z80 target and not CTTZ_ZERO_UNDEF). Good optimization idea though, I'll have to think whether I can do something similar.

[calc84maniac]

I guess this change would also hurt for maybe eventually implementing std::countr_zero, wouldn't it...

It's actually already been implemented in the toolchain recently, and makes use of the Z80 intrinsic behavior I mentioned.

[runer112]

It occurs to me that, except for that pesky 0 case, you could potentially rework this whole routine to be based on branches after pairs of left shifts. I think whether that would be faster or not depends on the input distribution, but it would certainly be smaller.

[runer112]

Matching __icttz's first 3 bytes might compress better.

Suggested change

	ld a, l
	or a, a
	xor a, a
	or a, l

[calc84maniac]

Good point, I always forget to think about compression alongside other size optimizations.