Messages in this thread | | | Date | Wed, 19 Sep 2007 06:59:51 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [patch 4/7] Immediate Values - i386 Optimization |
| |
* Jeremy Fitzhardinge (jeremy@goop.org) wrote: > Mathieu Desnoyers wrote: > > > +#define immediate_read(name) \ > > + ({ \ > > + __typeof__(name##__immediate) value; \ > > + switch (sizeof(value)) { \ > > + case 1: \ > > + asm ( ".section __immediate, \"a\", @progbits;\n\t" \ > > + ".long %1, (0f)+1, 1;\n\t" \ > > + ".previous;\n\t" \ > > + "0:\n\t" \ > > + "mov %2,%0;\n\t" \ > > Given that you're relying on the exact instruction that this mov > generates, it might be better to explicitly put the opcodes in with > .byte. That way you're protected from the assembler deciding to > generate some other form of the instruction (for whatever reason). I > guess substituting in different registers would be a pain. >
Good point. I thought it might come up, especially for 16 bits mov that can be expressed under different forms, one of which has a prefix. I would like to go for Peter's suggestion: putting the label _after_ the instruction, since we know that we will be right after the immediate value, but it has a drawback: we cannot insure correct alignment of the immediate value in that case. But that would help not having to force the register.
> Aside from that, is there any reason not to just put $0 in there rather > than use %2? >
Actually, no, since the initial value is written to the immediate value references at early boot and at module load time. I originally thought passing the referenced variable to it, but, as I recall, it brought linker issues when the symbol was defined in another module. So yes, just $0 is ok, I'll change that.
> > > + ".long %1, (0f)+1, 4;\n\t" \ > > + ".previous;\n\t" \ > > + "1:\n\t" \ > > + ".org (1b)+(3-((1b)%%4)), 0x90;\n\t" \ > > > Seems a little complex, but I couldn't come up with anything much better: > > .org . + 3 - (. & 3), 0x90 > > You can use . rather than needing to define 1:, it doesn't need quite so > many parens, and using &3 avoids the %% wart. >
Yes, this one is tricky.. trying to align efficiently something on a 4 bytes address - 1 is not what gas is used to help doing.
> It's a pity that gas seems to generate plain 0x90 nops rather than > long-nop forms here. I thought it could do that. >
At least we will have at most 3 nops there.
Mathieu
> J
-- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |