From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:43713)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1QNXGy-0004IE-AX
	for qemu-devel@nongnu.org; Fri, 20 May 2011 17:30:17 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1QNXGx-0003fx-Bb
	for qemu-devel@nongnu.org; Fri, 20 May 2011 17:30:16 -0400
Received: from mail-bw0-f45.google.com ([209.85.214.45]:63678)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jcmvbkbc@gmail.com>) id 1QNXGx-0003ft-5W
	for qemu-devel@nongnu.org; Fri, 20 May 2011 17:30:15 -0400
Received: by bwz16 with SMTP id 16so3606549bwz.4
	for <qemu-devel@nongnu.org>; Fri, 20 May 2011 14:30:14 -0700 (PDT)
From: Max Filippov <jcmvbkbc@gmail.com>
Date: Sat, 21 May 2011 01:30:10 +0400
References: <1305671572-5899-1-git-send-email-jcmvbkbc@gmail.com>
	<201105210005.00438.jcmvbkbc@gmail.com>
	<4DD6D3CE.1070701@twiddle.net>
In-Reply-To: <4DD6D3CE.1070701@twiddle.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201105210130.11067.jcmvbkbc@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 23/26] target-xtensa: implement interrupt
	option
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org

> > By the way, do I understand it right that if I chain TBs than I need
> > to periodically check for pending interrupts myself, otherwise e.g.
> > "j $" will create uninterruptible infinite loop?
> 
> No, it won't.  It'll create a loop, but it'll be broken by the host
> signal handler.  Notice no other target is checking for this.
> 
> >>> +DEF_HELPER_0(check_interrupts, void)
> >>> +DEF_HELPER_2(waiti, void, i32, i32)
> >>> +DEF_HELPER_2(timer_irq, void, i32, i32)
> >>> +DEF_HELPER_1(advance_ccount, void, i32)
> >>
> >> You shouldn't have to manage any of this from within the translator.
> 
> You should *never* have to check for interrupts, or advance cycle counters,
> from within the translated code.  Interrupt processing, and thus timers,
> are handled in between TBs as necessary by generic code.

Well,
- cycles fed into advance_ccount may (and on real hardware actually do) depend on executed commands/pipeline/cache hits. Most of this stuff may be counted at the translation time;
- timer_irq is a helper that raises IRQ generated by CCOMPARE match;
- waiti is a helper for the instruction of the same name;
- check_interrupts converts IRQs on enabled interrupt sources into current irq level.

Thanks.
-- Max