rosen@mtgzz.UUCP (05/11/87)
Someone wrote me mail asking:
I read your response to the guy trying to trap
ctrl-C's. Can the signal() function be used to
trap hardware interrupts? Have you seen any go
software to do this (for MSC 4.0)?
I answered:
According to the MSC manual signal() can only be used to trap for SIGINT
(ctrl C) or SIGFPE (floating point exception). It seems to me all
interrupts are the same (hardware and software) so I don't know why
MSC only handles 2 of them. I suppose to catch other interrupts you
can use the type of code the other fellow was writing for ctrl C. That
is, replace the interrupt vector or chain to it.
Does anyone else have any opinions/suggestions. I once had to chain to a
hardware interrupt. I wrote some general purpose C routines, and an assembly
program callable from C that will let me chain any C routine to any interrupt
vector. Is there a better way?
--
Tom Rosenfeld @ AT&T Information Systems Labs, Middletown, NJ
(201) 957-5867
UUCP: {harpo,ihnp4,burl,akgua}!mtgzz!rosen
Disclaimer: I don't claim anything.perry@omepd.UUCP (05/12/87)
In article <2681@mtgzz.UUCP> rosen@mtgzz.UUCP (Tom Rosenfeld) writes: >According to the MSC manual signal() can only be used to trap for SIGINT >(ctrl C) or SIGFPE (floating point exception). It seems to me all >interrupts are the same (hardware and software) so I don't know why >MSC only handles 2 of them. ... MSC makes a real effort to give the programmer as much of a UNIX-like system interface as possible in MS-DOS. In fact, they claim that provided you follow reasonable guidelines, your object modules are binary compatible between MS-DOS and XENIX. Thus, the signal() function must provide UNIX-style functionality. If you check the list of UNIX signals, you'll see that only SIGINT and SIGFPE make much sense under MS-DOS. The UNIX signal() function cannot be used to intercept hardware interrupts (heaven forbid!). Thus, MSC signal() can't either. I for one am quite happy with the UNIX-interface approach of MSC. It makes porting C program so much easier... ------------------------------------------------------------------------ << Perry The Cynic >> =>> perry@inteloa.intel.com <<= ...!tektronix!ogcvax!omepd!inteloa!perry (Peter Kiehtreiber) ...!verdix!omepd!inteloa!perry
mac@uvacs.CS.VIRGINIA.EDU (Alex Colvin) (05/13/87)
In article <2681@mtgzz.UUCP>, rosen@mtgzz.UUCP writes: > Someone wrote me mail asking: > ctrl-C's. Can the signal() function be used to > trap hardware interrupts? Have you seen any go > software to do this (for MSC 4.0)? > Does anyone else have any opinions/suggestions. I once had to chain to a > hardware interrupt. I wrote some general purpose C routines, and an assembly > program callable from C that will let me chain any C routine to any interrupt > vector. Is there a better way? The numbers defined for SIGINT and SIGFPE have no relation to real interrupts on the PC. This suggests that this mechanism can't be extended to other interrupts. All the interrupt handling code I've seen for MSC is in assembler. In some cases it sets up a stack and calls C code. There's no documentation about this, and I suspect you're taking your chances. System library routines (including Floating Point) are often not re-entrant. Be especially ware of anything involving allocation. Personally I prefer CII's C86, which supports this stuff, albeit clumsily.
mac@uvacs.UUCP (05/14/87)
> MSC makes a real effort to give the programmer as much of a UNIX-like system > interface as possible in MS-DOS. In fact, they claim that provided you follow > reasonable guidelines, your object modules are binary compatible between > MS-DOS and XENIX. Thus, the signal() function must provide UNIX-style > functionality. If you check the list of UNIX signals, you'll see that only > SIGINT and SIGFPE make much sense under MS-DOS. The point of using the names SIGINT and SIGFPE is to avoid depending on their numeric values. If MS had been careful they could have defined these values and the signal function to handle other interrupts. Instead they chose object code compatibility. > The UNIX signal() function cannot be used to intercept hardware interrupts > (heaven forbid!). Thus, MSC signal() can't either. I for one am quite happy > with the UNIX-interface approach of MSC. It makes porting C program so much > easier... The UN*X fork() function can be used. The MS-DOS can't. Porting code doesn't always work. Maybe MS should have produced a compiler for MS DOS.