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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 80432C433E0 for ; Fri, 15 Jan 2021 20:33:46 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BC84E23A5A for ; Fri, 15 Jan 2021 20:33:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC84E23A5A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:56444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0Vmy-00050z-Fe for qemu-devel@archiver.kernel.org; Fri, 15 Jan 2021 15:33:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0Vka-0003i0-TY for qemu-devel@nongnu.org; Fri, 15 Jan 2021 15:31:16 -0500 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]:33654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l0VkZ-0008Es-6l for qemu-devel@nongnu.org; Fri, 15 Jan 2021 15:31:16 -0500 Received: by mail-pj1-x1033.google.com with SMTP id w1so6711827pjc.0 for ; Fri, 15 Jan 2021 12:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FCzJk7V8W0zjOgsrORXZNgr+zZX1wsc15/d2WDgjDY8=; b=FSS6QlmaaS9f+uq1UVc3TFlzCJBIGHmdpSnZgv5GdbjDEu3R45o0AZ5jeBF8mk7Bqs y4PjpeT0spnb+ypriv6yQ6nTlGpVRJpgGrNZGGG1sylS0ap+hAv8MuEvi8ZB/YhuRDzX phecwPL4mhs/CEi9hT3TFytgiGAfWxl7YngDgh5qROazoSoUTKHkwVVYzcEnqpXHUJhj oLU9lyoKnyroWgSXIG3F5Cj2peOffOeUmsbwGRAc28ydsUPW2XYPaKMDLmbdJnvLq2zP KzKTm4Olx/JObjJNpQy+EggJG+EnpTnHValOy7xeRMhVlqCktgzl0ei9iWxV0OH+u0MI Z4gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FCzJk7V8W0zjOgsrORXZNgr+zZX1wsc15/d2WDgjDY8=; b=bJujOdRIAfNIJt10zI8iL/d7Dk22Rx5paQsL9HAAzpYxRqVhN2Fn/wCdZIqAFMTFUB RoM6i9yZ6z9TByuonZxOPZ9ndqoXdPW2o3GdVT/dTfGqNHSc9q4o4yh9vqECd2QSJO7C woTPziYYTL2LvCjTGvERfzSvNiL3HW6CEJzxqa7ZPvVaWNDkA6BWfcBCqXrn6fFVBhTO LTTgFZLpzA6YLU1mWtp6zYue5vSBXUTy82pTR+d/G0OAadtOOL3T44Yj0/uFAQJnB4K5 d1Zh7ZwXGBSepVGgc6R8Z75eQrvNwq4df5cOvEh2grtDDYF7SXr4IWr0PNIrHxUwKT7l 8VFQ== X-Gm-Message-State: AOAM530Q7WUs9Xqtvd0HnlNtoej4Ii+P1VFTMu8RH8pXZXkk14s3twza y+M5fU6Ru+7++WfHC146R/WMyg== X-Google-Smtp-Source: ABdhPJxHaK/ejMCpLwgWFBqe7qpdng85R70jNSiKbQgV3lVZ93psmp01c7nl6qPjcyDYd6ysURqmrw== X-Received: by 2002:a17:90a:f0c1:: with SMTP id fa1mr12421572pjb.3.1610742673463; Fri, 15 Jan 2021 12:31:13 -0800 (PST) Received: from [10.25.18.3] (rrcs-173-197-107-21.west.biz.rr.com. [173.197.107.21]) by smtp.gmail.com with ESMTPSA id gb9sm8841178pjb.40.2021.01.15.12.31.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Jan 2021 12:31:12 -0800 (PST) Subject: Re: [PATCH 04/15] arc: TCG and decoder glue code and helpers To: Cupertino Miranda , "cupertinomiranda@gmail.com" , "qemu-devel@nongnu.org" References: <20201111161758.9636-1-cupertinomiranda@gmail.com> <20201111161758.9636-5-cupertinomiranda@gmail.com> <33ba8432-64c7-db76-459c-5fa6fd7e549a@linaro.org> From: Richard Henderson Message-ID: Date: Fri, 15 Jan 2021 10:31:09 -1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2607:f8b0:4864:20::1033; envelope-from=richard.henderson@linaro.org; helo=mail-pj1-x1033.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Shahab Vahedi , Claudiu Zissulescu , "linux-snps-arc@lists.infradead.org" , Claudiu Zissulescu , Shahab Vahedi Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 1/15/21 7:11 AM, Cupertino Miranda wrote: >> Similarly. I think that both of these could be implemented entirely in >> translate, which is what >> >>> + bool restore_fp = u7 & 0x10; /* u[4] indicates if fp must be saved */ >>> + bool restore_blink = u7 & 0x20; /* u[5] indicates saving of blink */ >>> + bool jump_to_blink = u7 & 0x40; /* u[6] should we jump to blink? */ >> >> these bits strongly imply. >> > > For lack of knowing better, it is unclear to me where to draw the line > when choosing between a translate time (tcg) or helper implementation. > Your suggestions for carry/overflow computation are sharp and we should > have never used an helper, however I wonder what would be the benefit of > implementing enter and leave through TCG. > > We have dealt with those exception issues by just changing SP in the end > of the instruction implementation, when no exceptions can happen. 5-10 tcg opcodes is the rule of thumb. A conditional exception (requiring a branch) is a good reason to put the whole thing out of line. In the case of enter or leave, this is one load/store plus one addition, followed by a branch. All of which is encoded as fields in the instruction. Extremely simple. > As far as I understand when an exception happens in the middle of the > helper or even on a TCG implementation, it jumps out of that TB > execution to deal with the exception. On rtie instead of it returning to > the same tcg_ld or tcg_st where it actually triggered the exception it > will re-decode the same instruction which triggered the exception, and > re-attempts to execute it. > Is that the case in current TCG implementation, or did it improved and > it is now able to return to previous execution flow (i.e translation > block) ? I think I don't understand your question. An exception leaves the TB, via longjmp. Before the longjmp, there is normally an "unwind" or "restore" operation, to sync the cpu state with the middle of the TB. This happens in restore_state_to_opc(). When processing of the exception is complete, execution will continue with the appropriate cpu state. Which will probably be a new TB that (logically) partially overlaps the previous TB. I.e. everything will work as you'd expect. So... what's the question? r~