On Wed, Sep 19, 2001 at 03:22:40PM +0100, Christophe Rhodes wrote:
> I believe I understand what's going on in x86/float.lisp, around the
> VOPs translating for %log1p (flog1p and flog1p-pentium).
> The two vops are instructions for the same operation (:translate
> %log1p) and the same policy ((:policy :fast-safe) corresponding to
> safety > speed > (max space compilation-speed)).
> However, the flog1p-pentium uses a feature of the pentium
> architecture, a neato fyl2xp1 instruction (IANA x86 guru) that is not
> available on inferior architectures.
> This explains the reversal of the :guard instruction (actually, not
> completely, but I'm betting that the initial writer was
> overconservative). When :pentium is on *target-backend-features* (or
> whatever), then the compiler should use the flog1p-pentium VOP and not
> the ordinary flog1p; when :pentium isn't, then the ordinary flog1p VOP
> should be used, as we can't guarantee that the fyl2xp1 magic
> instruction will do its magic.
> This points, again, to the ideal; really, instead of those #!+ reader
> macros, we want something like
> (declaim (optimize (target-features :pentium :mmx)))
> to allow for sub-architecture-specific optimizations. If I were to
> provide a patch that did this for x86, is the above interface OK? Is
> there a better one?
Does anyone know how C and Fortran compilers and libraries handle this
issue? ("info gcc" doesn't give me any hits in the index on "mmx" or
"pentium"..) How important is this for performance? How many flags
like this are needed these days, and how complicated are their
If the number of flags is small, their interactions simple, and the
performance increase significant, this approach seems basically
reasonable to me, but I'd suggest a few tweaks:
1. I'm not sure it should be an optimization quality:
(DECLAIM (TARGET-FEATURES :PENTIUM :MMX))
might be better, since I'm not completely convinced it's logically
an optimization (any more than e.g. DYNAMIC-EXTENT is), and since
this way people using their code on other systems which don't
support this TARGET-FEATURES stuff can use CL's
(DECLAIM (DECLARATION TARGET-FEATURES))
as it's intended to be used.
2. If it's not actually interacting with *FEATURES* (not e.g. using
*FEATURES* for its default values) then some name which doesn't
refer to "features" might be better,
(DECLAIM (TARGET-SYSTEM-HAS :PENTIUM :MMX))
3. CMU CL feature names have historically been unclear about things
like whether they they mean "version 17 exactly" or "version greater
than or equal to 17", sometimes causing problems. If you end up
naming new features, I encourage you to give them names like
PENTIUM-PRO-OR-LATER or >=486 if that's what they mean; and if
you end up using old feature names, please provide documentation
of your understanding of the feature meaning if it's more precise
than the existing documentation.
If the number of flags is large or the interactions are complicated,
it might be worth specifying a more expressive system which includes
e.g. explicit information on which features override which other
features, error-checking for incompatible features, and so forth. Or
if that's premature now but a distinct possibility down the road, it
might be worth anticipating it at least in the documentation and
perhaps in the interface as well.
William Harold Newman <william.newman@...>
who can't reach SourceForge CVS or HTTP or SSH today, and isn't happy about it
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C