Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!sdd.hp.com!cs.utexas.edu!uunet!mcsun!hp4nl!cbmnlux!cbmehq!cbmdeo!jsmami!jsmoller From: jsmoller@jsmami.UUCP (Jesper Steen Moller) Newsgroups: comp.sys.amiga.programmer Subject: Re: Can you use Signal() from an input handler? Message-ID: Date: 9 May 91 01:56:27 GMT Followup-To: comp.sys.amiga.programmer Organization: Danish SofTech Lines: 87 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/