ahinds@hvrunix.UUCP (Alexander Hinds) (02/19/88)
Could anybody please tell me what order Exec pushes what registers onto the stack right before it calls your interrupt service routine? (It frees a1...?? to use as scratch.) I need access to this data, and any help would be greatly appreciated. The RKM's don't give the whole story. I thank you in advance. Alexander Hinds USENET:ahinds@hvrford BITNET:A_HINDS@HVRFORD
dillon@CORY.BERKELEY.EDU (Matt Dillon) (02/21/88)
> Could anybody please tell me what order Exec pushes what registers >onto the stack right before it calls your interrupt service routine? (It frees >a1...?? to use as scratch.) I need access to this data, and any help would >be greatly appreciated. The RKM's don't give the whole story. I thank you in advance. > Absolutely not! DON'T!!! WRONG! You can trace the ROM code if you want, but under no circumstances should you make assumptions as to what the interrupt tag code does! When your interrupt service routine is entered, the following is all you know: D0 -scratch D1 -scratch A0 -scratch A1 -server data segment pointer on call, scratch on return A5 -scratch A6 -EXEC library base pointer on call, scratch on return D2-D7/A2-A4 -must be preserved by your interrupt handler. Where the server data segment pointer is the one defined in the Interrupt structure for that interrupt. The interrupt service routine should return with an RTS. Obviously the tag code has saved D0/D1/A0/A1/ A5/A6, but what possible reason could you have for wanting the original contents? At the point your interrupt service routine is entered, the previous state could have been *anything*. This is the Amiga. Let us not get into the habit of using hardcoded addresses and offsets that delve into the internals of the OS! -Matt
itkin@stsci.EDU (Elliot Itkin) (02/22/88)
in article <8802210745.AA20230@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) says: [in response to a question about the previous stack contents and what the exec pushes there] > A5/A6, but what possible reason could you have for wanting the original > contents? I can think of one real quick - A performance analyzer. Generate an interrupt every n milliseconds and in your interrupt code just record the PC of what you interrupted. Save this in memory and write out to disk whenever memory is full. If you do it right it should take very little CPU out. Afterwards, you run the raw PC list though an analysis program that converts the absolute PCs into more meaning information (that's the hard one to write). This way you can discover many things that you could only guess at before. This is an especially useful tool for large complex software systems (especially real-time ones) where the place that is eating CPU cycles is completely unknown. Please answer the question so that this can be built. An Amiga tool this powerful (could the analysis program read your executable and object files when producing its report? A super-duper one could read your source files and tell you how often particular lines of code were executed!!!) WOW golly gee. I hope this is what the info is wanted for, but it probably is to produce a super-duper pirater or something. -- Elliot S. Itkin Space Telescope Science Institute, Baltimore, MD 21218 UUCP: {arizona,decvax,hao,ihnp4}!noao!stsci!itkin ARPA: itkin@stsci.edu SPAN: {SCIVAX,KEPLER}::ITKIN
haitex@pnet01.cts.com (Wade Bickel) (02/22/88)
ahinds@hvrunix.UUCP (Alexander Hinds) writes: > > Could anybody please tell me what order Exec pushes what registers >onto the stack right before it calls your interrupt service routine? (It frees >a1...?? to use as scratch.) I need access to this data, and any help would >be greatly appreciated. The RKM's don't give the whole story. I thank you in advance. > > Alexander Hinds I too am interested in exactly what goes on at this level in the OS. If anyone responds to this posting (which I kind of doubt) would you please post or send me E-Mail? Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM