[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070919110053.GB15500@Krystal>
Date: Wed, 19 Sep 2007 07:00:53 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, Andi Kleen <ak@....de>,
Chuck Ebbert <cebbert@...hat.com>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [patch 4/7] Immediate Values - i386 Optimization
* H. Peter Anvin (hpa@...or.com) wrote:
> Jeremy Fitzhardinge 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.
>
> Allowing different registers should be doable, but if so, one would have
> to put 0: at the *end* of the instruction and use (0f)-4 instead, since
> the non-%eax forms are one byte longer.
>
> This also seems "safer", since an imm32 is always the last thing in the
> instruction.
>
The idea is very interesting, but then, if I can't be sure of the size
of my instruction, how can I align the immediate value properly ?
> -hpa
>
--
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists