|
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
|