Originally Posted By Deunan Knute
- dead code
What is RBUFDST=AICA->RINGBUF+AICA->BUFPTR; in aica.c doing exactly?

It is vestigial code (used in FM processing) left over from the SCSP-->AICA conversion.

Originally Posted By Deunan Knute
- bug
PACK generates malformed (or is it supposed to be that way?) codes. Test case: 0xfffff800.
My encoder packs it to 0xe000, yours to 0xf800. This is already a special case, as there are >12 same bits in front.
As for decoder, mine will resolve both codes to 0xfffff800, yours to 0xfffff000. I'm not so sure my version is the good one though.

Yeah, looks like a bug to me. Since it was only occurring with negative denormals, it didn't have much of an effect on the quality of the DSP output.

Here's a patch that should fix it:

diff -Nru aosdk_base/eng_dsf/aicadsp.c aosdk/eng_dsf/aicadsp.c
--- aosdk_base/eng_dsf/aicadsp.c	2008-03-07 22:20:20.000000000 -0800
+++ aosdk/eng_dsf/aicadsp.c	2008-03-13 21:04:49.000000000 -0700
@@ -25,6 +25,7 @@
 		val <<= 11;
 	val >>= 11;
+	val &= 0x7FF;
 	val |= sign << 15;
 	val |= exponent << 11;
@@ -41,7 +42,10 @@
 	mantissa = val & 0x7FF;
 	uval = mantissa << 11;
 	if (exponent > 11)
+	{
 		exponent = 11;
+		uval |= sign << 22;
+	}
 		uval |= (sign ^ 1) << 22;
 	uval |= sign << 23;

Originally Posted By Deunan Knute
- bug
Neill's doc suggests this should be exactly the opposite? Also, why not always mask ADRS_REG here to 0xfff and not in address computation?

I believe ADRS_REG is handled correctly in AO. The Saturn dAsms User's Manual (page 18) indicates that ADRS_REG is derived from INPUTS in 3 out of the 4 different store modes and I wouldn't expect the AICA DSP to be any different. Also, note that in the current ADRS_REG handling, when SHIFT==3, SHIFTED is cleanly split at the bit-level into integer and fractional parts (ADRS_REG and FRC_REG). It wouldn't make any sense at all to require two different SHIFT values, and hence require 2 DSP instructions instead of 1, to do this.