Re: help number instruction

*To*: mathgroup at yoda.physics.unc.edu*Subject*: Re: help number instruction*From*: withoff (David Withoff)*Date*: Sun, 3 Jul 1994 19:57:42 -0500

> David Withoff says: > > > The list of pseudo-code instructions is the third element in this > > result. Here is an analysis of those instructions. > > > > In[11]:= f[[3]] //ColumnForm > > > > Out[11]= {1, 17} (* verify the version *) > > {3, 1, 0} (* load integer argument at position 1 into > > integer register 0 *) > > {12, 10, 1} (* load the integer constant 10 into integer > > register 1 *) > > {32, 0, 1, 2} (* add integer register 0 to integer register 1 > > and put the result in integer register 2 *) > > {7, 2} (* return the result in integer register 2 *) > > > > The error happens at the fourth instruction, {32, 0, 1, 2}, where > > the argument is added to the constant 10. > > ... > > In most cases, figuring out these messages by poring over lists of > > pseudocode instructions is sort of tedious. > > Which is of course why people use disassemblers to aid them. From the above > example it looks like this wouldn't be too hard. Does one exist? Try the following item on MathSource. 0205-928: Decompiling Compiled Functions (November 9, 1993) Author: Terry Robb Decompile[compiledFunction] decompiles a compiled function and returns a Function that would evaluate exactly the same as if the pseudocompiler were executing op codes. This is useful for seeing how the pseudocompiler works. A simple example is Decompile[Compile[x, x*Exp[x]]]. Registers named rB, rI, rR, and rC are used for holding boolean, integer, real, and complex datatypes. These registers can be traced using On[rI, rR] etc. 0011: Decompile.m Mathematica package (November 9, 1993; 8 kilobytes) > > It is usually easier to look at the code and think deep thoughts about > > whether or not the compiled program can be handled using machine-sized > > quantitites, whether or not there are square roots of negative numbers, and > > so forth. > > Which is all well and good, but deep thoughts can be elusive at times, and > more so as the function gets longer. Really, as others have found, its much > easier to put a little debugging information in the code, e.g. > > f = Compile[{{x, _Integer}}, x + 10, Debug->True] > > so when one disassembles it you get to see the source code corresponding to > the "machine" instructions. > > BTW arithmetic things like overflow usually generate an exception, so why cant > these be trapped to give a more informative message than "Numerical error". These are both good suggestions. Both are non-trivial to implement in a useful way, but it is certainly possible. Dave Withoff Research and Development Wolfram Research