[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4864CFA5.9050901@agner.org>
Date: Fri, 27 Jun 2008 13:31:49 +0200
From: Agner Fog <agner@...er.org>
To: "H. Peter Anvin" <hpa@...or.com>
CC: Arjan van de Ven <arjan@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: ABI change for device drivers using future AVX instruction set
Arjan van de Ven wrote:
>the linux kernel policy is loud and clear; this is more an OS policy as
>it is a platform ABI issue.
It doesn't help to say it "loud and clear" in a closed mailing list. It has to go into an official document that people can find, and the ABI is the most natural place to look for such rules. The ABI is hard enough to find. Is there an official OS policy document somewhere that I haven't found? Please point me to an authoritative document.
You can't blame driver makers for using XMM or YMM registers in inline assembly or intrinsic functions or calling their own libraries or using a different compiler unless there is an official rule against it written in some official document that is easy to find. If you want to move data in a device driver, it is tempting indeed to use the largest register size available.
I will write the rules in my manual, but it is not authoritative.
H. Peter Anvin wrote:
>Sadly, AVX repeats the mistakes of SSE1, and doesn't implement proper
wide support for integer operations.
>It has the basic bitwide stuff, which makes it usable for RAID-5, but
it doesn't extend MMX (which SSE2
>eventually got around to), so it's not usable for RAID-6. I'd hoped
to find a VPERM-style instruction, like
>SSE5 has :(
There is no problem in using the floating point permutation instructions
on integer data. They will not generate exceptions or anything on
denormal numbers. Only the smallest data size is 32 bits, of course.
Integer YMM instructions will probably come in a later version.
Note: Please Cc: me on answers, I am not on the mailing list.
--
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