SEE is defined on some Forth systems to reconstruct ( or try to reconstruct) the source of a Forth word. This seems to me to be a cute parlor trick, especially if the Forth source is readily available.
I feel that SEE can be a useful tool if, instead of attempting to show the source of a Forth word, it shows what actually got compiled. Here are my criteria for a useful SEE:
1 Display what was compiled for Forth words and code words.
2 Recognize the built in data types ( VARIABLE , CONSTANT , 2VARIABLE , 2CONSTANT , and USER ) and display their values.
3 Display a DEFERed word's vector ( the word a DEFERed word is set to execute) .
4 Transition seamlessly from decompiling/disassembling High level code to Low level and back. For example:

Notice that in these examples DOES , the primitive compiled by DOES> and ;CODE , sets the code field of the latest word in the current vocabulary to point to the code following DOES and exits. These defining words do not transition from high level code to low level, but the decompiler does.
5 SEE is just a wrapper word for (SEE) so (SEE) can take a CFA from the data stack.

6 Know when to stop decompiling and when, or if, it should transition from high or low level to the other.
7 Defined with helper words :DIS and DIS that decompile : ( colon) definitions and code definitions respectively. In some situations, the ones that 'trip up' SEE , it is useful to decompile a Forth word starting on a word boundary, inside the body of the definition, with :DIS ,or disassemble a low level word starting on an instruction boundary, with DIS . This example is a partial disassembly of FIND , the high level word that uses (FIND) and VFIND , the find primitives.

The full disassembly of FIND for comparison:

8 A word like DONE? is included in the definition of the decompiler(s) which can pause the listing and wait if a key is pressed or return with a flag. It is possible SEE will encounter a situation that makes it keep decompiling because none of the stop criteria are met, especially if it's used to examine the code of a new construct like DOER/MAKE .

DONE? is used like this:

The loop in SOME.FORTH.WORD keeps running until the test condition is true or the C64's STOP key is pressed ( DONE? returned a TRUE, we're done. If any other key is pressed, DONE? will wait for a key press. If the stop key is pressed, a TRUE flag is returned, otherwise FALSE is returned.

A SEE written with these criteria in mind, along with DUMP , a word to display memory contents, can be a useful tool when performing a 'postmortem' after an attempt to add some new feature to one's Forth fails.

Cheers,
Jim

You got pretty ambitious there, doing disassembly too! My SEE doesn't do that, but I did have it show more information. SEE has the following line in its definition to print a heading above a table of the decompiled word's contents:

The hex ±hex dec ±dec part is to show the cell contents in signed and unsiged hex and decimal, in case the cell is numerical data rather than the CFA of a word. The ASCII part is of course for if it's part of a string. Above all that, it prints the name of the word, whether or not it's IMMEDIATE, and then its NFA, LFA, and CFA. I can't remember the last time I used it though.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The last time I used SEE was to make sure the DOER/MAKE words compiled the right stuff.
With my mixing of high level and assembly code, it's good to have SEE able to decompile/disassemble both.
I took a tip from Charles Moore and don't let SEE mess with BASE. In my SEE , I used unsigned numeric display in the current base. My examples show HEX used, but it works just as well in decimal. To maintain proper spacing, I use 16BITS .R and 8BITS .R as appropriate.

SEE's components include SETWIDTH.

A useful change to my SEE is to include the address of the words that form a high level definition. Some words may be headless and some names may be in more than one vocabulary. Including the address is one sure way to know which word is used. Here is a disassembly of PLISTS , plain lists. It lists a range of blocks plainly ( no line numbers and no blank lines within a screen ).

The address of I , $0FEC, shows that it is in the kernel and is therefore the I defined in the FORTH vocabulary, not the I ( short for insert) defined in the EDITOR vocabulary.
There is one other thing. I was wondering how the formatting looks. Particularly when the disassembly transitions from high level to low and vice versa.

Cheers,
Jim

I've given that second criterion some thought and simplified my SEE . It still has the same features for high level and code decompiling/disassembling, but SEE now tests for the following types:
1 code words -- disassemble as before
2 high level words -- decompile as before
Both still transition between code and high level as needed.
3 deferred words -- show what the 'action' is but don't disassemble it. Show its name and address of its CFA.
4 All others are assumed to be CREATE DOES> or CREATE ;CODE words.
For these words it finds the size of the PFA.
A) If it is zero, disassemble the code pointed to by the CFA.
B) If it is not zero, show the name of the word which sets this word's code field and the address pointed to by the CFA. show the address and size of the PFA.

Here is a sample session:

And some deferred words:

Do you mean an inline string literal as in the string following ABORT" in this definition?

Or even this?

Here is what they look like when decompiled:

In TaliForth2 (an STC Forth that supports native compiling (inlining) of short words), that's extra important. Short words often have their assembly "native compiled" (eg. copy/pasted, similar to inlining or using a macro) into the word being compiled, but long words are compiled as a JSR. This results in a mix of assembly and JSRs to words. Here's a quick example:

Code:

: square dup * ." The answer is " . ;  ok
5 square The answer is 25  ok

Code:

see square
nt: 800  xt: 80E
flags (CO AN IM NN UF HC): 0 0 0 1 0 1
size (decimal): 51

080E  20 0A D8 CA CA B5 02 95  00 B5 03 95 01 20 0F D8   ....... ..... ..
081E  20 D7 A5 E8 E8 4C 34 08  54 68 65 20 61 6E 73 77   ....L4. The answ
082E  65 72 20 69 73 20 20 8A  A0 26 08 0E 00 20 DE A4  er is  . .&... ..
083E  20 26 8C   &.

80E   D80A jsr     STACK DEPTH CHECK
811        dex
812        dex
813      2 lda.zx
815      0 sta.zx
817      3 lda.zx
819      1 sta.zx
81B   D80F jsr     STACK DEPTH CHECK
81E   A5D7 jsr     um*
821        inx
822        inx
823    834 jmp
834   A08A jsr     SLITERAL 826 E
83B   A4DE jsr     type
83E   8C26 jsr     .

My version doesn't print out strings, but it does give you their address and length in case you want to TYPE them. Many of the built-in words have a stack depth check before they run (which can be inhibited from being compiled into new words if you want to save a few bytes when compiling known good source code). After that, you can see the assembly for DUP because it was short enough to inline, the code for * was also inlined (stack depth check, then um*, then two INX instructions to DROP the upper half of the double result from um*). The literal string data from ." is skipped over, but then SLITERAL puts the address and length on the stack and TYPEs it, and finally . is compiled directly as a JSR because it is too long to be inlined here.

This notion of having SEE show "what was actually compiled" is very important in Tali because if I disable inlining completely by setting nc-limit (native compiling limit) to zero, I get:

Code:

0 nc-limit !  ok
: square dup * ." The answer is " . ; redefined square  ok
see square
nt: 842  xt: 850
flags (CO AN IM NN UF HC): 0 0 0 1 0 1
size (decimal): 36

0850  20 9F 8D 20 3B A1 4C 67  08 54 68 65 20 61 6E 73   .. ;.Lg .The ans
0860  77 65 72 20 69 73 20 20  8A A0 59 08 0E 00 20 DE  wer is   ..Y... .
0870  A4 20 26 8C  . &.

850   8D9F jsr     dup
853   A13B jsr     *
856    867 jmp
867   A08A jsr     SLITERAL 859 E
86E   A4DE jsr     type
871   8C26 jsr     .
 ok

The string and . are handled the same, but you can now see DUP and * were just compiled as JSRs.
That's a pretty good list. Tali's SEE does the seamless high/low level code thing, but it really has to because Tali is an STC forth. I recently added recognition of strings because the disassembler was gacking on them (didn't know to skip over the data and tried to disassemble the string), but decided to just print the address and length of the string because I can always use a TYPE command if I need to see the string - also Tali includes a DUMP of the word and the string data is visible there if it's a constant string that was compiled directly into the word (eg. with ". or similar).
Having it show the values in constants and variables might be nice, and showing what a deferred word points to also sounds useful. I'll consider adding those to Tali's SEE.