terry@csd.uwo.ca (Terry Cudney) (01/12/91)
Hi,
I have an input handler which follows the example in the RKM companion
disks (devices/input/inputswap.c & inputhandler.a). We can fiddle with
the input events here, no problem.
I want to send a signal from the handler to the main program using
Signal(), so that the main program can do some DOS stuff.
- The Task pointer (pointing to the main program) and a
pre-AllocSignal()-ed signal bitnumber are passed to the handler
in it's data area. (The data area isn't used otherwise, in this handler.)
So far so good. Using kprintf's to a serial terminal I know things
are getting passed OK. But el GURU visits as soon as the Signal() function
is called in the handler.
Question:
Can the Signal() function not be called from an input handler
to signal another process? If not, what other mechanism (without busy-waiting)
could tell the other process that a particular input event
(RAMIGA + ALPHABETIC KEY)? has occurred?
Any help will be greatly appreciated.
--
--terry
/* terry@chaplin.csd.uwo.ca
* Terry Cudney Amistosa MicroWare 9 Durham Street, LONDON, Ontario, N5Y 2H9
*/ccplumb@rose.uwaterloo.ca (Colin Plumb) (01/27/91)
terry@csd.uwo.ca (Terry Cudney) wrote: > Question: > Can the Signal() function not be called from an input handler > to signal another process? If not, what other mechanism (without busy-waiting) > could tell the other process that a particular input event > (RAMIGA + ALPHABETIC KEY)? has occurred? The input handler is a full task, so you can call any Exec function (excpet OpenLibrary() or OpenDevice() that might need to load from disk) from within it. And Signal() can be called from anything other than an NMI handler. So yes, it's quite safe. I don't know why your code is Guruing, but it's not because you've described any rule violations. Only suspiscion: are you calling Signal(task, signum) or Signal(task, 1<<signum)? The latter form is correct. If you use the dos.library's signal bit, icky things could happen the next time you make a Dos call. -- -Colin
markv@kuhub.cc.ukans.edu (05/05/91)
> I want to send a signal from the handler to the main program using > Signal(), so that the main program can do some DOS stuff. > - The Task pointer (pointing to the main program) and a > pre-AllocSignal()-ed signal bitnumber are passed to the handler > in it's data area.(The data area isn't used otherwise,in this handler.) > > So far so good. Using kprintf's to a serial terminal I know things > are getting passed OK. But el GURU visits as soon as the Signal() function > is called in the handler. Signal() is kosher in an interrupt. The trick is, if your handler is in C, and if you are in a small data addressing scheme, then your library base isn't automatically addressable by the handler. Under SAS, either: -compile the module with the handler with -y -use the __saveds keyword (I've had some problems mixing mulitple keywords on functions though) on the function. -call geta4(); as the first line of the function. This is isn't a problem with 32 bit absolute addressing. Speaking of near/far, in this example, things wouldn't be a problem if the library base pointer *itself* was far data, but I cant figure out in SAS the way to declare pointers with the far keyword to put the pointer storage itself far, I always get a pointer to a far object. On DOS I can do something like this: (assume Near data model is default): // sizeof(foo) = 2 far footype *foo; // foo is near ptr located in far data segment // sizeof(foo) = 4 footype far *foo; // foo is far ptr located in default DS // sizeof(foo) = 4 far footype far *foo; // foo is far ptr in far data segment. //OOPs, too much C++ ;-) But SAS croaks unless far comes after the type, which means always modifies the kind of pointer it is, not where it goes. Granted ANSI says modifiers must come after the type, but that makes it tough to do things like this. DOS compilers bend the rule, since esp. on DOS the three proceeding situations are quite different, and you may want all three. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dillon@overload.Berkeley.CA.US (Matthew Dillon) (05/06/91)
In article <1991May4.193801.30388@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >> I want to send a signal from the handler to the main program using >> Signal(), so that the main program can do some DOS stuff. >> - The Task pointer (pointing to the main program) and a >> pre-AllocSignal()-ed signal bitnumber are passed to the handler >> in it's data area.(The data area isn't used otherwise,in this handler.) >> >> So far so good. Using kprintf's to a serial terminal I know things >> are getting passed OK. But el GURU visits as soon as the Signal() function >> is called in the handler. > >Signal() is kosher in an interrupt. The trick is, if your handler is >in C, and if you are in a small data addressing scheme, then your >library base isn't automatically addressable by the handler. Under >SAS, either: > -compile the module with the handler with -y > -use the __saveds keyword (I've had some problems mixing > mulitple keywords on functions though) on the function. > -call geta4(); as the first line of the function. Also, look into software interrupts.. the Cause() function. This generates a software level interrupt that has a higher priority than tasks but a lower priority than interrupts, allowing an interrupt to get in, do its stuff, cause the software interrupt, and get out fast. Signal() and Cause() are both valid from an interrupt. PutMsg() and ReplyMsg() are also valid but if you can avoid them please do. Many cia resource calls relating to interrupts are valid. Most other functions are NOT valid. For example, AllocMem() and Wait() can NOT be called from an interrupt. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jsmoller@jsmami.UUCP (Jesper Steen Moller) (05/09/91)
In article <1991May4.193801.30388@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: > > > I want to send a signal from the handler to the main program using > > Signal(), so that the main program can do some DOS stuff. > > - The Task pointer (pointing to the main program) and a > > pre-AllocSignal()-ed signal bitnumber are passed to the handler > > in it's data area.(The data area isn't used otherwise,in this handler.) > > > > So far so good. Using kprintf's to a serial terminal I know things > > are getting passed OK. But el GURU visits as soon as the Signal() function > > is called in the handler. > > Signal() is kosher in an interrupt. The trick is, if your handler is > in C, and if you are in a small data addressing scheme, then your > library base isn't automatically addressable by the handler. Under > SAS, either: > -compile the module with the handler with -y > -use the __saveds keyword (I've had some problems mixing > mulitple keywords on functions though) on the function. > -call geta4(); as the first line of the function. This is correct. > This is isn't a problem with 32 bit absolute addressing. Speaking of > near/far, in this example, things wouldn't be a problem if the library > base pointer *itself* was far data, but I cant figure out in SAS the > way to declare pointers with the far keyword to put the pointer > storage itself far, I always get a pointer to a far object. On DOS I No, you get a pointer placed in the far section (absolute), and it _is_ a 'pointer to far object' as all other Motorola pointers are. > can do something like this: > (assume Near data model is default): > > // sizeof(foo) = 2 > far footype *foo; // foo is near ptr located in far data segment > > // sizeof(foo) = 4 > footype far *foo; // foo is far ptr located in default DS > > // sizeof(foo) = 4 > far footype far *foo; // foo is far ptr in far data segment. > //OOPs, too much C++ ;-) Oh, here we're talking 16 bit pointers versus 32 bit pointers. This is not an issue in Amiga declarations (in C, at least). The PC uses more types of pointers than I care to think about (near, far, huge???), while the Amiga uses a linear adress space pointer - simply a 32 bit number. The SAS near and far storage specifiers are exactly that: storage specifiers. They do not alter the type of the pointer (or whatever they're applied to), only where it's stored and how it's accessed. int far f; /* use absolute 32-bit addressing for references to 'f' */ int near n; /* use 16-bit refs toabsolute 32-bit addressing for references to 'n' */ /* I used ints to underline the fact that the 'far' keyword is in fact (on the Amiga, that is!) _only_ a storage specifier */ > But SAS croaks unless far comes after the type, which means always > modifies the kind of pointer it is, not where it goes. Granted ANSI No, only where it goes, as there is only one pointer: The 32 bit pointer. There can never be more than one instance of far in a declaration, and that will be after the type, because 'far' does not alter the type, only where it is stored. > says modifiers must come after the type, but that makes it tough to do > things like this. DOS compilers bend the rule, since esp. on DOS the > three proceeding situations are quite different, and you may want all > three. Sigh, I would need to be severely overpaid to program PCs. Long live Motorola. > -- > Mark Gooderum Only... \ Good Cheer !!! Greets, Jesper -- __ Jesper Steen Moller /// VOICE: +45 31 62 46 45 Maglemosevej 52 __ /// USENET: cbmehq!cbmdeo!jsmami!jsmoller DK-2920 Charl \\\/// FIDONET: 2:231/84.45 Denmark \XX/