Re: Feature Requests

David McNab wrote:
> I'd like to put forward some feature requests - things I'd like to 
> implement myself, if I only understood the guts of the compiler better.

I'd like to put forward a few humble requests of my own:

1. It would be great if any words which are defined but never used 
weren't compiled into the binary (I realise this would require two 
passes to figure out how many times each word is used). In a similar 
vein, it would be nice to use the same information to automatically 
inline any words that are only used once.

2. It would be extremely helpful for beginners if the documentation 
included a glossary of every picforth word with a brief description of 
what it does.

3. The picforth source tree would be a little easier to navigate if the 
example source files and the library files were both in subdirectories 
of their own.

4. It would be handy if there was some way for the 'dis' and 'map' 
commands to output directly to a file. At the moment I run picforth 
twice every time I compile- the first run dumps the hex file and pipes 
the map through sort to a file and the second run pips the disassembly 
to a file.

5. It would be nice if there was some kind of 'statistics' command which 
after a compilation run tells us stuff like how many instructions and 
how many RAM bytes were used, how many words there were, the maximum 
return stack depth, etc.

6. Is there some way to get rid of the huge list of 'redefined' words 
every time gforth includes picforth.fs? It might be handy to see if I've 
redefined a word in my own source (I've done it a couple of times 
accidentally) but I don't want to see the dozens of words that 
picforth.fs has redefined every time I do a compile.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer