|
From: Florian K. <br...@ac...> - 2011-03-26 03:44:19
|
Hello Julian,
I've got two questions regarding the VEX_HWCAPS_... encoding in libvex.h
First: I noticed that after the s390x merge the encoding of the hardware
capabilities is no longer unique. E.g. the encoding 1<<14 has more than
one interpretation.
/* ppc64: baseline capability is integer and basic FP insns */
#define VEX_HWCAPS_PPC64_V (1<<12) /* Altivec (VMX) */
#define VEX_HWCAPS_PPC64_FX (1<<13) /* FP extns (fsqrt, fsqrts) */
#define VEX_HWCAPS_PPC64_GX (1<<14) /* Graphics extns
(fres,frsqrte,fsel,stfiwx) */
/* s390x: baseline capability is z/Architecture with long displacement */
#define VEX_HWCAPS_S390X_LDISP (1<<13) /* Long-displacement facility */
#define VEX_HWCAPS_S390X_EIMM (1<<14) /* Extended-immediate facility */
#define VEX_HWCAPS_S390X_GIE (1<<15) /* General-instruction-extension
facility */
#define VEX_HWCAPS_S390X_DFP (1<<16) /* Decimal floating point facility */
...
Those encodings used to be all distinct. We just missed to follow up on
VEX r1995 and adjust the s390x encodings. But we are not alone.
ARM hwcaps and architecture levels overlap freely with the other hwcaps.
Is it correct, that there is no uniqueness requirement on the encodings anymore?
Secondly, for s390x I need to extract the machine model from /proc/cpuinfo.
The machine model is needed to fix PR 268620 and also for cache configuration
in cachegrind. If the answer to my first question is "yes", then I presume I
can just adapt what is being deon for ARM, namely:
#define VEX_S390X_ARCHLEVEL(x) ((x) & 0x3f)
OK?
Florian
|
|
From: Julian S. <js...@ac...> - 2011-03-26 06:29:07
|
> Those encodings used to be all distinct. We just missed to follow up on > VEX r1995 and adjust the s390x encodings. But we are not alone. > ARM hwcaps and architecture levels overlap freely with the other hwcaps. > > Is it correct, that there is no uniqueness requirement on the encodings > anymore? I believe that is correct. Obviously they need to be unique within a particular architecture, but no need for the distinct architecture sets to be unique. > Secondly, for s390x I need to extract the machine model from /proc/cpuinfo. > The machine model is needed to fix PR 268620 and also for cache > configuration in cachegrind. If the answer to my first question is "yes", > then I presume I can just adapt what is being deon for ARM, namely: > > #define VEX_S390X_ARCHLEVEL(x) ((x) & 0x3f) /me confused. The ARM stuff is taken from the auxv entries IIRC, not from /proc/cpuinfo. What piece of code are you referring to? J |
|
From: Florian K. <br...@ac...> - 2011-03-27 16:06:36
|
On 03/26/2011 02:23 AM, Julian Seward wrote: > >> Those encodings used to be all distinct. We just missed to follow up on >> VEX r1995 and adjust the s390x encodings. But we are not alone. >> ARM hwcaps and architecture levels overlap freely with the other hwcaps. >> >> Is it correct, that there is no uniqueness requirement on the encodings >> anymore? > > I believe that is correct. Obviously they need to be unique within > a particular architecture, but no need for the distinct architecture > sets to be unique. > > >> Secondly, for s390x I need to extract the machine model from /proc/cpuinfo. >> The machine model is needed to fix PR 268620 and also for cache >> configuration in cachegrind. If the answer to my first question is "yes", >> then I presume I can just adapt what is being deon for ARM, namely: >> >> #define VEX_S390X_ARCHLEVEL(x) ((x) & 0x3f) > > /me confused. The ARM stuff is taken from the auxv entries IIRC, > not from /proc/cpuinfo. What piece of code are you referring to? > Sorry for the confusion, I was merely referring to the mechanism of encoding the architecture level in the hwcaps. I was not referring to the mechanism how that information was obtained. You've answered my questions. Florian |