This is the mail archive of the
mailing list for the binutils project.
Re: [RFC PATCH] .bundle_align_mode
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 <email@example.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.
> 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.
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.