From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kuninori Morimoto Date: Wed, 18 Dec 2019 05:21:14 +0000 Subject: Re: can someone solve string_32.h issue for SH ? Message-Id: <87a77qjjjp.wl-kuninori.morimoto.gx@renesas.com> List-Id: References: <339916914.636876.1576627652112.ref@mail.yahoo.com> <339916914.636876.1576627652112@mail.yahoo.com> <87tv5yjssb.wl-kuninori.morimoto.gx@renesas.com> <2107393677.694216.1576641363699@mail.yahoo.com> In-Reply-To: <2107393677.694216.1576641363699@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Karl Nasrallah Cc: dalias@libc.org, geert@linux-m68k.org, ysato@users.sourceforge.jp, linux-sh@vger.kernel.org, linux-renesas-soc@vger.kernel.org Hi Karl Thank you for your help > Or, can we use general strncpy() instead of SH assemble one ? (snip) > Though ultimately I do not have a say in that, it would appear that string_32.h is in arch/sh/include/asm > and has been there for a very long time. > In fact, it appears that x86 also has similar utility functions defined in inline assembly: > see arch/x86/include/asm. As straightforward as it would be to make C versions, there may be a reason > that they are in inline assembly--optimization would be my guess--and converting it all to C may require> > an overhaul of the string.h backend (something I would not be much help with given that I am unable to get > modern Linux booting on my machine, which is a Sega Dreamcast). > I also do not know what the performance implications of switching it all to C would be, if there even are any. > > Hopefully this information may be useful and my asm version is alright for the time being; > I have not been able to unearth much more on the topic of why this is structured the way it is, How about this ? You / I post each patch (= Me: use generic strnpy() patch You: fixup SH strnpy() patch) And follow SH maintainer's judge Thank you for your help !! Best regards --- Kuninori Morimoto From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5882C43603 for ; Wed, 18 Dec 2019 05:21:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A260520733 for ; Wed, 18 Dec 2019 05:21:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725811AbfLRFVQ (ORCPT ); Wed, 18 Dec 2019 00:21:16 -0500 Received: from relmlor1.renesas.com ([210.160.252.171]:60657 "EHLO relmlie5.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725797AbfLRFVQ (ORCPT ); Wed, 18 Dec 2019 00:21:16 -0500 Date: 18 Dec 2019 14:21:14 +0900 X-IronPort-AV: E=Sophos;i="5.69,328,1571670000"; d="scan'208";a="34723073" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie5.idc.renesas.com with ESMTP; 18 Dec 2019 14:21:14 +0900 Received: from morimoto-PC.renesas.com (unknown [10.166.18.140]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id 734E141C3C14; Wed, 18 Dec 2019 14:21:14 +0900 (JST) Message-ID: <87a77qjjjp.wl-kuninori.morimoto.gx@renesas.com> From: Kuninori Morimoto To: Karl Nasrallah Cc: dalias@libc.org, geert@linux-m68k.org, ysato@users.sourceforge.jp, linux-sh@vger.kernel.org, linux-renesas-soc@vger.kernel.org Subject: Re: can someone solve string_32.h issue for SH ? In-Reply-To: <2107393677.694216.1576641363699@mail.yahoo.com> References: <339916914.636876.1576627652112.ref@mail.yahoo.com> <339916914.636876.1576627652112@mail.yahoo.com> <87tv5yjssb.wl-kuninori.morimoto.gx@renesas.com> <2107393677.694216.1576641363699@mail.yahoo.com> User-Agent: Wanderlust/2.15.9 Emacs/24.5 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org Hi Karl Thank you for your help > Or, can we use general strncpy() instead of SH assemble one ? (snip) > Though ultimately I do not have a say in that, it would appear that string_32.h is in arch/sh/include/asm > and has been there for a very long time. > In fact, it appears that x86 also has similar utility functions defined in inline assembly: > see arch/x86/include/asm. As straightforward as it would be to make C versions, there may be a reason > that they are in inline assembly--optimization would be my guess--and converting it all to C may require> > an overhaul of the string.h backend (something I would not be much help with given that I am unable to get > modern Linux booting on my machine, which is a Sega Dreamcast). > I also do not know what the performance implications of switching it all to C would be, if there even are any. > > Hopefully this information may be useful and my asm version is alright for the time being; > I have not been able to unearth much more on the topic of why this is structured the way it is, How about this ? You / I post each patch (= Me: use generic strnpy() patch You: fixup SH strnpy() patch) And follow SH maintainer's judge Thank you for your help !! Best regards --- Kuninori Morimoto