fast 16bit clamping arithmetic? (was: "Inline decorator?")

[Lana-chan]

I'm trying to write an inline assembly function for an ESP32-S3FN8. mpy-cross works for generating precompiled binaries when passing the xtensawin architecture, however when i try to use @micropython.asm_xtensawin i get SyntaxError: invalid micropython decorator. Viper and native decorators work fine otherwise. Is there something I'm missing?

[Lana-chan]

well, time to answer my own question once again

it appears xtensawin doesn't have an inline option, only native emitter. So to turn this into another question, I'm using xtensawin because I saw somewhere that xtensa is for ESP8266 and xtensawin is for ESP32. is that the case or is there some confusion? is there a technical reason why xtensawin can't have inline assembly?

EDIT: let me rephrase.. what i need is not necessarily xtensawin inline assembly, but rather i'm trying to do 16bit clamped addition very quickly. i have a viper function that calls on this:

_INT_MINVAL = const(-32768)
_INT_MAXVAL = const(32767)
@micropython.native
def _16bit_clamp_add(a, b):
	a = -(~a & 0b0111111111111111) - 1 if a & 0b1000000000000000 else (a & 0b0111111111111111)
	b = -(~b & 0b0111111111111111) - 1 if b & 0b1000000000000000 else (b & 0b0111111111111111)
	res = a+b
	res = (_INT_MINVAL if res < _INT_MINVAL else _INT_MAXVAL if res > _INT_MAXVAL else res)
	if res < 0:
		return res & 0b0111111111111111 | 0b1000000000000000
	return res & 0b0111111111111111

prior to this, this entire block was replaced by a simple line in viper that was (consider out and in both results of ptr16 addressings)

out += in

and is now

out = _16bit_clamp_add(out, in)

due to the addition overflowing in 16bit arithmetic. however, the code (part of an I2S audio library) no longer performs as quickly, causing dropouts. is there a better way to approach this? the reason i'm using native instead of viper is viper lacking the ~ operand.

[dpgeorge]

So to turn this into another question, I'm using xtensawin because I saw somewhere that xtensa is for ESP8266 and xtensawin is for ESP32. is that the case or is there some confusion? is there a technical reason why xtensawin can't have inline assembly?

Yes, xtensa is for esp8266 and xtensawin is for esp32 (Xtensa variants, not the esp32-c3 variant which is RISC-V).

The difference is that "win" means "windowed register ABI", so the way arguments are passed between functions (at the machine code level) is different.

xtensawin can have inline assembly, but we just haven't implemented it yet.

...
however, the code (part of an I2S audio library) no longer performs as quickly, causing dropouts. is there a better way to approach this? the reason i'm using native instead of viper is viper lacking the ~ operand.

Using viper is definitely the right approach here! Calling into @micropython.native will be a lot slower because there's a lot of argument marshaling and object conversion.

Unfortunately none of the unary operators (like - and ~) are implemented for viper. But you can actually synthesis them pretty easily. Eg ~ would be:

    x = int(123)
    x_tilde = (0 - x) - 1

The above code will work in viper.

[Lana-chan]

thank you! however i'm not sure i follow. the following:

INT_MINUS_40 = 0b1111111111011000
INT_PLUS_40 = 0b00101000
@micropython.viper
def test():
	print(bin(0 - int(INT_MINUS_40) - 1))
	print(bin(int(INT_PLUS_40)))
test()

yields:

-0b1111111111011001
0b101000

if there's any way to leverage the (30? 31? 32? i can't find documentation for how many bits before an int becomes an object in viper) bit arithmethic to do this addition, i'd happily rework my entire logic instead. what i'm looking for is if the result of an addition overflows the 16bit int boundaries (-32768, 32767), then clamp to those limits. that's what i'm trying to figure out a way to do in viper

[Lana-chan]

here's what i have after some experimentation:

INT_MINUS_40 = 0b1111111111011000
INT_PLUS_40 = 0b00101000
@micropython.viper
def test():
	print(0 - (0b10000000000000000 - int(INT_MINUS_40)))
	print(int(INT_PLUS_40))
test()

yields:

-40
40

however, the following just produces garbage noise:

bsmp = 0 - (0b10000000000000000 - int(smp[ptr])) if smp[ptr]& 0b1000000000000000 else smp[ptr]
buf_now = 0 - (0b10000000000000000 - int(buf[i])) if buf[i] & 0b1000000000000000 else buf[i]
res = bsmp + buf_now
res = (_INT_MINVAL if res < _INT_MINVAL else _INT_MAXVAL if res > _INT_MAXVAL else res)
if res < 0:
	buf[i] = res & 0b0111111111111111 | 0b1000000000000000
else:
	buf[i] = res & 0b0111111111111111

what am i missing?

[Lana-chan]

clamping bit values after a bit shift. that's what i'm missing. this is the actual full code now

			if vol < 0:
				bsmp = bsmp = (bsmp & 0b1000000000000000) | (((bsmp & 0b0111111111111111) << int(abs(vol))) & 0b0111111111111111)
			else:
				bsmp = (bsmp & 0b1000000000000000) | ((bsmp & 0b0111111111111111) >> vol)
				if (bsmp & 0b1000000000000000) != 0:
					bsmp |= (0b111111111111111 << 15-vol)
			bsmp_int = 0 - (0b10000000000000000 - int(bsmp & 0b1111111111111111)) if bsmp & 0b1000000000000000 else bsmp
			buf_int = 0 - (0b10000000000000000 - int(buf[i] & 0b1111111111111111)) if buf[i] & 0b1000000000000000 else buf[i]
			res = bsmp_int + buf_int
			res = (_INT_MINVAL if res < _INT_MINVAL else _INT_MAXVAL if res > _INT_MAXVAL else res)
			if res < 0:
				buf[i] = (res & 0b0111111111111111) | 0b1000000000000000
			else:
				buf[i] = res & 0b0111111111111111

and if anyone has ideas how to refactor this, i'm all ears

[peterhinch]

I feel I must be missing something here, but the following works to clamp a value as you require:

@micropython.viper
def test(x):
    return max(0-32768, min(x, 32767))

[Lana-chan]

right, i should clarify: yes, that does the same as the current line of code:

res = (_INT_MINVAL if res < _INT_MINVAL else _INT_MAXVAL if res > _INT_MAXVAL else res)

however, the biggest issue is how the values i'm working with are signed 16bit, so i need to convert them from ptr16 results into int first (by checking the 16th bit and subtracting a value or not. and then recombining them into signed 16bit values from python int after adding and clamping. there doesn't seem to be a more direct way to do arithmetic on those values otherwise, that i could find

EDIT: to further illustrate,

INT_MINUS_40 = 0b1111111111011000
INT_PLUS_40 = 0b00101000
@micropython.viper
def test():
	print(int(INT_MINUS_40))
	print(0 - (0b10000000000000000 - int(INT_MINUS_40)))
	print(int(INT_PLUS_40))
test()

yields:

65496
-40
40

meaning that taking a signed negative 16 bit value resulting from a ptr16 memory addressing and casting it as int yields an incorrect value. to correct that we need to subtract the value from a constant (65536) in order to make it positive and then "subtract" that result from 0 to give it a python sign instead. i was simply wondering if there was a better way to do that cast within viper

and since writing the last comment, i realized i could simplify that code into this:

bsmp_int = 0 - (0b10000000000000000 - int(bsmp)) if bsmp & 0b1000000000000000 else bsmp
buf_int = 0 - (0b10000000000000000 - int(buf[i])) if buf[i] & 0b1000000000000000 else buf[i]
if vol < 0:
	bsmp_int <<= (0-vol)
else:
	bsmp_int >>= vol
res = bsmp_int + buf_int
buf[i] = (_INT_MINVAL if res < _INT_MINVAL else _INT_MAXVAL if res > _INT_MAXVAL else res)
if res < 0:
	buf[i] |= 0b1000000000000000

[mendenm]

my viper snippet for something like this in viper mode looks like:

ctb = ptr16(blah)
cossum = 0
while ci < count:
  c = ctb[ci] #this comes in as an unsigned16 from ptr16
  cossum += v * (c if c < 0x8000 else c - 0x10000) #fix sign

where cossum is a normal viper

[Lana-chan]

i'm not sure why i didn't think of doing number - maxval rather than 0 - (maxval - number) to get an int. i think i worked my way backwards from the end and missed the obvious 😅 that's what these posts are for, thank you!