AVR Freaks

it still is early here, but I think the difficult part here is that you have to take care that you do not take only 15 bits if you have a negative number.

I would first strip the minus sign if it is present, and then return the 16bits you want by doing a shift and a type cast.

I think the function MattRW has made does that, but that is easily checked by giving it a known number

It looks like Matt's code will give 15-bit numbers for

both positive and negative inputs, so change the

divisor to 0x8000.

There's also an edge case for when the input is the

most negative 32-bit number (0x80000000).  The

negative of this is maybe even undefined in the C
standard (I don't remember), but in practice you

get the same number back, which when divided by

0x8000 and converted to uint16_t gives zero!

So add a check for 0x80000000 and return 0xFFFF.

--Mike

That's the name of most of my programs!!!  ;-)

--Mike

You said you wanted the absolute value. What's wrong with the straightforward

int32_t src = ...;
uint16_t dst = labs(src) >> 16;

?

It is not clear what 16 bits you are talking about though in the subsequent messages. 16 upper value bits bits of absolute value (i.e. not including the zero sign bit)? Then its just

int32_t src = ...;
uint16_t dst = labs(src) >> 15;

I don't understand what is the point of any convoluted/multi-storied manipulations of the value when you can just directly state what you want. This is also an efficient way to do this, considering that `abs` is a built-in function in GCC.

In C code you will have to choose the proper version of `abs` depending on how the width of `int32_t` relates to the width of `int`. Or you can write your own `abs` as `(src >= 0 ? src : -src)`. (I used `labs` under assumption that `int` is a 16-bit type.)

Um... But this is the only way to use unary minus! What other uses could you possibly be implying?

After a bit of thought, I came up with an even dirtier trick.

See, my assembler routine doesn't need any high-side registers, but I didn't put in the preamble nor postamble that would protect registers and pointers and all that.  The problem was preserving the SREG - the status register.  To efficiently preserve that, you needed a high-side register.  So, you should not do what I said to do, and do something slightly different instead...

32s-16u-TRUNCATE:
push r0  ; just preserving registers, here.
push r1
push r2  ; And we don't need r3- see below
push ZL
push ZH  ; 'cause we'll be mucking with the Z pointer

; But we don't have to store and restore the SREG
; 'cause we're about to get clever

ldi ZL, low(32s-SOURCE)
ldi ZH, high(32s-SOURCE)

;We're big-endian here, so let's get the MSB first
ld r2, Z+
ld r1, Z+
ld r0, Z+
; We have no need for the low byte
; We're going to throw it away anyhow

rol r0  ; This is a change from my first idea
rol r1  ; Moving on
rol r2  ; Shoving the sign bit out into the carry

; Which trashes the carry flag in SREG
; Typically, we'd have to deal with this by storing and restoring
; the SREG, but because of the change...

ldi ZL, low(16u-DESTINATION)
ldi ZH, high(16u-DESTINATION)
; With carefully organized memory, this can be made more efficient

st Z+, r2
st Z+, r1   ; Deliberately throwing away r0, until...

ror r0      ; Putting the carry flag back!  HA!

pop ZH
pop ZL
pop r2
pop r1
pop r0

ret     ; And Bob's your uncle.

That is already incorrect/misleading, under assumption that you are talking about regular 2's-complement platform. You just said that your original values are signed. That means that the "unused" bits will be either all-zero (for non-negative values) or all-ones (for negative values). "Unused" bits on a 2's-complement platform always contain a copy of the sign bit (!). The upper portion of a negative value is always filled with 1's. So, your "always zero" claim seems to make no sense.

In any case, on a 2's complement platform in order to truncate a 32-bit signed integer into a 16-bit signed integer in accordance with the algorithm you described (discard upper 9 bits, discard lower 8 bits, preserve sign) you don't need to worry about the sign bit as a separate entity at all. It is just plain and simple

int32_t src = ...;
int16_t dst = src >> 8;

There's no need for any manipulations with sign bit or any bit masks.

(And no, there no way to make it more efficient through using assembler.)

You can use union as a way to discard the lower 8 bits, but normally it is not worth it. The compiler is smart enough to realize that in a `>> 8` shift the lowest byte of the original value can be discarded as whole.

No, of course not. No self-respecting compiler will implement a shift by 8 bits as a sequence of single-bits shifts. It is also not clear why you want to "mask" anything. If the upper 8 value bits are unused (as you stated) then a `>> 8` shift will produce a value that will fit perfectly in a `int16_t` without any masking.

As I said

int32_t src = ...;
int16_t dst = src >> 8;

and that's it. Everything else is a solution looking for a problem.

int16_t __attribute__ ((noinline)) foo(int32_t src) 
{
  return src >> 8;
}

Compiling for `-Os`

clr r27
sbrc r25,7
dec r27
mov r26,r25
mov r25,r24
mov r24,r23
ret

No repetitive shifts, as you see. No shifts at all, actually. This is still less efficient than it could have been: the compiler bothers to form values in `r27` and `r26`, which is completely unnecessary. But if the code is allowed to inline into the actual calling context, it might easily become much more efficient.

It is specified in the language standard.

1. If the original `int32_t` value fits into the range of `int16_t` type then it is guaranteed that the assignment will preserve the value. E.g. `-5` of type `int32_t` is guaranteed to become `-5` of type `int16_t`. Which means, of course, that in 2's-complement representations the lower 16 bits are taken.

2. If the original `int32_t` value does not fit into the range of `int16_t` type, then the result is implementation-defined. In real life this also means that the compiler will simply take the lower 16 bits of the original value.

In your case, under your conditions (as you stated them), the value will fit, meaning that the branch 1 applies.

Because in C and C++ conversions between arithmetic types are implicit. There's no need for an explicit cast.

However, some overcautious compilers might issue warnings for narrowing conversions. Just to suppress such warnings you might want to add a cast. By using a cast you tell the compiler that "yes, this is what I really want to do". But the language itself does not require any casts in this case.

The only exception from this rule is `{}` initializers in C++ (C++11 and later). Such initializers do not allow implicit narrowing conversions. But this is not our case.

Yes, but all data type conversions in C and C++ separate into two categories:

1. Conversions that can be done implicitly.

2. Conversions that require an explicit cast.

Conversions between arithmetic types in C and C++ belong to the first category.

P.S. This applies to contexts that naturally imply a conversion, e.g. assigning a 32-bit value to a 16-bit variable. If the conversion is not implied by the context, you have to use an explicit cast to change the type, e.g. multiplying two 16-bit values produces 16-bit result unless you explicitly cast one of the operands to 32-bit type.

This may be too crude, but I'd be pleased to see you test it out.   I just stepped through one example on my simulator to see it looks to be working.

All math is signed.   When squaring hi:lo, it only accumulates hi*hi, hi*lo and lo*hi; lo*lo is ignored.

You pass pointer to an array of 3 int16_t.  EDIT: Oh, and assumes the bias is removed before calling.

EDIT: Above should read "accumulation of hi8(hi*lo) and hi8(lo*hi)".

  int16_t v[3], r;

  v[0] = 124;
  v[1] = 31123;
  v[2] = -30999;

  r = sumsq3_16(v);

	.section .text
	.global sumsq3_16

	.type sumsq3_s16,function
	;; int16_t sumsq3_16(int16_t *v)
	;; v: pointer to array of 3 int16's (r25:r24)
sumsq3_16:
	ldi r23,3
	movw r30,r24
	clr r20
	clr r24			; result
	clr r25
0: 	ld r20,Z+
	ld r21,Z+
	;;
	muls r21,r21		; v.hi*v.hi => r1:r0
	add r24,r0
	adc r25,r1
	mulsu r21,r20		; v.hi*v.lo => r1:r0
	sbc r25,r20
	add r24,r1
	adc r25,r20
	mulsu r21,r20		; v.hi*v.lo => r1:r0
	sbc r25,r20
	add r24,r1
	adc r25,r20
	;;
	dec r23
	brne 0b
	;;
	clr r1			; reset R1 to zero
	ret

I'm probably being unhelpful  at this stage of the design; but that requirement looks like something the accelerometer should be able to handle autonomously. I.e. you program a set of threshold registers and an averaging filter and the chip asserts an IRQ line if the acceleration threshold is exceeded.

BTW: I'm starting to notice this behaviour in a few commercial products now; for instance Bluetooth headphones that "wake up" when you lift them up off the desk.

Does the sensor you've chosen support this mode of operation ?

You probably already know this, but keep the division to factors of 2 (2, 4, 8, 16, 32, 64, etc.) so it only has to slide bits right instead of perform actual division.

Maybe accruing values in a 24 bit or 32 bit won't be so bad if you do nothing else on that 24 bit or 32 bit variable, and the divide by 2 it back into a 16 bit one.

My experience with 32 bit variables, and especially manipulating them is that it doesn't take much to produce 10-20 instructions for even operations you think are no big deal.  Best thing to do is to dig through your lss file and look at your instructions and what the compiler emits for them.

I always set the debugging to default -g2 even for release because it doesn't change the contents of the hex file or binary produced, but it does give me an lss with source instructions to review.