Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: Mark Gordon <spamtrap AT ruddygore DOT net>
To: cygwin AT sources DOT redhat DOT com
Subject: Re: Signal handling in tight loops
Date: Wed, 15 Aug 2001 16:31:10 +0100
Organization: Only Occasionally
Message-ID: <eu2lnto3j2fp2cnkpoe0slaeblsp4bcj41@4ax.com>
References: <20010808002825 DOT 36F611F9CF8 AT deborah DOT paradise DOT net DOT nz> <5 DOT 1 DOT 0 DOT 14 DOT 0 DOT 20010808135357 DOT 03eb8030 AT mail>
In-Reply-To: <5.1.0.14.0.20010808135357.03eb8030@mail>
X-Mailer: Forte Agent 1.8/32.553
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id LAA30316

On Wed, 08 Aug 2001 13:57:03 -0400, "David A. Cobb"
<superbiskit AT home DOT com> wrote:

>At 8/7/01 08:28 PM (Tuesday), ejrh AT paradise DOT net DOT nz wrote:
>> > Wow.  You haven't been home for 24 hours?  I hope you're getting
>> > overtime.
>>
>>I was at home when I sent the question (some time around midnight, I
>>think), but it was here at work that I got your response.
>>
>>No matter.  Assuming that SIGALRM can't be raised inside loops of the
>>form,
>>
>>L1: jmp L1
>
>!! I hope that's a joke !!
>I haven't tried it on intel architecture, but on many processors there 
>would never be another read-next-instruction cycle, never another 
>interrupt, nothing at all until you pulled the plug.  Anyway, it isn't a 
>Cygwin issue - it's in the processor wiring/microcode.

On the processors I used to deal with the processor would still be
checking for interrupts in a loop like this. Mind you, I can't see
much use for this in normal software. In embedded systems I have done
something close...

loop: IDLE
      B    loop

as a background loop.

I just checked up on one of the old embedded 80x86 processors and it
is the instruction boundary, not the fetch which determines the
processor recognising interrupts.

>>what do you say to the idea of parsing the .s files for this sort of
>>pattern, and dealing with it there?

There should be no need because the processor should still respond to
interrupts as normal. Although why someone would do this in an
application is another matter.
-- 
Mark Gordon - To email me replace spamtrap with mark.gordon
	This message has been brought to you by the Flash AI Responder.
	No humans were harmed (or involved in any way) in its production.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/