IamRob wrote:
I take it that DUMP and SEE don't use FIND to find a word, since the word cannot be found when the SMUDGE bit is on, correct?
As Garth said, DUMP takes an address and count from the data stack and performs a memory dump.
SEE does use find. In my post on
SEE , I mentioned in my fifth point that I define SEE as this:
Code:
: SEE ' (SEE) ;
' ( pronounced tick) uses find to find the next word in the text stream and leaves the address on the stack ( or aborts if the name is not found) . (SEE) takes the address of a word's code field and decompiles that word. LATEST will return the address of the name field of the latest word defined ( in that vocabulary ) regardless of whether it's smudged. With the above definition of SEE, you could type
Code:
LATEST NAME> (SEE)
To examine the body of the latest word defined even if it's smudged. It's also helpful if SEE is factored into useful components such as
:DIS . When given the address of a section of threaded code ( such as in the body of a colon definition ) where the address is lined up on one of the words that make up this section of threaded code,
:DIS will decompile the code at that point on. For this example I left the number base set to DECIMAL .
Code:
SEE FIND
FIND
8045 2638 CONTEXT
8047 4903 @
8049 2841 (FIND)
8051 5177 ?DUP
8053 2436 ?EXIT
8055 2652 CURRENT
8057 4903 @
8059 8034 VFIND
8061 2406 EXIT
18
OK
8051 :DIS
8051 5177 ?DUP
8053 2436 ?EXIT
8055 2652 CURRENT
8057 4903 @
8059 8034 VFIND
8061 2406 EXIT
12
OK
If not lined up
Code:
8050 :DIS
8050 14603
8052 33812
8054 23561
8056 9994
8058 25107
8060 26143
8062 25609
14
OK
You get the idea.
:DIS can come in handy if the smudged word has a section that is so badly messed up that SEE can not correctly decompile it at that point and you have to try an address and resume decompiling there.
That is how, with right tools, you can SEE a word that has been smudged.