This is the mail archive of the
mailing list for the binutils project.
Re: Gas can't handle prefix generated by gcc
> "H. J. Lu" <email@example.com> writes:
> >> 1) Make GAS accept cs;je and do the right thing.
> >> 2) Prove that cs/je, rep/stosl, etc are acceptable to all i386
> >> assemblers since time immemorial.
> >> 3) Write the GCC patch yourself. And I will not review it.
> >> And yes, those are in order of decreasing preference.
> > ';' is a line terminator for assembler. Assembler won't see the string
> > of "cs;je" at all. I don't think adding such a hack for gcc is a good
> > idea.
> My idea of the Right Thing would be to recognize an instruction
> consisting only of a prefix opcode (any prefix opcode - not just
> segment overrides), and save it to be combined with the next one.
> That would handle "cs;je", "rep\n\tmovsl", and so on.
> It's not just GCC that does this; take a look at the Linux kernel's
> arch/i386 assembly files.
> > I can write a patch. But who will review it?
> Not me.
Being the author of original code ;) I have few comments for the thread
(trying to get out of backlog from email from last month)
about effectivity of prefixes - I did some initial testing on the P4
hardware and I got no speedups (nor slowdowns) on SPEC and Byte
benchmarks. I however measured small speedups on GCC (don't recall
exact percentage but it was out of noise) when compiled with profiling.
My conclussion was that the code needs to be huge enought to make the
trace cache pollution (the preffixes are supposed to reduce) visible, so
it looked like good and simple addition to GCC that should help large
codebases. Since I don't have any strong data supporting the branch
hints and common practice appears to not use them, I would be happy to
disable them by default for now.
However except for Zack's testcase with '.' operator where it is dubious
if the instruction starts before the prefix (writen explicitly via ; as
separate instruction) or before the prefixed instruction I don't see any
dubiousity in the usual syntax with explicit jump destination. (and in
fact if I read Zack's code somewhere I would interpret it precisely same
way as gas does). Why the jump destination would be affected by the
prefix when the offset is relative to the end of the instruction?
And my preffered sollution would be to make both 32bit and 64bit gasses
behave consisstenly, and it seems only feasible to fix 64bit gas to
behave like 32bit counterpart as other way will break GCC compatibility.
I will try to look into it unless someone beats me ;)