Fresh Fish 5

home *** CD-ROM | disk | FTP | other *** search

/ Fresh Fish 5 / FreshFish_July-August1994.bin / bbs / util / isan-1.2.lha / ISAN-1.2 / README < prev next >

Wrap

Text File | 1994-05-22 | 10.0 KB | 253 lines

**************************************************************************** * * * Conditions of use ISAN 1.2 * * ----------------- -------- * * * * This program has been provided for the enjoyment of the masses. * * It is FREEWARE, but not Public Domain. * * Since the author doesn't ask for anything in return, the user * * will accept the following conditions: * * * * 1) In no case whatsoever shall the author be liable for any * * damages, losses etc... due to the use of this program. * * 2) Distribution of the program is only allowed subject to the * * following restrictions: * * * * 2.a) No file part of this distribution will be omitted or * * modified in any way. * * 2.b) None of the files which are part of this distribution * * should be stored on environmentally unfriendly media. * * (e.g. paper! (listings, faxes)) * * * * Laurence Vanhelsuwé * * 08-MAR-94 * * * **************************************************************************** Program Title : ISAN (Instruction Stream ANalyzer) (Version 1.2) -------------------- Author : Laurence Vanhelsuwé ---------------------------- 0. Short description ----------------- ISAN Allows you to monitor a Task's machine code and register usage... in real time ! 1. Requirements/Installation: -------------------------- ISAN Is Kickstart 1.3 compatible. ISAN Only works on 68020 and upwards machines. If you run ISAN on a machine with a 68000 or a 68010 it should refuse to do any useful work gracefully. ISAN Needs one run-time configuration file; the default is called "ISAN.config". This configuration file should be located in the S: directory or in the current directory when ISAN is invoked. 2. How to use it: -------------- ISAN is used to collect machine instruction statistics of any Task (or Process) currently running on the machine. It allows you to snoop on a RUNNING task and find out which instructions it is using ... in real-time ! Since the 680x0 potentially has 65536 different instructions (opcodes are 16-bit words) it's impractical to somehow show 65536 different bargraphs or counters for each possible word. (but see option GRAFMAP for an alternative, nevertheless). Therefore, you provide ISAN with a list of opcodes that you are interested in. You can specify unique opcodes (like $4E75 for RTS) or an opcode template with a mask defining "don't care" bits. For example $7000 as the template and $0EFF as the mask encompasses ALL possible MOVEQ instructions. Have a look at the supplied ISAN.config files for some examples. ISAN Allows you to analyze the instruction stream in two ways: - MODE 1 traces every single instruction of a Task - MODE 2 traces only instructions which cause a change of program flow (branches, jumps, ..) This feature is a direct mapping from the 68020+ dual-mode CPU TRACE capability. The slider gadget at the right of the window determines the update speed of the graphs. The higher the slider, the higher the update speed. The slowest update speed gives an update every 2.5 seconds approximately. Clicking inside the window will reset the counters. A full syntax template is produced when passing a "?" as the only command line argument: ISAN ? Internally ISAN uses a (built-in) clone of the 2.0 ReadArgs() routine to parse the command line arguments in a flexible and consistent manner (this gives 1.2/1.3 users the uniformity of command line templates that 2.0 users are blessed with). 3. What can you do with ISAN ? --------------------------- Obviously you need a reasonable knowledge of assembler and/or the 680x0 microprocessors to get the most out of this system utility. You can for example easily work out whether a program is derived from lean, mean assembler or just from lazy, overweight 'C'. You can also find out whether the program uses the extra instructions and/or addressing modes of the 68020+ CPUs or 6888x FPUs. You could also possibly detect viruses by spotting strange program behavior as reflected by strange instruction usage (the example ISAN.config file has an entry to spot short absolute JSRs... there's no way a normal program should ever do this; only a virus hiding in very low memory (<32K) might use this to conserve code space...). Basically you can find whether a program uses a certain instruction or group of instructions frequently and if so exactly how many times etc... Using the TOTAL switch you can also learn more about your computer and go "Geee ! That many instructions for a stupid keypress ?!". (The days of a Commodore 64-type OS are definitely over... sniff) Etc... 4. Internals: ---------- ISAN Works by allocating 65536 counters. One ULONG per possible 680x0 opcode. It just adds a TRACE exception (trap) handler to the target Task and enables T1 or T0 in the SR copy of the Task in its saved context. The handler just grabs the Instruction Pointer (IP) from the exception stack frame, picks up the word pointed to by that IP and increments the LONG counter associated with that word (=instruction). So basically you've got 256K of counters RAM which is updated by the Task itself (not ISAN!); while ISAN just lazily sits there picking up selected counters specified by your list of opcodes and updates the graphs window accordingly. Note that turning the update speed up to its maximum will only give you smooth(ish) evolution of frequencies if the Task being analyzed has a task priority lower or equal to that of ISAN (which is normally 0 if your parent Shell hasn't changed the default by doing a settaskpri). If you analyze tasks like input.device or scsi.device which both have priorities higher than ISAN's then the updating will be jerky because ISAN doesn't get a chance to make quick "snapshots" of the frequencies while the task is running. This is of course due to the higher priority Task blocking ISAN from getting a time slice (logical isn't it ?!). (This explanation is just for those who might think that ISAN is screwing up at high update speeds or something like that! No so.). When the register option is used you'll find that the PCs of most Tasks don't do much. This is not a bug and is again due to the multi- tasking nature of the Amiga. Tasks which are CPU bound (constantly READY, not WAITING) do have PCs which will change frequently in ISAN's register output window. 5. ISAN Limitations/Warnings: -------------------------- !CRASH! - Make 300% sure the Task being traced doesn't exit (disappear) BEFORE ISAN quits ! ISAN 1.0 Has no reliable way of knowing whether the Task vanished from under its nose or not (the Task TCB might be deallocated and then a new Task started with a new TCB in exactly the same spot!). The safest way to go about things is to do a NEWCLI and trace that newly created Shell in which you can start your program that you want to analyze. The only downside is that you'll get some garbage readings from the CLI process itself just prior to your program taking over the Shell. This is of course because the CLI has to load and start the program. !CRASH! - Since ISAN 1.0 adds a trap handler via the TC_TRAPCODE vector, programs which make use of the following 680x0 traps will not work correctly: - Bus Error - Address Error - Illegal instruction - Zero divide - CHK - TRAPV, TRAPcc - TRACE (! That's the one I use) - Line $A opcodes - Line $F opcodes To be more precise programs will fail if these traps are generated; thus CHK and TRAPV instructions cause no problem as long as they don't fire. Normally all these traps give you a "Software Failure" requester anyway, I anticipate problems only when looking at compiled HLL code with run-time array bounds or arithmetic overflow checking on. - If you specify a huge list of opcodes you want to snoop on, ISAN might not be able to list them all in a Window (due to the Workbench Screen having a finite height), so it refuses to open its window and returns an error. (a slider gadget to scroll through a huge list would be better - maybe for version 1.1). - ISAN 1.0 can't look beyond the opcode (the first word). So you can't find out if a program uses specific arguments in the extra words. Arguments encoded in the opcode itself are of course possible. E.g. in MOVE.W #$BEEF,d0 the immediate operand $BEEF is stored in an extra word after the opcode. ISAN has no way of snooping beyond the opcode, in other words you can't ask ISAN to find MOVEs with immediate operands of xxxx. - Since ISAN works by enabling the TRACE mode of the target Task (and not much more), if a Task is READY all the time (not in the Wait()ing queue), then the WHOLE system will get very jerky and slow because of the trace exceptions going off all the time. Apart from doing fancy re-scheduling in the TRACE exception handler there's not much you can do about this. - When specifying opcode groups (templates) you should know that the more "don't care" bits, the more work ISAN will have to do to find all the possible opcode combinations. For example if your don't care mask contains just 5 set bits, then ISAN will have to find 2^5 = 32 unique opcode counters. For every update pass ISAN freezes multi-tasking to get a consistent view of the counters array (a "snapshot"). Keep masks reasonable otherwise multi-tasking might get disabled for too long (resulting in jerky pointer movement ... at least)! 6. Changes from previous versions: ------------------------------- 1.2: - Added simplistic PROFILE option. Added FILE option to use files other than S:ISAN.config 1.1: - Added option to display Task regsisters in seperate window. - Optimized TRACE handlers to use memory indirect addressing modes (which in turn allowed me to optimize the save/restore sequences). 7. Credits: -------- Any comments, ideas or bug reports? My name and address are: Laurence Vanhelsuwé Christinastraat 105 B-8400 Oostende Belgium Enjoy !