Re: help number instruction
- To: mathgroup at yoda.physics.unc.edu
- Subject: Re: help number instruction
- From: Peter Whaite <peta at cim.mcgill.ca>
- Date: Sat, 02 Jul 1994 21:50:17 -0400
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?
> 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".