Talk:6.1.2

From RevaWiki

(NOTE: if you make comments here, please separate them from the text I have entered, and use the ~~~~ markup to indicate your name and the time of your edit. Thank you!)

---

For this release I want to concentrate on issues of efficiency and cleanup.

Size

There are a few big changes I want to make. Reorganize code layout (again) so that the XT is not preceded by bookkeeping information. Currently, the layout is:

       jmp xt
       dd size-of-code
       dd pointer-to-dictionary
xt:    actual code...

This is beneficial for debugging, since we can easily determine what the 'name' of a piece of code is, and also we know the exact size for disassembly. It is also beneficial for inline words, since the size of code to put inline is known.

Unfortunately, this construct adds 12 surplus bytes to each colon-def (currently amounting to over 4K wasted space). It also make the fall-through from one word to another much less efficient:

     : word1 : word2 ... ;

The 'fall-through' has to perform a JMP which is totally unnecesary.

I am planning the following steps:

1. Completely remove the "jmp..." prefix to each XT
2. Change inline words so that they store their code simultaneously with the length in a "cstr" in the dictionary. That is, inline words will not consume any code space until used.
3. Modify the debugger so it scans forward for a RET opcode rather than rely on stored size. This will be wrong in many cases.

Ron 11:14, 2 November 2006 (EST): Partly finished, though p: is unhappy for some reason. Ah well, no pain -- no gain.

Ron 01:55, 3 November 2006 (EST): The 95% that was easy is done. Now the 5% of pain has started, and it is reasonably painful. It turns out it was quite convenient and useful to have the xt point back to the dictionary entry, and I took advantage of it in quite a few places. No matter, the work progresses.

Ron 15:06, 7 November 2006 (EST): This undertaking has uncovered bugs (which is a good thing) that are quite subtle. Still fixing things up...

Speed

It may be that the size modifications alone will render a significant speedup -- certainly the "fall-through" words will be sped-up.

The create family stores the data inefficiently, in that the data pointer is misaligned. While this may be a significant amount of work to do properly (based on my trial before 6.1.1), I think it will be a gain for anything which uses create. I also want to look at exactly how does> operates and perhaps change the mechanism to take advantage of classes (I'm not sure how yet).

I will also want to look into alignment issues in the core, and try to ensure all entry points are aligned and that all data references are also aligned.

Ron 17:31, 9 November 2006 (EST): Just finished converting over "create/does>" to a new method. Seems to be considerably faster, which is good.

Cleanup

1. Examine every word in Reva itself and remove the "stragglers" to libraries
2. Make sure every word is documented in Reva
3. Resume commenting the libraries
4. Streamline the build process more