Home Original page

[RFC PATCH] .bundle_align_mode

Roland McGrath mcgrathr@google.com
Tue Feb 21 19:29:00 GMT 2012 
Thanks for the feedback and sorry for the delay.
(I was out sick and then it was a long weekend in the US.)

On Thu, Feb 16, 2012 at 3:01 AM, nick clifton <nickc@redhat.com> wrote:
>> The short version is, "For some
>> targets, it's an ABI requirement that no instruction may span a certain
>> aligned boundary."  Is that what you had in mind?
>
> For the documentation, yes, thanks.

Done.

> Good point - I do not know of any architectures with both variable sized
> insns and delay slots.  Although... what about anulling instructions ? The
> RL78 for example has variable length instructions, one of which is the SKC
> instruction (skip following if carry set).  Note: I have no problems with
> you specifying that .bundle_align_mode will not work with such
> architectures.  I just wanted to raise the possibility of awkward targets.

Thanks for pointing it out.  It might be sufficient just to expect people
to use .bundle_lock explicitly around such sequences.  Or perhaps for such
targets it will make sense to have special cases for certain instructions.
I think for now I'm happy to conclude that adding the bundle support for
some CPUs may require more implementation work than I'll do in the initial
set of ports.

> I was thinking specifically of linker relaxation where the linker can
> replace longer instruction sequences with shorter ones.  Targets that
> support this feature already have special relocs to handle normal alignment
> requirements, so I expect that it would be fairly easy to add another one to
> cope with bundle lengths.  Or just refuse to support bundle_align_mode and
> linker relaxation in the same target.

Ah, I'm not familiar with such targets, unless there is a reloc like that
for ARM that I don't know about.  So again I think I'm satisfied to leave
that concern for whenever the time comes to do a port to such a target.

> [...]  If you request a reduced alignment then you should know what you
> are doing.

Indeed.

Thanks very much for the feedback so far, Nick.  But I still haven't heard
anything in the areas in which I was hoping to receive some wisdom.  That
is, the general implementation plan with the alignment frags (is there a
better way?), the hook interface for the CPU-specific code (is md_max_size
a good name and/or signature?), and optimal implementations of that hook
for x86 and ARM.


Thanks,
Roland
More information about the Binutils mailing list