Was it a performance reason? Eg, was it faster to implement common numbers like 0 or 3 as forth words, and leaving other numbers as-is?
Yes, spot on - you have discovered a little secret! (Actually, not so secret - they are in the manual). Not a major performance increase but slightly quicker nonetheless. I think it's worth it for 0 and 1 which occur in programs very commonly; I'm not so convinced by 2 and 3!
Honestly, I feel lost a bit with forth, especially with the storage methods. As far as I can understand the "difficulties" is because forth is old and run on systems without "real" OS (other than forth) having only block I/O without real filesystem etc ...
Yes, FORTH can sit rather uncomfortably on other OSs, particularly with file I/O, and especially with tape storage! I was reading the word list of a modern FORTH the other day and it included a set of words very similar to C's fopen(), fread() etc.. Of course of the Enterprise you can use EXOS
From the manual: at the start 8 buffers used. Can be added more with the CREATE-BUFFERS which is allocating full segment for more 16 buffers. It is can be used 16 times, then the total buffers is 8+16*16=264.
But now I tried and after 13 CREATEs it is frozen
Trust you to try that zozo!!
I was not able to test that 30 years ago - that much memory was just a distant dream! This system of saving the buffers to a file was really a way of getting around the lack of disks which standard FORTH relies on (it is my invention, not standard). In my defence nobody would want to save 264k to a tape file
If you were writing a serious program on a real Enterprise with disks you would not use this method at all - you would use the random access .4th files to hold your FORTH blocks.
lgb I think you and zozo now have more information than my memory about the file format! In FORTH You can create whatever block numbers you like, eg 10 EDIT followed by 10000 EDIT so when they are written to the file there is no way they could be sequential. I expect the order is whatever the order in internal memory.
One point I have just noticed is that trailing spaces are not removed; thus even the smallest program takes up 1k
and if you have 16 small program fragments each in their own block it will take up 16k
which is not good on tape systems that this is aimed at!