SamCoVT
commented
7 months ago I pretty much navigate by searching for xt_word_i_want: (the colon is important to get the definition and not all of the places were it is called) but that can be difficult for the ones with punctuation, like <#. At least their names are in the comments and that helps sometimes.
The "not in alphabetical order" is usually for words that share enough code that you could start in one and jump into the other, but I would expect these to end up together in the same file if they are that related. We do also have a few, like 0 and 1 that are reused for other things like 0 is also case is also false is also forth-wordlist. I think there are comments for these now (in the alphabetical location) and most of the magic of reusing the body happens in the headers, although it looks like xtzero does have additional xt and z_ labels for the other words right now. I'd be fine with just using xt_zero in the header along with a comment.
On double checking, false is actually a separate word, which is silly, and we could save 6 bytes by merging it with the xt_zero and the others.
I have no issues at all with breaking up native_words.asm. Would you also split out the headers? That may actually prove to be more difficult than splitting up the words. Because Tali was designed to be Forth-2012 compliant, I do think it makes sense to break them out by standard wordsets.
I find it somewhat unwieldy to navigate, being mostly but not quite in alpha order. You typically have to know what you're looking for to find things.
I guess a start might be to splits out block.asm and wordlist.asm which are the biggest sets of conditional words.
I'm not sure if there are other clusters of words that would make sense in a separate file, perhaps https://forth-standard.org/standard/words would be way of grouping?
files could share a common prefix, like native or words to keep them grouped in the folder.
for example words_core.asm words_block.asm words_wordlist.asm words_double.asm words_string.asm ...