From: Stan Sieler <sieler@allegro.com>
To: Philipp.H.Rumpf@mathe.stud.uni-erlangen.de (Philipp Rumpf)
Cc: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux] Progress
Date: Tue, 23 Nov 1999 13:11:44 -0800 (PST) [thread overview]
Message-ID: <199911232111.NAA25923@opus.allegro.com> (raw)
In-Reply-To: <19991123190339.H1009@mathe.stud.uni-erlangen.de> from "Philipp Rumpf" at Nov 23, 1999 07:03:39 PM
Re:
> I'd agree this loop is the nicest of the "real" delay loops so far, but I'm
> still unconvinced there's any advantage to using a "real" delay loop over a
> CR16-based one.
If interrupts can happen (and get serviced), a CR16 loop is inherently
unreliable. If you're looping until CR16 becomes >= some value, X, then
you might find that CR16 goes: n, n+2, n+3, n-10000, n-9998, ...
I.e., the interrupt servicing could take enough time that the value in
CR16 becomes misleading. If the new CR16 is < the last seen one, is it
simply because it "rolled over", or because an interrupt came in and
you've spent an unknown amount of time doing other things?
OTOH, I like the idea of using a drastic change to CR16 as a signal
that "something happened", and consider using that as a clue
to prematurely exit a counter-based loop. In that scenario, I'd
expect a routine like: delay (int loops, int premature_exit_ok),
which would let the caller decide if a premature (CR16 change based)
exit was allowable.
--
Stan Sieler sieler@allegro.com
www.allegro.com/sieler/wanted/index.html www.allegro.com/sieler
next prev parent reply other threads:[~1999-11-23 21:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-11-18 23:16 [parisc-linux] Progress John David Anglin
1999-11-19 3:30 ` Philipp Rumpf
1999-11-21 23:07 ` John David Anglin
1999-11-22 1:12 ` John David Anglin
1999-11-22 8:24 ` Philipp Rumpf
1999-11-22 9:59 ` Alan Cox
1999-11-22 15:54 ` Philipp Rumpf
1999-11-22 7:30 ` Philipp Rumpf
1999-11-22 18:11 ` John David Anglin
1999-11-22 18:27 ` Stan Sieler
1999-11-22 18:42 ` Philipp Rumpf
1999-11-22 18:33 ` Philipp Rumpf
1999-11-22 20:55 ` John David Anglin
1999-11-23 11:47 ` Philipp Rumpf
1999-11-23 16:19 ` John David Anglin
1999-11-23 18:03 ` Philipp Rumpf
1999-11-23 19:01 ` John David Anglin
1999-11-23 21:11 ` Stan Sieler [this message]
1999-11-24 10:00 ` Philipp Rumpf
1999-11-24 19:00 ` Stan Sieler
1999-11-24 19:33 ` Philipp Rumpf
1999-11-24 20:55 ` [parisc-linux] Progress - Update John David Anglin
1999-11-24 21:05 ` Philipp Rumpf
1999-11-24 21:27 ` Kirk Bresniker
1999-11-24 21:37 ` Philipp Rumpf
1999-11-24 22:38 ` Frank Rowand
1999-11-24 23:24 ` Cache Flushes Grant Grundler
1999-11-25 0:31 ` [parisc-linux] Progress - Update John David Anglin
1999-11-25 1:17 ` Alan Cox
1999-11-25 13:24 ` Philipp Rumpf
1999-11-25 23:47 ` John David Anglin
1999-11-30 18:17 ` John David Anglin
1999-11-30 18:21 ` Alan Cox
1999-11-30 18:32 ` Philipp Rumpf
1999-11-30 19:31 ` Alan Cox
1999-11-30 20:14 ` Mark Klein
1999-11-30 23:40 ` John David Anglin
1999-12-01 15:41 ` Philipp Rumpf
1999-12-01 18:03 ` Alan Cox
1999-12-01 18:29 ` Alex deVries
1999-12-01 18:34 ` Alan Cox
1999-12-02 2:51 ` Philipp Rumpf
1999-12-01 18:33 ` John David Anglin
1999-12-01 18:54 ` Alan Cox
1999-12-01 18:55 ` Grant Grundler
1999-11-26 13:40 ` Matthew Wilcox
1999-11-23 15:59 ` [parisc-linux] Progress Paul Bame
1999-11-23 16:33 ` John David Anglin
1999-11-23 17:05 ` Paul Bame
1999-11-23 20:15 ` John David Anglin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199911232111.NAA25923@opus.allegro.com \
--to=sieler@allegro.com \
--cc=Philipp.H.Rumpf@mathe.stud.uni-erlangen.de \
--cc=parisc-linux@thepuffingroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox