dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/09/87)
There are two EXEC calls, AllocTrap() and FreeTrap(). The manual page states that they can be called "only from the currently running task"... Does this mean that each task gets its own set of traps? None of the manuals state how one goes about setting a trap vector once one has allocated it. Can I write directly to the vectors in low RAM? -Matt
scotty@l5comp.UUCP (Scott Turner) (05/10/87)
In article <8705082331.AA16155@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > There are two EXEC calls, AllocTrap() and FreeTrap(). The manual >page states that they can be called "only from the currently running >task"... Does this mean that each task gets its own set of traps? > > None of the manuals state how one goes about setting a trap vector once >one has allocated it. Can I write directly to the vectors in low RAM? > > -Matt Each task has it's on field for recording which traps have already been handed out for THAT task. NO!!!! You NEVER EVER EVER EVEN THINK of touching those vectors! If C-A had used the 68010 CPU then everyone could have their own private set of exception vectors to dink with (I like the VBR, thanks Motorola!). They didn't so we don't. What we have instead is the ol trap handler hook in the task record. You hook a handler into here and this handler then decodes a number that will be passed to it whenever a trap opcode is executed. This routine will also be called for the other "naughty" traps as well, like TRAPV, CHK, div by 0 etc... If you expect to continue using your debugger then your handler should save the address it found in the task record. Whenever it gets a trap # outside the ones it deals with, like a div by 0, it should pass it along to the original handler so that your debugger will still be useful. TDI didn't do this and as a result it's a real chore to rip into one of their M2 codefiles with MetaScope. Also, note that if you wish to deal with ALL exceptions (to beat Mr. Guru out of his due :-) inside your program you will HAVE TO DEAL WITH 010 and 020 issues! The good ol' boys at C-A pass us the exception frame just the way it came from the CPU. So your handler must check the CPU flags in execbase if it intends to cleanup the stack and continue execution after a blowup. Also note that due to all the overhead traps shouldn't be used for time intensive things. Using TRAP #0 to read a character from the serial port is a sure way to slow yer Amiga down. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)
jmsynge@sqm.dec.com (James M Synge, DTN 381-1545) (05/10/87)
> There are two EXEC calls, AllocTrap() and FreeTrap(). The manual > page states that they can be called "only from the currently running > task"... Does this mean that each task gets its own set of traps? My understanding is that the trap code pointed to in your task data structure is the code that is called to handle any trap that occurs while your task is executing. It is not very clear what the purpose of AllocTrap() and FreeTrap() is. It may be for allocating the TRAP instruction trap values. > None of the manuals state how one goes about setting a trap vector once > one has allocated it. Can I write directly to the vectors in low RAM? I think the answer is NO. Write your trap handler and enter it in your task structure, not in low RAM. James Synge USENET: {decvax, ucbvax, allegra}!decwrl!sqm.dec.com!jmsynge ARPAnet: jmsynge%sqm.DEC@decwrl.DEC.COM #include <disclaimer.h> "Ken Olsen can speak for Digital, not me!"