From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH 7/9] arm: replace arbitrary divisions Date: Thu, 17 Oct 2013 11:59:26 -0700 Message-ID: <20131017185926.GR24837@cbox> References: <1381767815-12510-1-git-send-email-drjones@redhat.com> <1381767815-12510-8-git-send-email-drjones@redhat.com> <20131017010629.GJ24837@cbox> <20131017100322.GC2172@hawk.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, gleb@redhat.com To: Andrew Jones Return-path: Received: from mail-pd0-f172.google.com ([209.85.192.172]:43636 "EHLO mail-pd0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758714Ab3JQS6n (ORCPT ); Thu, 17 Oct 2013 14:58:43 -0400 Received: by mail-pd0-f172.google.com with SMTP id z10so3263676pdj.31 for ; Thu, 17 Oct 2013 11:58:42 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20131017100322.GC2172@hawk.usersys.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Oct 17, 2013 at 12:03:23PM +0200, Andrew Jones wrote: > On Wed, Oct 16, 2013 at 06:06:29PM -0700, Christoffer Dall wrote: > > On Mon, Oct 14, 2013 at 06:23:33PM +0200, Andrew Jones wrote: > > > arm can't do arbitrary divisions without software support. Usually > > > libgcc would jump in here, but depending on the toolchain used that may > > > or may not work. Luckily, we only care about two types of divisions. > > > Divide by 10 and divide by 16. Divide by 16 is already covered by gcc > > > since it's a power of two. Divide by 10 can be hacked up using a > > > multiplication and shift. > > > > Isn't this just a matter of supplying a few libc implementations to > > handle div_by_0 and that sort? I'm pretty sure we had that working in > > the kvm-selftest for ARM thingy that allowed you to use the standard '/' > > operator in C code.... I suspect there will be more users of this > > eventually. > > > > Or wait, do you mean 'long long' operations by arbitrary? In that case, > > I'm less sure... A library implementation to support the operator would > > still be preferred IMHO. > > No, that's not what I meant, nor can I pretend that's what I meant now :-) > I saw that you had brought lib1funcs.S into kvm-selftest, but I'm not sure > why I rejected doing the same thing... Probably because my reflex was to > not adopt a bunch of assembler that I didn't want to maintain. But I guess > there's nothing to maintain there. It works, and will always work. I'll > switch to using it. > I think so, and I'll gladly help you maintain those bits. -Christoffer