From patchwork Wed Oct 19 21:11:29 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kjetil Oftedal X-Patchwork-Id: 120692 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id CDE05B6F7B for ; Thu, 20 Oct 2011 08:20:12 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754376Ab1JSVUB (ORCPT ); Wed, 19 Oct 2011 17:20:01 -0400 Received: from mail47.e.nsc.no ([193.213.115.47]:61987 "EHLO mail47.e.nsc.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754196Ab1JSVUA (ORCPT ); Wed, 19 Oct 2011 17:20:00 -0400 Received: from 149.199.34.95.customer.cdi.no (149.199.34.95.customer.cdi.no [95.34.199.149]) by mail47.nsc.no (8.14.4/8.14.4) with ESMTP id p9JLJnPi012248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Oct 2011 23:19:50 +0200 (MEST) Date: Wed, 19 Oct 2011 23:11:29 +0200 (CEST) From: Kjetil Oftedal X-X-Sender: kjetil@oizys.tordivel.org To: David Miller cc: konrad@gaisler.com, sparclinux@vger.kernel.org, daniel@gaisler.com Subject: Re: [PATCH 3/4] sparc32: return destination pointer on return from memcpy In-Reply-To: <20111019.152951.1289973252553591449.davem@davemloft.net> Message-ID: References: <1318489205-315-4-git-send-email-konrad@gaisler.com> <20111019.000700.1958065818398834929.davem@davemloft.net> <4E9E8B55.2060004@gaisler.com> <20111019.152951.1289973252553591449.davem@davemloft.net> MIME-Version: 1.0 Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org On Wed, 19 Oct 2011, David Miller wrote: > From: Konrad Eisele > Date: Wed, 19 Oct 2011 10:33:25 +0200 > > > It seems to me that memcpy is tightly programmed. Is saving 2 lines of gdbstub.c > > diff worth a memcpy rewrite? > > You really can't find another register to save the initial %o0 value in? > Have you even tried? This might be considered a ugly hack. But what about using %y ? According to the V8 manual, %y might be destroyed across a procedure call, and none of the functions in memcpy.S use multiply/divide instructions. It is however not mentioned as a available register in the section dealing with leaf procedures. A quick test on a SS20 did not reveal any immediate side-effects, and the return value of memcpy is now the destination pointer. --- -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/sparc/lib/memcpy.S b/arch/sparc/lib/memcpy.S index 34fe657..0327309 100644 --- a/arch/sparc/lib/memcpy.S +++ b/arch/sparc/lib/memcpy.S @@ -23,8 +23,8 @@ x: * One should use macros in asm/string.h for that purpose. * We return 0, so that bugs are more apparent. */ -#define SETUP_RETL -#define RETL_INSN clr %o0 +#define SETUP_RETL mov %o0, %y +#define RETL_INSN mov %y, %o0 #else