SigmaDSP Like Devices

I never did see an answer to the question of using SigmaDSP like devices 
for tasks that require branching.  An old thread was recently 
resurrected on the topic and I still don't see an answer.  Does anyone 
know how to program the SigmaDSP devices in assembly language and if 
these parts have anything like a branch instruction?

What are the applications where these chips get used?

-- 

Rick

On Thursday, April 14, 2016 at 3:43:26 PM UTC-4, rickman wrote:
> I never did see an answer to the question of using SigmaDSP like devices 
> for tasks that require branching.  An old thread was recently 
> resurrected on the topic and I still don't see an answer.  Does anyone 
> know how to program the SigmaDSP devices in assembly language and if 
> these parts have anything like a branch instruction?
> 
> What are the applications where these chips get used?

i believe the SigmaDSP was designed by Bob Adams, whom you will see in these parts occasionally.

if i remember correctly, at the top of the sampling interrupt the instruction pointer (or whatever it is called) is reset to the top of the list of instructions.  i thought that the list was like 256 or 512 instructions long.  each instruction is a single-cycle instruction. each MAC is a separate instruction.  no do loops.

i believe that there are at least a couple of different machine pointers.  at the top of the sampling interrupt one pointer is reset to the top of a list of parameters that would be where the coefficients would be.  another pointer is advanced (or maybe decremented) by one relative to its location in the previous sample period and the space that this pointer points to is circular, probably a power of 2 in length.  i think that the instruction opcode, coefficient, and stored sample can all be accessed simultaneously in one instruction cycle as you would expect in a Harvard architecture.

now i can understand how this can do practically anything that is exactly the same instructions for each and every sample.  i can see how to implement various filters, IIR or FIR, and maybe even a reverberator.  another Bob (Chidlaw) does all sorts of guitar effects with this family of DSP.  but i dunno how i would write an efficient pitch-detector or deglitched pitch-shifter with such a restriction.

i thought Bob told me once at an AES that there was a new Sigma that might have had some kinda branch or conditional branch, but the memory is fuzzy.  i would welcome Bob to straighten me out straight away.  i could be totally fucked up in my recollection.

r b-j

On 4/15/2016 8:03 PM, robert bristow-johnson wrote:
> On Thursday, April 14, 2016 at 3:43:26 PM UTC-4, rickman wrote:
>> I never did see an answer to the question of using SigmaDSP like
>> devices for tasks that require branching.  An old thread was
>> recently resurrected on the topic and I still don't see an answer.
>> Does anyone know how to program the SigmaDSP devices in assembly
>> language and if these parts have anything like a branch
>> instruction?
>>
>> What are the applications where these chips get used?
>
> i believe the SigmaDSP was designed by Bob Adams, whom you will see
> in these parts occasionally.
>
> if i remember correctly, at the top of the sampling interrupt the
> instruction pointer (or whatever it is called) is reset to the top of
> the list of instructions.  i thought that the list was like 256 or
> 512 instructions long.  each instruction is a single-cycle
> instruction. each MAC is a separate instruction.  no do loops.
>
> i believe that there are at least a couple of different machine
> pointers.  at the top of the sampling interrupt one pointer is reset
> to the top of a list of parameters that would be where the
> coefficients would be.  another pointer is advanced (or maybe
> decremented) by one relative to its location in the previous sample
> period and the space that this pointer points to is circular,
> probably a power of 2 in length.  i think that the instruction
> opcode, coefficient, and stored sample can all be accessed
> simultaneously in one instruction cycle as you would expect in a
> Harvard architecture.
>
> now i can understand how this can do practically anything that is
> exactly the same instructions for each and every sample.  i can see
> how to implement various filters, IIR or FIR, and maybe even a
> reverberator.  another Bob (Chidlaw) does all sorts of guitar effects
> with this family of DSP.  but i dunno how i would write an efficient
> pitch-detector or deglitched pitch-shifter with such a restriction.
>
> i thought Bob told me once at an AES that there was a new Sigma that
> might have had some kinda branch or conditional branch, but the
> memory is fuzzy.  i would welcome Bob to straighten me out straight
> away.  i could be totally fucked up in my recollection.

I guess the simplicity of no branches makes sense. In fact, I see there 
being no real need to reset the instruction pointer since there are the 
same number of instruction words in memory as instruction times per 
sample, just fill the memory with NOPs after your code and Bob's your 
uncle.  In fact, the ADC/DAC can be triggered by the instruction pointer 
rather than the other way around, lol.

Yes, this makes the chip design very simple.  I think I read that recent 
versions run at 300 MHz or similar.  Not bad I guess.  I like it because 
it is a DSP inside a stereo CODEC.  I have a good use for that, but not 
if it can only do fairly simple algorithms.   Most DSPs come in too 
large a package.  I don't need I/Os.  I need it small and to look like a 
stereo CODEC for the most part.  Currently I'm using a 20 pin TSSOP 
CODEC.  Unless I change something else that is the space I have.

I see that problem with a number of devices, DSP, MCU, FPGA...   If you 
want more than some minimum amount of processing capability, you have to 
get a large package or at least go with some microscopic pitch like 0.4 
mm BGA types.  I suppose a 32 pin QFN might do the job... hmmm... But 
high resolution stereo CODECs don't typically get integrated with MCUs.

-- 

Rick

There are 3 generations of sigmaDSP parts.

The 1st generation did not have any branching but does have "skip-on-condition" capability. It is integrated with a 4-channel codec and is popular in musical-effects boxes. It is mated to a graphical drag-and-drop code generation tool called "sigmaStudio". 

The 2nd generation is a modification of the first but has conditional branching, do-loops, DAGs with support for bit-reversed modes, etc. However most of this extra capability is best unleashed by an experienced assembly-code person. It is also available in Codec form (2 channels).


The 3rd generation is completely different and is a 300MHz quad-MAC machine with complete flexibility in the addressing modes. It is not integrated with a Codec, and is programmed via sigmaStudio. The assembly code for this machine is very "algebraic". It has benchmarks for most audio tasks that are very impressive, and has a fair amount of on-chip memory.

Bob


On Friday, April 15, 2016 at 8:25:46 PM UTC-4, rickman wrote:
> On 4/15/2016 8:03 PM, robert bristow-johnson wrote:
> > On Thursday, April 14, 2016 at 3:43:26 PM UTC-4, rickman wrote:
> >> I never did see an answer to the question of using SigmaDSP like
> >> devices for tasks that require branching.  An old thread was
> >> recently resurrected on the topic and I still don't see an answer.
> >> Does anyone know how to program the SigmaDSP devices in assembly
> >> language and if these parts have anything like a branch
> >> instruction?
> >>
> >> What are the applications where these chips get used?
> >
> > i believe the SigmaDSP was designed by Bob Adams, whom you will see
> > in these parts occasionally.
> >
> > if i remember correctly, at the top of the sampling interrupt the
> > instruction pointer (or whatever it is called) is reset to the top of
> > the list of instructions.  i thought that the list was like 256 or
> > 512 instructions long.  each instruction is a single-cycle
> > instruction. each MAC is a separate instruction.  no do loops.
> >
> > i believe that there are at least a couple of different machine
> > pointers.  at the top of the sampling interrupt one pointer is reset
> > to the top of a list of parameters that would be where the
> > coefficients would be.  another pointer is advanced (or maybe
> > decremented) by one relative to its location in the previous sample
> > period and the space that this pointer points to is circular,
> > probably a power of 2 in length.  i think that the instruction
> > opcode, coefficient, and stored sample can all be accessed
> > simultaneously in one instruction cycle as you would expect in a
> > Harvard architecture.
> >
> > now i can understand how this can do practically anything that is
> > exactly the same instructions for each and every sample.  i can see
> > how to implement various filters, IIR or FIR, and maybe even a
> > reverberator.  another Bob (Chidlaw) does all sorts of guitar effects
> > with this family of DSP.  but i dunno how i would write an efficient
> > pitch-detector or deglitched pitch-shifter with such a restriction.
> >
> > i thought Bob told me once at an AES that there was a new Sigma that
> > might have had some kinda branch or conditional branch, but the
> > memory is fuzzy.  i would welcome Bob to straighten me out straight
> > away.  i could be totally fucked up in my recollection.
> 
> I guess the simplicity of no branches makes sense. In fact, I see there 
> being no real need to reset the instruction pointer since there are the 
> same number of instruction words in memory as instruction times per 
> sample, just fill the memory with NOPs after your code and Bob's your 
> uncle.  In fact, the ADC/DAC can be triggered by the instruction pointer 
> rather than the other way around, lol.
> 
> Yes, this makes the chip design very simple.  I think I read that recent 
> versions run at 300 MHz or similar.  Not bad I guess.  I like it because 
> it is a DSP inside a stereo CODEC.  I have a good use for that, but not 
> if it can only do fairly simple algorithms.   Most DSPs come in too 
> large a package.  I don't need I/Os.  I need it small and to look like a 
> stereo CODEC for the most part.  Currently I'm using a 20 pin TSSOP 
> CODEC.  Unless I change something else that is the space I have.
> 
> I see that problem with a number of devices, DSP, MCU, FPGA...   If you 
> want more than some minimum amount of processing capability, you have to 
> get a large package or at least go with some microscopic pitch like 0.4 
> mm BGA types.  I suppose a 32 pin QFN might do the job... hmmm... But 
> high resolution stereo CODECs don't typically get integrated with MCUs.
> 
> -- 
> 
> Rick

On Saturday, April 16, 2016 at 6:35:15 PM UTC-4, radam...@gmail.com wrote:
> There are 3 generations of sigmaDSP parts.
> 
> The 1st generation did not have any branching but does have "skip-on-condition" capability. It is integrated with a 4-channel codec and is popular in musical-effects boxes. It is mated to a graphical drag-and-drop code generation tool called "sigmaStudio". 
> 
> The 2nd generation is a modification of the first but has conditional branching, do-loops, DAGs with support for bit-reversed modes, etc. However most of this extra capability is best unleashed by an experienced assembly-code person. It is also available in Codec form (2 channels).
> 
> The 3rd generation is completely different and is a 300MHz quad-MAC machine with complete flexibility in the addressing modes. It is not integrated with a Codec, and is programmed via sigmaStudio. The assembly code for this machine is very "algebraic". It has benchmarks for most audio tasks that are very impressive, and has a fair amount of on-chip memory.
> 

thanks for straightening me out, Bob.

what is "algebraic" assembly code?

is the SHArC asm code algebraic?

bestest,

r b-j

On 4/16/2016 6:35 PM, radams2000@gmail.com wrote:
> There are 3 generations of sigmaDSP parts.
>
> The 1st generation did not have any branching but does have
> "skip-on-condition" capability. It is integrated with a 4-channel
> codec and is popular in musical-effects boxes. It is mated to a
> graphical drag-and-drop code generation tool called "sigmaStudio".

Not sure which parts you are referring to.  The 1401A, 1701 and 1702 
have 2 channels of ADC and 4 channels of DAC.  By 4 channel codec do you 
mean 2 channels each of ADC and DAC?

ADI has a selection table which does not include the single most vital 
parameter, "not recommended for new designs" which applies to a number 
of products in that table.  I suspect many of the 1st generation parts 
are these.


> The 2nd generation is a modification of the first but has conditional
> branching, do-loops, DAGs with support for bit-reversed modes, etc.
> However most of this extra capability is best unleashed by an
> experienced assembly-code person. It is also available in Codec form
> (2 channels).

Not sure what an "experienced assembly-code person" is exactly. 
Obviously I would have no experience with the SigmaDSP assembly 
language.  Otherwise I have lots of assembly language experience 
including microcode and designing my own processors.

Any idea how to access the tools for assembly programming of the 
SigmaDSP?  Is that in the standard tools?  Exactly which parts does "2nd 
generation" include?  I'm 'guessing this would be the ADAU17xx parts? 
One thing I don't get is how these are very low power devices, but they 
include a pad on the bottom.  That pad gets in the way of routing.


> The 3rd generation is completely different and is a 300MHz quad-MAC
> machine with complete flexibility in the addressing modes. It is not
> integrated with a Codec, and is programmed via sigmaStudio. The
> assembly code for this machine is very "algebraic". It has benchmarks
> for most audio tasks that are very impressive, and has a fair amount
> of on-chip memory.

Yeah, sort of a "Super SigmaDSP".  They come in a "super" 72 pin package 
and have a "super" power consumption of a large fraction of a watt.  I 
guess these parts are for the same market as the others, but with a lot 
more processing power.  I think the market is defined by the tools being 
GUI based rather than code based.


> On Friday, April 15, 2016 at 8:25:46 PM UTC-4, rickman wrote:
>> On 4/15/2016 8:03 PM, robert bristow-johnson wrote:
>>> On Thursday, April 14, 2016 at 3:43:26 PM UTC-4, rickman wrote:
>>>> I never did see an answer to the question of using SigmaDSP
>>>> like devices for tasks that require branching.  An old thread
>>>> was recently resurrected on the topic and I still don't see an
>>>> answer. Does anyone know how to program the SigmaDSP devices in
>>>> assembly language and if these parts have anything like a
>>>> branch instruction?
>>>>
>>>> What are the applications where these chips get used?
>>>
>>> i believe the SigmaDSP was designed by Bob Adams, whom you will
>>> see in these parts occasionally.
>>>
>>> if i remember correctly, at the top of the sampling interrupt
>>> the instruction pointer (or whatever it is called) is reset to
>>> the top of the list of instructions.  i thought that the list was
>>> like 256 or 512 instructions long.  each instruction is a
>>> single-cycle instruction. each MAC is a separate instruction.  no
>>> do loops.
>>>
>>> i believe that there are at least a couple of different machine
>>> pointers.  at the top of the sampling interrupt one pointer is
>>> reset to the top of a list of parameters that would be where the
>>> coefficients would be.  another pointer is advanced (or maybe
>>> decremented) by one relative to its location in the previous
>>> sample period and the space that this pointer points to is
>>> circular, probably a power of 2 in length.  i think that the
>>> instruction opcode, coefficient, and stored sample can all be
>>> accessed simultaneously in one instruction cycle as you would
>>> expect in a Harvard architecture.
>>>
>>> now i can understand how this can do practically anything that
>>> is exactly the same instructions for each and every sample.  i
>>> can see how to implement various filters, IIR or FIR, and maybe
>>> even a reverberator.  another Bob (Chidlaw) does all sorts of
>>> guitar effects with this family of DSP.  but i dunno how i would
>>> write an efficient pitch-detector or deglitched pitch-shifter
>>> with such a restriction.
>>>
>>> i thought Bob told me once at an AES that there was a new Sigma
>>> that might have had some kinda branch or conditional branch, but
>>> the memory is fuzzy.  i would welcome Bob to straighten me out
>>> straight away.  i could be totally fucked up in my recollection.
>>
>> I guess the simplicity of no branches makes sense. In fact, I see
>> there being no real need to reset the instruction pointer since
>> there are the same number of instruction words in memory as
>> instruction times per sample, just fill the memory with NOPs after
>> your code and Bob's your uncle.  In fact, the ADC/DAC can be
>> triggered by the instruction pointer rather than the other way
>> around, lol.
>>
>> Yes, this makes the chip design very simple.  I think I read that
>> recent versions run at 300 MHz or similar.  Not bad I guess.  I
>> like it because it is a DSP inside a stereo CODEC.  I have a good
>> use for that, but not if it can only do fairly simple algorithms.
>> Most DSPs come in too large a package.  I don't need I/Os.  I need
>> it small and to look like a stereo CODEC for the most part.
>> Currently I'm using a 20 pin TSSOP CODEC.  Unless I change
>> something else that is the space I have.
>>
>> I see that problem with a number of devices, DSP, MCU, FPGA...   If
>> you want more than some minimum amount of processing capability,
>> you have to get a large package or at least go with some
>> microscopic pitch like 0.4 mm BGA types.  I suppose a 32 pin QFN
>> might do the job... hmmm... But high resolution stereo CODECs don't
>> typically get integrated with MCUs.
>>
>> --
>>
>> Rick


-- 

Rick

On 4/16/2016 6:35 PM, radams2000@gmail.com wrote:
> There are 3 generations of sigmaDSP parts.
>
> The 1st generation did not have any branching but does have "skip-on-condition" capability. It is integrated with a 4-channel codec and is popular in musical-effects boxes. It is mated to a graphical drag-and-drop code generation tool called "sigmaStudio".
>
> The 2nd generation is a modification of the first but has conditional branching, do-loops, DAGs with support for bit-reversed modes, etc. However most of this extra capability is best unleashed by an experienced assembly-code person. It is also available in Codec form (2 channels).

In reading a data sheet a bit more , I found the description of the data 
sample sync process.  The program ends with a jump-to-start command. 
The PC is set to the start of the program but execution waits for the 
audio sample to be ready.  So there is no need to fill the program 
memory with NOPs.  They don't say if there is any other use for this 
unused memory.

-- 

Rick

On Saturday, April 16, 2016 at 9:50:35 PM UTC-4, robert bristow-johnson wrote:
> On Saturday, April 16, 2016 at 6:35:15 PM UTC-4, radam...@gmail.com wrote:
> > There are 3 generations of sigmaDSP parts.
> > 
> > The 1st generation did not have any branching but does have "skip-on-condition" capability. It is integrated with a 4-channel codec and is popular in musical-effects boxes. It is mated to a graphical drag-and-drop code generation tool called "sigmaStudio". 
> > 
> > The 2nd generation is a modification of the first but has conditional branching, do-loops, DAGs with support for bit-reversed modes, etc. However most of this extra capability is best unleashed by an experienced assembly-code person. It is also available in Codec form (2 channels).
> > 
> > The 3rd generation is completely different and is a 300MHz quad-MAC machine with complete flexibility in the addressing modes. It is not integrated with a Codec, and is programmed via sigmaStudio. The assembly code for this machine is very "algebraic". It has benchmarks for most audio tasks that are very impressive, and has a fair amount of on-chip memory.
> > 
> 
> thanks for straightening me out, Bob.
> 
> what is "algebraic" assembly code?
> 
> is the SHArC asm code algebraic?
> 
> bestest,
> 
> r b-j

Robert


Yes the Sharc is algebraic, it just means when you look at a line of assembly, a high-school math student could understand it. It also implies an orthogonal instruction set.

On Sunday, April 17, 2016 at 12:45:34 AM UTC-4, rickman wrote:
> On 4/16/2016 6:35 PM, radams2000@gmail.com wrote:
> > There are 3 generations of sigmaDSP parts.
> >
> > The 1st generation did not have any branching but does have
> > "skip-on-condition" capability. It is integrated with a 4-channel
> > codec and is popular in musical-effects boxes. It is mated to a
> > graphical drag-and-drop code generation tool called "sigmaStudio".
> 
> Not sure which parts you are referring to.  The 1401A, 1701 and 1702 
> have 2 channels of ADC and 4 channels of DAC.  By 4 channel codec do you 
> mean 2 channels each of ADC and DAC?
> 
> ADI has a selection table which does not include the single most vital 
> parameter, "not recommended for new designs" which applies to a number 
> of products in that table.  I suspect many of the 1st generation parts 
> are these.
> 
> 
> > The 2nd generation is a modification of the first but has conditional
> > branching, do-loops, DAGs with support for bit-reversed modes, etc.
> > However most of this extra capability is best unleashed by an
> > experienced assembly-code person. It is also available in Codec form
> > (2 channels).
> 
> Not sure what an "experienced assembly-code person" is exactly. 
> Obviously I would have no experience with the SigmaDSP assembly 
> language.  Otherwise I have lots of assembly language experience 
> including microcode and designing my own processors.
> 
> Any idea how to access the tools for assembly programming of the 
> SigmaDSP?  Is that in the standard tools?  Exactly which parts does "2nd 
> generation" include?  I'm 'guessing this would be the ADAU17xx parts? 
> One thing I don't get is how these are very low power devices, but they 
> include a pad on the bottom.  That pad gets in the way of routing.
> 
> 
> > The 3rd generation is completely different and is a 300MHz quad-MAC
> > machine with complete flexibility in the addressing modes. It is not
> > integrated with a Codec, and is programmed via sigmaStudio. The
> > assembly code for this machine is very "algebraic". It has benchmarks
> > for most audio tasks that are very impressive, and has a fair amount
> > of on-chip memory.
> 
> Yeah, sort of a "Super SigmaDSP".  They come in a "super" 72 pin package 
> and have a "super" power consumption of a large fraction of a watt.  I 
> guess these parts are for the same market as the others, but with a lot 
> more processing power.  I think the market is defined by the tools being 
> GUI based rather than code based.
> 
> 
> > On Friday, April 15, 2016 at 8:25:46 PM UTC-4, rickman wrote:
> >> On 4/15/2016 8:03 PM, robert bristow-johnson wrote:
> >>> On Thursday, April 14, 2016 at 3:43:26 PM UTC-4, rickman wrote:
> >>>> I never did see an answer to the question of using SigmaDSP
> >>>> like devices for tasks that require branching.  An old thread
> >>>> was recently resurrected on the topic and I still don't see an
> >>>> answer. Does anyone know how to program the SigmaDSP devices in
> >>>> assembly language and if these parts have anything like a
> >>>> branch instruction?
> >>>>
> >>>> What are the applications where these chips get used?
> >>>
> >>> i believe the SigmaDSP was designed by Bob Adams, whom you will
> >>> see in these parts occasionally.
> >>>
> >>> if i remember correctly, at the top of the sampling interrupt
> >>> the instruction pointer (or whatever it is called) is reset to
> >>> the top of the list of instructions.  i thought that the list was
> >>> like 256 or 512 instructions long.  each instruction is a
> >>> single-cycle instruction. each MAC is a separate instruction.  no
> >>> do loops.
> >>>
> >>> i believe that there are at least a couple of different machine
> >>> pointers.  at the top of the sampling interrupt one pointer is
> >>> reset to the top of a list of parameters that would be where the
> >>> coefficients would be.  another pointer is advanced (or maybe
> >>> decremented) by one relative to its location in the previous
> >>> sample period and the space that this pointer points to is
> >>> circular, probably a power of 2 in length.  i think that the
> >>> instruction opcode, coefficient, and stored sample can all be
> >>> accessed simultaneously in one instruction cycle as you would
> >>> expect in a Harvard architecture.
> >>>
> >>> now i can understand how this can do practically anything that
> >>> is exactly the same instructions for each and every sample.  i
> >>> can see how to implement various filters, IIR or FIR, and maybe
> >>> even a reverberator.  another Bob (Chidlaw) does all sorts of
> >>> guitar effects with this family of DSP.  but i dunno how i would
> >>> write an efficient pitch-detector or deglitched pitch-shifter
> >>> with such a restriction.
> >>>
> >>> i thought Bob told me once at an AES that there was a new Sigma
> >>> that might have had some kinda branch or conditional branch, but
> >>> the memory is fuzzy.  i would welcome Bob to straighten me out
> >>> straight away.  i could be totally fucked up in my recollection.
> >>
> >> I guess the simplicity of no branches makes sense. In fact, I see
> >> there being no real need to reset the instruction pointer since
> >> there are the same number of instruction words in memory as
> >> instruction times per sample, just fill the memory with NOPs after
> >> your code and Bob's your uncle.  In fact, the ADC/DAC can be
> >> triggered by the instruction pointer rather than the other way
> >> around, lol.
> >>
> >> Yes, this makes the chip design very simple.  I think I read that
> >> recent versions run at 300 MHz or similar.  Not bad I guess.  I
> >> like it because it is a DSP inside a stereo CODEC.  I have a good
> >> use for that, but not if it can only do fairly simple algorithms.
> >> Most DSPs come in too large a package.  I don't need I/Os.  I need
> >> it small and to look like a stereo CODEC for the most part.
> >> Currently I'm using a 20 pin TSSOP CODEC.  Unless I change
> >> something else that is the space I have.
> >>
> >> I see that problem with a number of devices, DSP, MCU, FPGA...   If
> >> you want more than some minimum amount of processing capability,
> >> you have to get a large package or at least go with some
> >> microscopic pitch like 0.4 mm BGA types.  I suppose a 32 pin QFN
> >> might do the job... hmmm... But high resolution stereo CODECs don't
> >> typically get integrated with MCUs.
> >>
> >> --
> >>
> >> Rick
> 
> 
> -- 
> 
> Rick

Rick


Yes the parts that start with "17" are first-gen. They have a 2-channel ADC/4-channel DAC as you mentioned.
The "17" parts are 2nd-generation. The codec version is 2ADC/2DAC.

The first two generations have an architecture that makes them very efficient for single-rate stream processing, IIR filtering and FIR filtering. But the assembly code it can look a bit "weird" to a programmer who is used to more standard approaches, and the more you venture outside stream processing, the more difficult it becomes. We have internal people who are good at this, but it's a bit hard to teach.

When you are introducing DSP chips that cut across many markets, you can afford to fund a large tools and support group that can hand-hold customers learning the instruction set. But when you introduce a highly "targeted" core, you can't. So we addressed this by using a graphical tool for code generation and real-time parameter control. Note that the auto-generated code is virtually 100% as dense as hand-coded assembly. Note also that these devices do not have a JTAG port, so debugging your code is different than normal. For these reasons we prefer to do the coding ourselves; if you have a very high-volume application, contact us and we'll see what we can do.

You're right that the 3rd generation is completely different. When defining "low-power", you need to normalize that definition to the amount of processing power available; so maybe "mw/MIP" is a better metric, and in that case the gen-3 parts look pretty good.

Bob

On Sunday, April 17, 2016 at 9:09:49 AM UTC-4, radam...@gmail.com wrote:
> On Saturday, April 16, 2016 at 9:50:35 PM UTC-4, robert bristow-johnson wrote:
> > 
> > thanks for straightening me out, Bob.
> > 
> > what is "algebraic" assembly code?
> > 
> > is the SHArC asm code algebraic?
> > 
> 
> 
> Yes the Sharc is algebraic, it just means when you look at a line of assembly, a high-school math student could understand it. It also implies an orthogonal instruction set.


well, i would hardly call the SHArC instruction set orthogonal.  some instructions you can have a "COMPUTE" field in parallel with it and others you cannot.  this is why the SHArC C runtime system has 3 modifier registers (m5, m6, m7) dedicated with  0, +1, and -1 in them because while

    r0 = dm(+1, i4);

is legal

    r1 = r2*r3,   r0 = (+1, i4);

is not.  but you *can* do

    r1 = r2*r3,   r0 = (m6, i4);

and count on m6 being loaded since initialization with 1.  but if you wanted to offset by a constant of 10, you can't do it with a COMPUTE class of instruction in parallel.

if you look at the SHArC "Multifunction" instructions, they are hardly orthogonal.  if you want to optimize your asm code, you must be very careful and deliberate with the choice of arithmetic registers you use for specific instructions, because not all combinations are allowable.  a few months ago i ran into this big time with a precision delay alg that i was optimizing (i eventually got it down to 20 instructions in the inner loop and it is doing 3rd-order Hermite interpolation) but i really had to play musical chairs in using exactly the correct register for each computation destination, because if i picked the wrong (or "less correct") register, it could not be used as an argument in a future, highly parallelized, instruction.

i just cannot agree with the notion that the SHArC instruction set is "orthogonal".  it just ain't.  perhaps the Sigma, is.  so Bob, i am not picking on you.  but the SHArC, while powerful, and while it has more and more and more and more and more features (that i will never use) larded onto to it, it is a truly ugly assembler syntax and twice in my life, 20 years ago and this past year, i had to learn all of the minute details, what is allowed - what is not, of this instruction set.  there are some things about it that i just cannot imagine what the architects were thinking of (or what chemicals they might have been on) when they carved them into stone (or silicon) forever. 

it doesn't seem to be a popular sentiment around some folks, but i think that this "algebraic" syntax has little advantage over a "regular" asm syntax.  i've never been impressed with it.  and i think it tries to hide other ugly things.  at least this is the case with the SHArC.

r b-j