Compacting 4x 24 bit values into 3x 32 bits

I've done this already (not for byte-stuffing, but for a demonstration on the NXP LPC1768).

The attachment shows how I use the DMA to blink a LED. Not impressive in itself, but what's special is that I use a table in order to change speed.

You could use tables in the same way to swap those bytes around (and even place them in a nice order).

The DMA is quite fast, and it can work side-by-side with the CPU, but make sure that you wait until the DMA is finished, before a new FIR buffer is written.

What you could do is that you send your FIR output to two different buffers, then while the FIR is writing to the current buffer, the DMA is fixing up the other buffer, which was written last time. You probably already know this; it's called double-buffering and is used both in preparing Audio and Video for output - but can also be applied here.

About the stack pointer, yes, you have the option to use either the Main Stack Pointer (default) or the Process Stack Pointer. You need to use MSR to set up the PSP.

> "The one register too short is too bad. I don't understand what you mean by squeeze register usage. You mean I could always load the last value after the first pack when I unroll by 3?"

Sorry, I've been a bit unclear on that. What I mean is that you load for instance 10 registers, then process the first 8 registers, process the 9th register and then load 9 more registers, while keeping the 10th register. This might save you 1/3 clock cycle per block. Sometimes you can save some, sometimes it's just the same, so you'll need to create a good overview before you start.

You have another alternative, though. The mask I was speaking about, can be loaded right after processing the very first register, as  you would have a register free.

Unfortunately, most likely loading the mask will take 2 clock cycles, so it will only pay if you can do 3 chunks at a time.

> "I must say your code is very efficient, at the point that I should start looking at improvements at other parts of my code. I don't think I can output the samples left aligned, since that would mean I would need to increase my multiplication, causing overflows. If I could, how would that help things?"

Thank you; I think your original code is quite good as well; much better than what most implementations would look like.

-My packing will only work correctly, if you are sure that your code delivers the upper 8 bits as zero always. If you know it does this, no problem, there's no need to change your FIR code.

The instruction...

                    orrs                r3,r3,r5,lsr#8              /* [1] r3 = $BBBBDDDD */

...requires that the top 8 bits of r5 is zero, because it's mixing using bitwise OR. This is the only place I could not find a safer way to mix the two registers.

So if r5 holds $xxDDDDdd, then the 'xx' would overwrite the top/mid byte of r3, which means the result would be $BBxxDDDD - we do not want that to happen.

I imagine this would only be happening if your FIR results are signed integers, so that they would sometimes store $FF in the top byte and sometimes $00.

But as I do not know the FIR code, I can't do any checking. You've probably already verified how it behaves regarding this.

But if not, you could left-shift one of your factors by 8, then the overflow would not matter at all. Those 8 bits would just be shifted out (discarded). Your byte-stuffing would be slightly different, but I think it could still pack using 4 instructions.

Pre-shifting them left would mean that you would be sure that the low 8 bits are zero. That means for packing, you can use only 4 instructions (thus 4 clock cycles) for packing instead of 5 instructions (and 5 clock cycles).

I find questions like this one particularly interesting, puzzling things around so they fit exactly is probably the most fun way of optimizing.

I've done this already (not for byte-stuffing, but for a demonstration on the NXP LPC1768).

The attachment shows how I use the DMA to blink a LED. Not impressive in itself, but what's special is that I use a table in order to change speed.

You could use tables in the same way to swap those bytes around (and even place them in a nice order).

The DMA is quite fast, and it can work side-by-side with the CPU, but make sure that you wait until the DMA is finished, before a new FIR buffer is written.

What you could do is that you send your FIR output to two different buffers, then while the FIR is writing to the current buffer, the DMA is fixing up the other buffer, which was written last time. You probably already know this; it's called double-buffering and is used both in preparing Audio and Video for output - but can also be applied here.

About the stack pointer, yes, you have the option to use either the Main Stack Pointer (default) or the Process Stack Pointer. You need to use MSR to set up the PSP.

> "The one register too short is too bad. I don't understand what you mean by squeeze register usage. You mean I could always load the last value after the first pack when I unroll by 3?"

Sorry, I've been a bit unclear on that. What I mean is that you load for instance 10 registers, then process the first 8 registers, process the 9th register and then load 9 more registers, while keeping the 10th register. This might save you 1/3 clock cycle per block. Sometimes you can save some, sometimes it's just the same, so you'll need to create a good overview before you start.

You have another alternative, though. The mask I was speaking about, can be loaded right after processing the very first register, as  you would have a register free.

Unfortunately, most likely loading the mask will take 2 clock cycles, so it will only pay if you can do 3 chunks at a time.

> "I must say your code is very efficient, at the point that I should start looking at improvements at other parts of my code. I don't think I can output the samples left aligned, since that would mean I would need to increase my multiplication, causing overflows. If I could, how would that help things?"

Thank you; I think your original code is quite good as well; much better than what most implementations would look like.

-My packing will only work correctly, if you are sure that your code delivers the upper 8 bits as zero always. If you know it does this, no problem, there's no need to change your FIR code.

The instruction...

                    orrs                r3,r3,r5,lsr#8              /* [1] r3 = $BBBBDDDD */

...requires that the top 8 bits of r5 is zero, because it's mixing using bitwise OR. This is the only place I could not find a safer way to mix the two registers.

So if r5 holds $xxDDDDdd, then the 'xx' would overwrite the top/mid byte of r3, which means the result would be $BBxxDDDD - we do not want that to happen.

I imagine this would only be happening if your FIR results are signed integers, so that they would sometimes store $FF in the top byte and sometimes $00.

But as I do not know the FIR code, I can't do any checking. You've probably already verified how it behaves regarding this.

But if not, you could left-shift one of your factors by 8, then the overflow would not matter at all. Those 8 bits would just be shifted out (discarded). Your byte-stuffing would be slightly different, but I think it could still pack using 4 instructions.

Pre-shifting them left would mean that you would be sure that the low 8 bits are zero. That means for packing, you can use only 4 instructions (thus 4 clock cycles) for packing instead of 5 instructions (and 5 clock cycles).

I find questions like this one particularly interesting, puzzling things around so they fit exactly is probably the most fun way of optimizing.