Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ptsfa!hoptoad!academ!uhnix1!nuchat!sugar!karl
From: karl@sugar.UUCP (Karl Lehenbauer)
Newsgroups: comp.sys.amiga
Subject: Notes on writing software interrupts
Message-ID: <356@sugar.UUCP>
Date: Fri, 3-Jul-87 03:55:14 EDT
Article-I.D.: sugar.356
Posted: Fri Jul  3 03:55:14 1987
Date-Received: Sun, 5-Jul-87 01:17:55 EDT
Organization: Sugar Land UNIX - Houston, TX
Lines: 32
Keywords: aztec interrupt bug

I have been working on getting "software interrupts on I/O completion" using
the audio device.  I have found that the system will guru under Aztec 3.40
if you write your interrupt routine in C, even if you are compiling
in super-portability mode (+p) and/or make a call to int_start() at the
start of your interrupt routine and int_end at the end as described in the
new documentation that came with the 3.40 release.  I have not tried this
using Lattice or with any devcies other than the audio device.

It appears that all of the registers used by the interrupt code are not
properly saved and restored by either of the methods given by Manx.
I was getting a line F emulation guru (illegal instruction) until I changed
my calls to int_start and int_end to the following in-line assembly:

InterruptRoutine()
{
#asm
	movem.l d0-d7,a0-a7,-(sp)
#endasm

... body of interrupt routine ...

#asm
	movem.l (sp)+,d0-d7/a0-a7
#endasm
}

This is a brute force hack.  I haven't figured out what group of registers
represents the minimal set.  Does anyone else know?

Also, note that the Aztec direct-i/o-to-the-serial-port debugging subroutines
(such as mprintf, kputchar, kputs) can be called from within the software
interrupt.