From: Martin A. <ma...@at...> - 2001-05-10 22:31:50
Attachments:
patch-20010510-disassem.diff.gz
|
Hi, attached is a port of Tim Moore's improved disassembly patch on cmucl-imp 2001-05-07. "... They annotate the disassembly listing with values of code constants, foreign functions, and variables referenced by the code. ..." [I borrowed a very small portion of my patch for *COMPILER-TRACE-OUTPUT* (deleted one character in #'PRINT-NOTES-AND-NEWLINE in compiler/target-disassem), to get rid of an unnecessary semicolon in the commented output. So, if you apply both patches, don't be confused.] -- Martin Atzmueller <ma...@at...> |
From: Brian D. <bdo...@la...> - 2004-06-20 09:14:42
Attachments:
disassemble.diff
|
This is a patch I came up with quite a while ago for DISASSEMBLE. SBCL's DISASSEMBLE has the problem that it usually only starts at the "; No args parsing point". This is caused because, unlike CMUCL, SBCL makes different names for some segments of the code, like: "XEP for FOOBAR::NUTS". The CMUCL DISASSEMBLE code had a name check before it started disassembling. With the more descriptive names, SBCL was failing these checks until it got to the function proper. I just removed the name check. Everything still seems to disassemble okay, and you can see the function entry and args parsing code, which can be terribly important at times. -bcd -- *** Brian Downing <bdowning at lavos dot net> |
From: Alexey D. <ade...@co...> - 2004-06-21 16:04:51
|
Hello, Brian Downing <bdo...@la...> writes: > This is a patch I came up with quite a while ago for DISASSEMBLE. > SBCL's DISASSEMBLE has the problem that it usually only starts at the > "; No args parsing point". > > This is caused because, unlike CMUCL, SBCL makes different names for > some segments of the code, like: "XEP for FOOBAR::NUTS". The CMUCL > DISASSEMBLE code had a name check before it started disassembling. With > the more descriptive names, SBCL was failing these checks until it got > to the function proper. Thank you for the investigation. But the patch does not seems to be not completely correct: for (locally (labels ((twos (n) (declare (type (integer 0 1000) n)) (if (zerop n) nil (cons 2 (threes (1- n))))) (threes (n) (declare (type (integer 0 1000) n)) (if (zerop n) nil (cons 3 (twos (1- n)))))) (setf (fdefinition 'twos) #'twos (fdefinition 'threes) #'threes))) (DISASSEMBLE #'TWOS) outputs the XEP of #'THREES. -- Regards, Alexey Dejneka "Alas, the spheres of truth are less transparent than those of illusion." -- L.E.J. Brouwer |
From: William H. N. <wil...@ai...> - 2001-05-19 20:35:00
|
On Fri, May 11, 2001 at 12:31:09AM +0200, Martin Atzmueller wrote: > attached is a port of Tim Moore's improved disassembly patch > on cmucl-imp 2001-05-07. > > "... They annotate the disassembly listing with values of code > constants, foreign functions, and variables referenced by the code. ..." Thank you. I merged it, spent some time admiring the pretty output from (DISASSEMBLE 'PRINT) and (DISASSEMBLE 'SORT) and whatnot, and checked it in as sbcl-0.6.12.9. I'll look at your "logical pathname patch & readable hashtables" patch next, then see about restoring compiler trace output. -- William Harold Newman <wil...@ai...> "As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database." -- http://mindprod.com/unmain.html PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |