16-bit vs. 32-bit

Hi,

in the documentation for the Infineon TriCore DSP
they say that both 32-bit and 16-bit instruction 
formats are supported by the processor. Furthermore
they say that the code size can be reduced by 30%-40%
when just 16-bit instructions are used. So far, every-
thing is ok. 
But then they say: "16-bi instructions are subset of
32-bit instructions & are automatically generated during
compilation". Does this mean that an assembler programmer
who wants to write efficient code in terms of code size
does not have to care about the choice of the instruction
formats because even if he uses a larger 32-bit instruction
the compiler will notice that and possibly replace that
32-bit instruction by a smaller equivalent 16-bit instruction?
So, if my assumption is right, it's up to the compiler(assembler)
to perform this replacement of equivalent instructions, right?

Regards,
Chris

I needed a slight clarification:

Is this processor superscalar or VLIW?

Partho



Christian Christmann wrote:
> Hi,
>
> in the documentation for the Infineon TriCore DSP
> they say that both 32-bit and 16-bit instruction
> formats are supported by the processor. Furthermore
> they say that the code size can be reduced by 30%-40%
> when just 16-bit instructions are used. So far, every-
> thing is ok.
> But then they say: "16-bi instructions are subset of
> 32-bit instructions & are automatically generated during
> compilation". Does this mean that an assembler programmer
> who wants to write efficient code in terms of code size
> does not have to care about the choice of the instruction
> formats because even if he uses a larger 32-bit instruction
> the compiler will notice that and possibly replace that
> 32-bit instruction by a smaller equivalent 16-bit instruction?
> So, if my assumption is right, it's up to the compiler(assembler)
> to perform this replacement of equivalent instructions, right?
> 
> Regards,
> Chris

I needed a slight clarification:

Is this processor superscalar or VLIW?

Partho



Christian Christmann wrote:
> Hi,
>
> in the documentation for the Infineon TriCore DSP
> they say that both 32-bit and 16-bit instruction
> formats are supported by the processor. Furthermore
> they say that the code size can be reduced by 30%-40%
> when just 16-bit instructions are used. So far, every-
> thing is ok.
> But then they say: "16-bi instructions are subset of
> 32-bit instructions & are automatically generated during
> compilation". Does this mean that an assembler programmer
> who wants to write efficient code in terms of code size
> does not have to care about the choice of the instruction
> formats because even if he uses a larger 32-bit instruction
> the compiler will notice that and possibly replace that
> 32-bit instruction by a smaller equivalent 16-bit instruction?
> So, if my assumption is right, it's up to the compiler(assembler)
> to perform this replacement of equivalent instructions, right?
> 
> Regards,
> Chris

Christian Christmann wrote:
> Hi,
>
> in the documentation for the Infineon TriCore DSP
> they say that both 32-bit and 16-bit instruction
> formats are supported by the processor. Furthermore
> they say that the code size can be reduced by 30%-40%
> when just 16-bit instructions are used. So far, every-
> thing is ok.
> But then they say: "16-bi instructions are subset of
> 32-bit instructions & are automatically generated during
> compilation". Does this mean that an assembler programmer
> who wants to write efficient code in terms of code size
> does not have to care about the choice of the instruction
> formats because even if he uses a larger 32-bit instruction
> the compiler will notice that and possibly replace that
> 32-bit instruction by a smaller equivalent 16-bit instruction?
> So, if my assumption is right, it's up to the compiler(assembler)
> to perform this replacement of equivalent instructions, right?
>

Dont know much about DSP but in RISC, like ARM, writing code in 16
bit(called thumb mode) is space efficient by 30-35% compare to 32 bit
code(called ARM mode) compilation but the performance degrades by 50%
or so because it internally converts the 16 bit code to 32 bit code and
works on it.

I think, similar philosphy must be used in your case, possibly in
inverse manner..but i didnt understand how come you want to use 32 bit
instruction set if it wont give the enhanced performance!

Of course it matters whether you are using 32 bit or 16 bit instruction
set..otherwise why should it even exist at first place.

Christian Christmann wrote:
> Hi,
> 
> in the documentation for the Infineon TriCore DSP
> they say that both 32-bit and 16-bit instruction 
> formats are supported by the processor. Furthermore
> they say that the code size can be reduced by 30%-40%
> when just 16-bit instructions are used. So far, every-
> thing is ok. 
> But then they say: "16-bi instructions are subset of
> 32-bit instructions & are automatically generated during
> compilation". Does this mean that an assembler programmer
> who wants to write efficient code in terms of code size
> does not have to care about the choice of the instruction
> formats because even if he uses a larger 32-bit instruction
> the compiler will notice that and possibly replace that
> 32-bit instruction by a smaller equivalent 16-bit instruction?
> So, if my assumption is right, it's up to the compiler(assembler)
> to perform this replacement of equivalent instructions, right?
> 
> Regards,
> Chris
> 
Assemblers and compilers are two different things.  Compilers take C, 
ADA, or some other high level language and convert it into assembly, 
which then gets assembled.  An assembler takes a set of mnemonics which 
have a 1:1 mapping to the instruction set and put them together, while 
taking care of the details of finding labels &c.

So no, I wouldn't expect an _assembler_ to do this: I would expect the 
assembly language programmer would have to know which instructions have 
16-bit equivalents.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

On Thu, 22 Jun 2006 02:27:53 -0700, Ben wrote:

> 
> I needed a slight clarification:
> 
> Is this processor superscalar or VLIW?

Superscalar

Arent superscalar RISCs supposed to have a fixed opcode size? How come
they have 16 and 32 bit formats, or are the 16 bit opcodes packages
into 32 bit opcodes with NOP padding? Correct me if I am wrong!!!

Partho

Christian Christmann wrote:
> On Thu, 22 Jun 2006 02:27:53 -0700, Ben wrote:
>
> >
> > I needed a slight clarification:
> > 
> > Is this processor superscalar or VLIW?
> 
> Superscalar

On Tue, 27 Jun 2006 00:10:01 -0700, Ben wrote:

> 
> Arent superscalar RISCs supposed to have a fixed opcode size? How come
> they have 16 and 32 bit formats, or are the 16 bit opcodes packages into
> 32 bit opcodes with NOP padding? Correct me if I am wrong!!!

Please see here
http://www.infineon.com/upload/Document/cmc_upload/documents/035/879/inf0010_v1_4Dec2003_1.pdf

Tim--

>Assemblers and compilers are two different things.  Compilers take C, 
>ADA, or some other high level language and convert it into assembly, 
>which then gets assembled.  An assembler takes a set of mnemonics which 
>have a 1:1 mapping to the instruction set and put them together, while 
>taking care of the details of finding labels &c.
>
>So no, I wouldn't expect an _assembler_ to do this: I would expect the 
>assembly language programmer would have to know which instructions have 
>16-bit equivalents.

Not true anymore. Its sort of done in the assembler+compressor module
atleast in TIs C64x+ processor.

If you look up TIs recent C64x+ architecture which has got similar code
compression design, you would realize that a module called compressor has
been added to the tool chain after the assembler.Though its a seperate
executable, it should be thought of as part of Assembler, according to TI
manuals. Here in this architecture design, the C programmer, as expected,
to be agnostic about 16/32 instruction set but code post assembler goes
through a phase called compressor, which converts those eligible 32bit
instructions into 16 bit variants before load time.

Flow:

C->Compiler->.asm>Assembler->.obj(32 bit)->Compressor->.obj(some portion
16 bit)


--Bhooshan


So, here no where can the programmer program in 16 bit directly.

bhooshaniyer wrote:
> Tim--
>
> >Assemblers and compilers are two different things.  Compilers take C,
> >ADA, or some other high level language and convert it into assembly,
> >which then gets assembled.  An assembler takes a set of mnemonics which
> >have a 1:1 mapping to the instruction set and put them together, while
> >taking care of the details of finding labels &c.
> >
> >So no, I wouldn't expect an _assembler_ to do this: I would expect the
> >assembly language programmer would have to know which instructions have
> >16-bit equivalents.
>
> Not true anymore. Its sort of done in the assembler+compressor module
> atleast in TIs C64x+ processor.
>
> If you look up TIs recent C64x+ architecture which has got similar code
> compression design, you would realize that a module called compressor has
> been added to the tool chain after the assembler.Though its a seperate
> executable, it should be thought of as part of Assembler, according to TI
> manuals. Here in this architecture design, the C programmer, as expected,
> to be agnostic about 16/32 instruction set but code post assembler goes
> through a phase called compressor, which converts those eligible 32bit
> instructions into 16 bit variants before load time.
>
> Flow:
>
> C->Compiler->.asm>Assembler->.obj(32 bit)->Compressor->.obj(some portion
> 16 bit)

Bhooshaniyer,

Is this true for "raw" assembly as well as linear assembly? I haven't
seen this "compression" mode for either in the v6.0.0 alpha
assembly language tools user's guide (SPRU186O).

--Randy