From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5816 invoked by alias); 12 May 2003 12:36:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 5629 invoked by uid 71); 12 May 2003 12:36:00 -0000 Date: Mon, 12 May 2003 12:36:00 -0000 Message-ID: <20030512123600.5598.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Philip Graham Willoughby Subject: Re: inline-asm/9637: arguments passed/return to asm block via mmx registers trigger failure Reply-To: Philip Graham Willoughby X-SW-Source: 2003-05/txt/msg01221.txt.bz2 List-Id: The following reply was made to PR inline-asm/9637; it has been noted by GNATS. From: Philip Graham Willoughby To: Dara Hazeghi , gcc-gnats@gcc.gnu.org, pgw99@doc.ic.ac.uk, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org Cc: Subject: Re: inline-asm/9637: arguments passed/return to asm block via mmx registers trigger failure Date: Mon, 12 May 2003 13:26:07 +0100 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&database=3D= gcc&pr=3D9637 On 2003-05-10 14:07:50 +0000, Dara Hazeghi wrote: >=20 > It seems that the crash has been solved, and we now exit gracefully. =20 > Can the submitter verify if the code in question is in fact faulty? =20 I now have a somewhat better understanding of inline asm than when I submit= ted this bug. Here is an explanation of what the operative (well, problematic) lines of t= his code: : "=3Dy" (c), "=3Dy" (a), "=3Dy" (b) : "0" (c) are actually supposed to do. The first line means "Pick three MMX registers. These will contain the val= ues of c, a and b at the end of the ASM instructions. I've called them $y0, %y1 and %y2 inside the asm block, and I need you to substitute those names with= the names of the registers you picked." The second line means "Remember the first register you picked? Well, I want you to put the value of c into it before running the ASM block." So far this matches what the documentation says. Now, on to the reasons I think that this code might have failed: * Reason 1: The function tries to use a FP value and the MMX registes in the same funct= ion, and you can't mix FP calls and MMX calls indiscriminately. - Good Solution: Fix gcc to add the appropriate calls to save/restore the FP stack before/af= ter asm blocks which use MMX registers - Bad Solution: Change the documentation so it says "You cannot mix FP and MMX calls in the same function." * Reason 2: GCC doesn't actually understand how to pass things to/from MMX registers. - Good Solution: Fix gcc to bring it in line with what the docs say. - Bad Solution: Change the docs to remove references to MMX register constraints to asm. * Reason 3: GCC doesn't know how to move a "long long" value into or out of an MMX register. - Good Solution: Teach it how - they are the same length, so it ought not to be a problem. Alignment _may_ be an issue however. - Bad Solution: Change the docs to say it doesn't work. That would raise the question of w= hat in fact gcc can move into an MMX register... Hope all this helps. The bottom line is that the code as written should wo= rk if gcc behaves as documented. I can't assure you that the asm actually wor= ks when compiled because I have never persuaded gcc to compile it ;-), plus of course there are better instructions to do the same from the SSE instruction set. I'd still like to resolve this as a fallback path for k6 and pre-xp athlon processors. Regards, Philip Willoughby Systems Programmer, Department of Computing, Imperial College, London, UK --=20 echo bzidd@nfo.ho.co.se | tr "bizndfohces" "pwgd9ociaku" Why reinvent the wheel? Because we can make it rounder... --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+v5Lei294YDsKgb0RAs45AJ4tkK74mdvT4d3fqPWs4WQ6nW/5vgCfWftw 9bTsuY7NSxyhKxF0df7zOzg= =6g+R -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1--