Contents of file "README"

This Forth, postFORTH, is not ANSI; it's not FIG-FORTH, and it's not like
any other Forth you have ever used. It's very incomplete. It does not have
states, and all compilation is done with tick and comma. Its outer
interpreter hashes all words into a unique hash; if it turns out not to
be unique, you will very likely crash the program, particularly if the word
with which it collides is part of the inner or outer interpreters. The
best possible reaction is for postFORTH to show you the word with which
the most recent word collides, and allow you to exit gracefully.

Now that the basic shell, pf, has trapped the SEGV signal, it will now
recover from the most common, previously catastrophic, error; that of
invoking an as-yet undefined word. Since this yields a CA of zero,
that would previously coredump as a segfault.

This README file is for now just a collection of debugging notes; someday
it will become the postFORTH manual.

gdb f core
x/i $pc
info reg

Launches the GNU debugger on the corefile created by f or postFORTH. Since
only f has any symbols, use that with gdb and the corefile. 'x/i $pc' will
show what instruction was being executed at the time of the crash. And
'info reg' will show the contents of all the registers so you can see
exactly what went wrong.

' .S ,

Sprinkle this liberally in your buggy programs and it will show you the
stack contents at those points. The first is outside a definition, and
the second inside a definition.

S" critical point" 2 TYPE
" critical point" ' 2 , ' TYPE ,

Another debugging tool; again, the first is typed outside of a definition
and the second within a definition. Don't mix the two up!

Look for the numbers corresponding to syscalls in:

I played around with making hashbits smaller; I got one collision with
it set to 14, so I left it at 15. Then I tried setting bss_size smaller
since now the dictsize was only half what it was; benchmarking showed a
slight slowdown, only 385 times 'hello' in 10 seconds vs. 400 times before
the change.