* H. Peter Anvin ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to