Texts on generic DSP architecture designs?

glen herrmannsfeldt wrote:

> Special purpose registers comlicated things a little bit, but
> not so much that it can't be done.

Assume that all registers are special purpose. Even if they are
all general purpose there use becomes colored with
conventions. Argument passing is the worst offender.


w..

Tim Wescott wrote:

> I suppose if one took your sum and followed it by a shift, and a
> saturate, and a cast back to 16 bits, one could hope that the compiler
> would recognize it and optimize it.  There would be subtleties in getting
> the C to exactly match the behavior of the machine code -- I think it'd
> take the same level of knowledge and be less time-consuming to just write
> the assembly for the thing than to try to cook up some C and successfully
> surround it with enough comments that future developers would understand
> that it is read-only.

Inline asm has its own restrictions as well. I have seen many well
written examples but there is a lot of inline asm that does not account for
overall application optimization and the inline code is efficient but
getting arguments and results in and out kill the savings.

An "asm instruction  in C" gives the compiler a chance to organize data flow
around the restrictions of a code fragment. Inline asm tends to break
flow mapping in most compilers.

w..

Walter Banks <walter@bytecraft.com> wrote:

(snip, I wrote)
>> Special purpose registers comlicated things a little bit, but
>> not so much that it can't be done.

> Assume that all registers are special purpose. Even if they are
> all general purpose there use becomes colored with
> conventions. Argument passing is the worst offender.

If all are special purpose, it might simplify things, except
that it will make the tables bigger. 

The LCC book has it pretty well described, or at least I thought
so when I was reading it.

One that complicated many is the x87 register stack. It seems that
the usual solution is to treat it as registers instead of a stack.

-- glen

On Wed, 07 Mar 2012 08:06:52 -0500, Walter Banks wrote:

> Tim Wescott wrote:
> 
>> I suppose if one took your sum and followed it by a shift, and a
>> saturate, and a cast back to 16 bits, one could hope that the compiler
>> would recognize it and optimize it.  There would be subtleties in
>> getting the C to exactly match the behavior of the machine code -- I
>> think it'd take the same level of knowledge and be less time-consuming
>> to just write the assembly for the thing than to try to cook up some C
>> and successfully surround it with enough comments that future
>> developers would understand that it is read-only.
> 
> Inline asm has its own restrictions as well. I have seen many well
> written examples but there is a lot of inline asm that does not account
> for overall application optimization and the inline code is efficient
> but getting arguments and results in and out kill the savings.

True, it should only be used with care and consideration -- I generally 
like to leave such things up to the compiler if it's smart enough.

But nothing says "here be dragons" to the would-be master code jockey 
like "asm(".

> An "asm instruction  in C" gives the compiler a chance to organize data
> flow around the restrictions of a code fragment. Inline asm tends to
> break flow mapping in most compilers.

True again.  But the last time I did DSP programming in anger, the 
compiler was unable (or at least seemed unable) to come up with a 
hardware loop around a MAC when I tried to make it so -- I diddled with 
it for a day in C, then wrote my assembly code in a couple days more.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com