From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gctDF-0005jr-UX for qemu-devel@nongnu.org; Fri, 28 Dec 2018 09:34:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gct9P-0001iL-B8 for qemu-devel@nongnu.org; Fri, 28 Dec 2018 09:30:12 -0500 Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]:37014) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gcstG-0001Sy-27 for qemu-devel@nongnu.org; Fri, 28 Dec 2018 09:13:30 -0500 Received: by mail-ot1-x331.google.com with SMTP id 40so18729754oth.4 for ; Fri, 28 Dec 2018 06:13:27 -0800 (PST) MIME-Version: 1.0 References: <945511ac-d99a-d483-12a2-e6ad4dda09c2@linaro.org> In-Reply-To: From: Peter Maydell Date: Fri, 28 Dec 2018 14:13:13 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] AVX support for TCG List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nick Renieris Cc: Richard Henderson , QEMU Developers On Fri, 28 Dec 2018 at 13:45, Nick Renieris wrote: > Also, I hope you meant four months for me, not for you - I'm > completely new to the QEMU codebase. I expect it will take me weeks > just to understand x86's 'translate.c' (who thought it'd be a good > idea to put all this stuff in _one_ file?). x86 suffers from being one of the first and oldest frontends, and on top of that from not having had a great deal of active attention. So it has a lot of remnants from older styles of implementation, as well as the kind of "one big function in one huge file" that organic growth of a codebase tends to give you. It doesn't make that much difference whether you have one file or several, though -- target/arm/translate-a64.c is pretty well structured and easy (IMHO) to comprehend, but it's 5000 lines longer than target/i386/translate.c. The comprehensibility improvements come from better breakdown into separate functions and much clearer commenting of the extent of the decode at any particular point (plus not having any legacy baggage to deal with). thanks -- PMM