Searching \ for '[OT] PC interrupts, guaranteed timing...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'PC interrupts, guaranteed timing...'.

Exact match. Not showing close matches.
PICList Thread
'[OT] PC interrupts, guaranteed timing...'
1999\03\24@084554 by Barry King

flavicon
face
I think there is a fundamental misunderstanding about DOS-like
operating systems versus a protected mode OS like Windows.

> Doesn't the Pentium CPU have a disable instruction itself??? How would the OS
> be able to do "atomic" functionality (eg: for resource allocation) else????
> How would an interrupt protect itself from being triggered over and over
> and corrupting megabytes of memory with pushing status to stack over and over?
?

> Don't tell me it hasn't.

Of course the CPU has an interrupt disable.  Of course the OS kernel
has to use it.

But if you are an APPLICATION running under Windows, you CANT USE IT.

In protected mode (Linux, Windows, QNX, etc.) The CPU "protects"
memory segments and restricts instructions which attempt to cause a
context switch, under a protection scheme controlled by the OS.  Bill
Gates decides what your application can do and when.  Or never.
(I'll spare you my rant about the flaws in the structure chosen by
MicroSoft.  If you don't like it either, go buy Linux, or QNX, or
something.)

If you attempt to execute one of these priviledged instructions, or
memory that the OS has not given to you, as an application, the CPU
turns you over to the authorities.  This is known as a "Processor
exception".  In Windows the exception handler can give the user a
"This Application has performed an illegal operation..." Window.
This is known as "Being blown off the machine."  :)

To get access to system hardware and especially interrupt function
under Windows, you have to be a Device Driver.

Writing a Win32 device driver (a VxD) is not impossible, but its
non-trivial. Debugging a Vxd is definitely non-trivial.  (Want to
trade your Tait programmer in for a $5000 Pentium emulator?  Me
neither.)

That's why I moved over to embedded programming- working under the
Windows structure takes all the fun out of hardware hacking.  Which
brings us back on topic!  PICs don't have a protected mode, hurrah!

------------
Barry King, KA1NLH
Engineering Manager
NRG Systems "Measuring the Wind's Energy"
Hinesburg, Vermont, USA
spam_OUTbarryTakeThisOuTspamnrgsystems.com
"The witty saying has been deleted due to limited EPROM space"

1999\03\24@134328 by William Chops Westfield

face picon face
   Of course the CPU has an interrupt disable.  Of course the OS kernel
   has to use it.

There is an ADDITIONAL "power management interrupt" on most modern (486+)
cpus that even the OS kernel may have troubles disabling.  I helped a guy
find info on it when his no-MS-present, netbsd laptop would mysteriously
drop into the standard windows-like "your battery is running low" popup when
the battery ran low (and perhaps at other times - it was a long time ago.)

I believe this is pretty much like the watchdog on a PIC - you enable it
at startup or via hardware, and then it can't be disabled any more...

BillW

1999\03\24@143558 by John Payson

flavicon
face
|Of course the CPU has an interrupt disable.  Of course the OS kernel
|has to use it.

|But if you are an APPLICATION running under Windows, you CANT USE IT.

Prior to the Pentium, read or write of the interrupt-enable flag by non-
privileged apps would force an OS trap.  Even pushing/popping the status
register would cause such traps (whether or not the software made any
effort to read/change the interrupt-enable bit within the stacked regi-
ster); some programs which happen to save/restore the status register a
lot can end up running **REALLY** slow under Windows for that reason.

Fortunately, Intel finally realized by the time the Pentium (or is it the
P-II) came around that it would be a good idea to add a second interrupt
control outside the status register.  Now, user software can set/clear
the interrupt enable in the main status register all it likes without any
problem; when it's time for the OS to time-slice the OS can examine that
bit and adjust its behavior as desired (e.g. if a thread has the interr-
upt enable flag cleared, the OS could decline to emulate any interrupts
for that process).

Of course, setting the flag in that case won't help the delays caused
when interrupts occur, but that's one of the hazards OS's can impose...

1999\03\24@151132 by Marc

flavicon
face
> But if you are an APPLICATION running under Windows, you CANT USE IT.

I didn't know that - it explains everything :(  Well I see Win really
is as bad as it appears to me as a user..

> That's why I moved over to embedded programming- working under the
> Windows structure takes all the fun out of hardware hacking.  Which
> brings us back on topic!  PICs don't have a protected mode, hurrah!

Hehe :-) I moved to embedded programming at the point where I realised
that I spend 95% of my time "just" on the GUI.  Embedded systems usually
have a lot less than that.. (not all though)

1999\03\24@155450 by paulb
flavicon
face
Barry King wrote:

> In Windows the exception handler can give the user a
> "This Application has performed an illegal operation..." Window.

 Yes, the annoyance being that it gives the user this window for
randomly chosen "legal" instructions as well! ;-)

> To get access to system hardware and especially interrupt function
> under Windows, you have to be a Device Driver.

 Obviously the *only* way to go.  Discussion as to whether this is
straightforward, difficult or simply not worth the effort, naturally
follows and various points of view will presumably be aired.

John Payson then wrote:

> Even pushing/popping the status register would cause such traps
> (whether or not the software made any effort to read/change the
> interrupt-enable bit within the stacked register);

 Which explains the above.

> some programs which happen to save/restore the status register a lot
> can end up running **REALLY** slow under Windows for that reason.

 Really slow or not at all, according to Windoze' "RND(Q)" function.

> Now, user software can set/ clear the interrupt enable in the main
> status register all it likes without any problem; ...if a thread has
> the interrupt enable flag cleared, the OS could decline to emulate any
> interrupts for that process).

 .. and does exactly that.  It interprets interrupt disabled as "if an
interrupt occurs, do something and don't tell me about it".  Cute!
--
 Cheers,
       Paul B.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...