Encoding of immediates different to label addresses

Encoding of immediates different to label addresses

[Julius Baxter]

Hi,

I'm working on fixing up the OpenRISC 1000 CGEN port and have come
across something I find I can't quite do with CGEN.

For the jump and branch instructions, if we use immediate value number
specified in the assembly, we need that encoded into the instruction
without any shifting occurring to it.

Eg. "l.bf 1" should become 0x10000001, "l.bf 4" should become 0x10000004 etc.

These target addresses are shifted-left by two during decoding, and so
"l.bf 1" is actually a branch of 4 bytes.

If we use a label for an address, though, I'm seeing that we're
getting the offset in bytes during encoding, which then needs to be
shifted right by two before being put in the instruction.

But it seems we can have the shifting on both numerical immediates and
labels, or neither. (Pardon my incorrect use of terminology, I have a
feeling I'm not quite calling everything its right name!)

Upon inspecttion, it looks like the binutils port we have been using
for the past few years (not CGEN-based) has a right-shift of 2 in the
md_apply_fix() function in binutils/gas/config/tc-or32.c (
http://sourceware.org/git/?p=binutils.git;a=blob;f=gas/config/tc-or32.c;h=7234fb837e006f979c255f62206e39a9822046d2;hb=HEAD#l603
) when the instruction had the actual value of the label inserted into
it.

Is there any way to handle this using the CGEN description?

The current instruction field definition being used is:

(df f-disp26     "disp26"              (PCREL-ADDR) 25 26 INT
    ((value pc) (sra WI (sub WI value pc) (const 2)))
    ((value pc) (add WI (sll WI value (const 2)) pc)))

This does the shifting on encode and the target label addresses are
right but the numerical immediates are wrong, but if I remove the sra
on the encode, the numerical immediates are right but the target label
addresses are wrong.

I've had a bit of a poke around and seen the function
gas_cgen_md_apply_fix() is used as a generic md_apply_fix() function,
but can't quite see where I might be able to hook in things for
particular encoding cases.

If anyone could point out how I could handle this case it'd be appreciated.

Thanks,

Julius

Re: Encoding of immediates different to label addresses

[Andrew Burgess]

On 02/01/2012 09:44, Julius Baxter wrote:
> I'm working on fixing up the OpenRISC 1000 CGEN port and have come
> across something I find I can't quite do with CGEN.
>
> For the jump and branch instructions, if we use immediate value number
> specified in the assembly, we need that encoded into the instruction
> without any shifting occurring to it.
>
> Eg. "l.bf 1" should become 0x10000001, "l.bf 4" should become 0x10000004 etc.
>
> These target addresses are shifted-left by two during decoding, and so
> "l.bf 1" is actually a branch of 4 bytes.
>
> If we use a label for an address, though, I'm seeing that we're
> getting the offset in bytes during encoding, which then needs to be
> shifted right by two before being put in the instruction.
>
> But it seems we can have the shifting on both numerical immediates and
> labels, or neither. (Pardon my incorrect use of terminology, I have a
> feeling I'm not quite calling everything its right name!)
>
> Upon inspecttion, it looks like the binutils port we have been using
> for the past few years (not CGEN-based) has a right-shift of 2 in the
> md_apply_fix() function in binutils/gas/config/tc-or32.c (
> http://sourceware.org/git/?p=binutils.git;a=blob;f=gas/config/tc-or32.c;h=7234fb837e006f979c255f62206e39a9822046d2;hb=HEAD#l603
> ) when the instruction had the actual value of the label inserted into
> it.
>
> Is there any way to handle this using the CGEN description?

I don't know about that.

> The current instruction field definition being used is:
>
> (df f-disp26     "disp26"              (PCREL-ADDR) 25 26 INT
>      ((value pc) (sra WI (sub WI value pc) (const 2)))
>      ((value pc) (add WI (sll WI value (const 2)) pc)))
>
> This does the shifting on encode and the target label addresses are
> right but the numerical immediates are wrong, but if I remove the sra
> on the encode, the numerical immediates are right but the target label
> addresses are wrong.
>
> I've had a bit of a poke around and seen the function
> gas_cgen_md_apply_fix() is used as a generic md_apply_fix() function,
> but can't quite see where I might be able to hook in things for
> particular encoding cases.

What might work is to drop the shifting from the field definition and 
create your own md_apply_fix function something like this,

void
md_apply_fix (fixS *fixP, valueT *valP, segT seg)
{
   if (fixP->fx_done
       && fixP->fx_r_type == BFD_RELOC_UNUSED + OPERAND_ID_OF_BRANCH)
     {
        gas_assert (fixP->fx_addsy == NULL);
        gas_assert (fixP->fx_subsy == NULL);

        *valP >>= 2;
     }

     gas_cgen_md_apply_fix (fixP, valP, seg);
}


Good luck!

Andrew