eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) (08/02/89)
Tech Note #85 says that we should not disable interrupts from within an
application. There is an ominous admonition that "there will come a time
... when you won't be able to change the interrupt mask because the
processor is running in user mode." This may be putting me in a real
quandary, and it may be bad news for a lot of other people who are writing
hardware interfacing code.
I have been writing software to drive a data acquisition card sitting on
the Nubus in a Mac II. But my application requires the CPU to do high
speed uninterrupted polling of the card, sometimes for several seconds at
a time. It may be impossible to implement these routines with
interrupt-driven code, since the interval between service requests could
be as little as 5 microseconds. And an interrupt by someone else's code
(like a VBL task) could cause me to miss some data.
Note that the applications that I am working on (waveform synthesis and
precision event timing) are quite common jobs for laboratory
microcomputers. And remember that general purpose data acquistion boards
do not have much buffering or on-card intelligence. So there are lots of
other folks out there who are writing code that temporarily disables
interrupts. The following questions should be of interest to all of them:
What does Apple really mean when they say that the interrupt mask may
become inaccessible in some future System version, or on some future Mac?
My reading of the Motorola manuals indicates that applications running in
user mode will not be able to directly modify the interrupt mask in the
status register of a 680xx CPU. If applications must run in user mode,
will Apple provide a trap (or another mechanism) that will allow an
application to disable interrupts?
If not, what is the recommended way of doing uninterrupted I/O? I believe
that it is possible to turn off individual interrupt sources by flipping
bits in the Interrupt Enable registers of the VIA chip(s). But this
hardware is quite machine dependent - different Mac models have either 1
or 2 VIA chips, in different memory locations, and with different register
bit mappings. So the code would have to special case each computer that
it runs on, and might break on a future model.
Perhaps I am overlooking something obvious (wouldn't be the first time),
but I don't see a clean solution to this problem.
--
Julian Vrieslander
Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853
UUCP: {cmcl2,decvax,rochester,uw-beaver}!cornell!batcomputer!eacj
INTERNET: eacj@tcgould.tn.cornell.edu BITNET: eacj@CRNLTHRYtim@hoptoad.uucp (Tim Maroney) (08/03/89)
In article <8538@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: >Tech Note #85 says that we should not disable interrupts from within an >application. There is an ominous admonition that "there will come a time >... when you won't be able to change the interrupt mask because the >processor is running in user mode." > >I have been writing software to drive a data acquisition card sitting on >the Nubus in a Mac II. But my application requires the CPU to do high >speed uninterrupted polling of the card, sometimes for several seconds at >a time. I'm sure drivers will not be made to run in user mode; they will run in supervisor mode. Only applications (and possibly the user-interface drivers known as desk accessories) will be moved into user mode. Drivers need to have direct access to the hardware, device registers, interrupt mask, and all. So the answer to your problem is to move your i/o code out of your application and move it into a driver which is called by your application. This is a cleaner and more modular design anyway. Probably this should be in your Read routine, but possibly that won't be general enough for your needs. If so, you can always put it into your Control routine. >If applications must run in user mode, >will Apple provide a trap (or another mechanism) that will allow an >application to disable interrupts? Almost certainly not. >If not, what is the recommended way of doing uninterrupted I/O? I believe >that it is possible to turn off individual interrupt sources by flipping >bits in the Interrupt Enable registers of the VIA chip(s). A user-mode OS will likely also be a memory-protected OS, and user mode software will not have the device addressing spaces mapped into their address spaces. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Jesus died for somebody's sins, but not mine." -- Patti Smith
afoster@ogccse.ogc.edu (Allan Foster) (08/07/89)
In article <8538@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu (Julian Vrieslander) writes: >Tech Note #85 says that we should not disable interrupts from within an >application. There is an ominous admonition that "there will come a time >[...] >What does Apple really mean when they say that the interrupt mask may >become inaccessible in some future System version, or on some future Mac? >My reading of the Motorola manuals indicates that applications running in >user mode will not be able to directly modify the interrupt mask in the >status register of a 680xx CPU. If applications must run in user mode, >will Apple provide a trap (or another mechanism) that will allow an >application to disable interrupts? > >If not, what is the recommended way of doing uninterrupted I/O? I believe >that It seems to me that the driver that you are writing really should be an OS level task. I am sure there would be a way under the new systems to install a driver that would run in supervisor mode. That would solve half your problem. I however as another application on this machine would be very upset if I were not serviced for severasl seconds..... It seems the real solution to the problem is to do it in hardware... Get a board that can do DMA or has some sort of buffering on board so that it does not require the attention of the host CPU as much. Maybe putting a 68000 on the board with some ram would solve the problem quite nicely. If Mac is ever going to run as a protected memory virtual machine, then running in USER mode is a MUST. You do not own any hardware as a user process, only access to a virtual machine! Regards Allan Foster MicroPhone II Development Team -- Allan Foster UUCP : tektronix!ogcvax!afoster UseNet: afoster@cse.ogc.edu GEnie : A.FOSTER AppleLink : D1663 MacNet : FOSTER
eacj@batcomputer.tn.cornell.edu (Julian Vrieslander) (08/08/89)
In article <4111@ogccse.ogc.edu> afoster@ogccse.UUCP (Allan Foster) writes: >In article <8538@batcomputer.tn.cornell.edu> eacj@tcgould.tn.cornell.edu >(Julian Vrieslander) writes: >>Tech Note #85 says that we should not disable interrupts from within an >>application. >> ... >>What does Apple really mean when they say that the interrupt mask may >>become inaccessible in some future System version, or on some future Mac? >>My reading of the Motorola manuals indicates that applications running in >>user mode will not be able to directly modify the interrupt mask in the >>status register of a 680xx CPU. If applications must run in user mode, >>will Apple provide a trap (or another mechanism) that will allow an >>application to disable interrupts? >> ... >>If not, what is the recommended way of doing uninterrupted I/O? > >It seems to me that the driver that you are writing really should >be an OS level task. I am sure there would be a way under the new systems >to install a driver that would run in supervisor mode. I just received a note from someone else suggesting the same. I hope that this is true, since I was planning to rewrite my code as a driver anyway. >It seems the real solution to the problem is to do it in hardware... >Get a board that can do DMA or has some sort of buffering on board >so that it does not require the attention of the host CPU as much. We looked, to no avail, for a card flexible enough to handle our data acquisition tasks autonomously in hardware. We even thought about building a custom card, but that would require too much time. We can, however, do what we need with a simple GWI MacADIOS II card, and some custom interface code. But this code needs to run without being interrupted (and therefore, in supervisor mode). >If Mac is ever going to run as a protected memory virtual machine, >then running in USER mode is a MUST. You do not own any hardware >as a user process, only access to a virtual machine! The bottom line is that, after "opening up" the Macintosh hardware with the Mac II, Apple seems to be moving again in the direction of concealed, inaccessible hardware. I (sort of) understand the motives for this. But there are some folks who need to access low level hardware in order to implement unusual i/o tasks. Many of these applications, like mine, cannot be done with commercially available plug-and-run products. Apple execs may now see these applications as an inconsequential market compared to networked business and dtp systems. I really like working with Macs, but in the future, people like me may have to shop elsewhere for micros to run those "non-standard" data acquisition applications. >Allan Foster >MicroPhone II Development Team -- Julian Vrieslander Neurobiology & Behavior, W250 Mudd Hall, Cornell University, Ithaca NY 14853 UUCP: {cmcl2,decvax,rochester,uw-beaver}!cornell!batcomputer!eacj INTERNET: eacj@tcgould.tn.cornell.edu BITNET: eacj@CRNLTHRY