FPGA Central

Hi,

I've some newbie questions concerning an assembler code
generated for the Infoneon TriCore DSP.

First of all the c-code:

int main()
{
long long a = 2147483648ll;
return a;
}

and the corresponding assembler code generated by the
tricore-gcc:

[...]
..LC0:
.word -2147483648
.word 0
.section .text
.align 1
.global main
.type main,@function
main:
# arg_overflow_area = 0, pretend = 0
# frame_size = 8, outgoing_args_size = 0
# f_size = 8, frame_pointer_needed = 0
# pool_size = 8
sub.a %SP, 8 # allocate space for locals
call __main
movh.a %a15, HI:.LC0
lea %a15, [%a15] LO:.LC0
ld.d %e0, [%a15] 0
st.d [%a10] 0, %e0
ld.w %d15, [%a10] 0
mov %d2, %d15
j .L1
..L1:
ret

Before I start with my questions, here two definitions from the tricore
assembler manual which could be helpful:

"Operand Prefixes

The following operand prefixes are recognized by the TriCore version of as:
hi:symbol_or_expression
Returns the high part (16 bits) of symbol_or_expression by adding 0x8000 to the
32-bit value of symbol_or_expression and then right-shifting the result 16
bits. If the value of symbol_or_expression isn't known at assemble time, a
special relocation entry is generated for the linker to resolve. Example:
movh.a %a15,hi:foo.

lo:symbol_or_expression
Returns the lower 16 bits of symbol_or_expression. If the 32-bit value of
symbol_or_expression isn't known at assemble time, a special relocation
entry is generated for the linker to resolve. Example: lea
%a15,[%a15]lo:foo. "


My questions:
1) HI:.LC0: How can this operand prefix use .LC0 for any calculations like
adding 0x8000 ... Isn't it just a label name represented by a string? Or
is it kind of alias which is representing a particular memory address?

2) MOVH.A is an instruction to move the value (here HI:.LC0) to the
most- significant half-word of the given address register (here: %a15)
and set the least-significant 16-bits to zero. Similar to 1), how can you
move a label to some bits? I understand that you can move a constant
value or the value of a data register which is representing a value in
binary to an address register but I cannot imagine how to move a label.

3) A general question: What is .LC0 representing? A specific value or
is it a memory address?

4) Just to make sure: LEA is using the indirect addressing mode to read
the memory address stored in memory at address M[%a15], add the
offset (LO:.LC0, why LO this time?) and put the result (effective address)
in the address register %a15.


Thank you for answering my basic questions.

Chris

Christian Christmann wrote:
> Hi,
>
> I've some newbie questions concerning an assembler code
> generated for the Infoneon TriCore DSP.
>
> First of all the c-code:
>
> int main()
> {
> long long a = 2147483648ll;
> return a;
> }
>
> and the corresponding assembler code generated by the
> tricore-gcc:
>
> [...]
> .LC0:
> .word -2147483648
> .word 0
> .section .text
> .align 1
> .global main
> .type main,@function
> main:
> # arg_overflow_area = 0, pretend = 0
> # frame_size = 8, outgoing_args_size = 0
> # f_size = 8, frame_pointer_needed = 0
> # pool_size = 8
> sub.a %SP, 8 # allocate space for locals
> call __main
> movh.a %a15, HI:.LC0
> lea %a15, [%a15] LO:.LC0
> ld.d %e0, [%a15] 0
> st.d [%a10] 0, %e0
> ld.w %d15, [%a10] 0
> mov %d2, %d15
> j .L1
> .L1:
> ret
>
> Before I start with my questions, here two definitions from the tricore
> assembler manual which could be helpful:
>
> "Operand Prefixes
>
> The following operand prefixes are recognized by the TriCore version of as:
> hi:symbol_or_expression
> Returns the high part (16 bits) of symbol_or_expression by adding 0x8000 to the
> 32-bit value of symbol_or_expression and then right-shifting the result 16
> bits. If the value of symbol_or_expression isn't known at assemble time, a
> special relocation entry is generated for the linker to resolve. Example:
> movh.a %a15,hi:foo.
>
> lo:symbol_or_expression
> Returns the lower 16 bits of symbol_or_expression. If the 32-bit value of
> symbol_or_expression isn't known at assemble time, a special relocation
> entry is generated for the linker to resolve. Example: lea
> %a15,[%a15]lo:foo. "
>
>
> My questions:
> 1) HI:.LC0: How can this operand prefix use .LC0 for any calculations like
> adding 0x8000 ... Isn't it just a label name represented by a string? Or
> is it kind of alias which is representing a particular memory address?

The construct with user-defined token at the far left followed by a
colon is a pretty universal way of generating a label for a memory
address. The following construct with spaces and .word xxx put xxx into
memory at the current memory location (which happens to be pointed to by
..LCO in this instance).
>
> 2) MOVH.A is an instruction to move the value (here HI:.LC0) to the
> most- significant half-word of the given address register (here: %a15)
> and set the least-significant 16-bits to zero. Similar to 1), how can you
> move a label to some bits? I understand that you can move a constant
> value or the value of a data register which is representing a value in
> binary to an address register but I cannot imagine how to move a label.

The label has a numerical value -- in this case the memory location's
address. That's what gets loaded.
>
> 3) A general question: What is .LC0 representing? A specific value or
> is it a memory address?

It is a memory address (which is a specific value once things are linked
and loaded).
>
> 4) Just to make sure: LEA is using the indirect addressing mode to read
> the memory address stored in memory at address M[%a15], add the
> offset (LO:.LC0, why LO this time?) and put the result (effective address)
> in the address register %a15.

Check your manual, I believe that LEA is loading the lower 16 bits of
..LCO into the lower 16 bits of a15. I'm not sure what the [%a15] syntax
is about - it's your job to figure that out.
>
>
> Thank you for answering my basic questions.
>
> Chris
>
>
>
Just a general note:

Assemblers are always weird, each one is always different from the last,
they always do pretty much the same things with extensions for your
compilers peculiarities, and they always do it in a way you really
didn't expect. The _almost_ always do anything you want, but sometimes
they don't have as good of macro facilities as you'd like and sometimes
they don't address your processor's peculiarities as well as you'd like
or in the way you'd like.

Once you learn how to program in assembly in one processor you'll have
learned 90% of what you need to know; you'll get up to 98% or so on the
next assembler, then you'll just start learning all the different ways
that assembler authors can dream up to win the annual "worlds weirdest
assembler" contest.

--

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