Re: Implementing DOES>: How not to do it (and why not) and how to do it

On 7/14/24 07:20, Krishna Myneni wrote:

On 7/14/24 04:02, albert@spenarnc.xs4all.nl wrote:

In article <2024Jul13.173138@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>

>
In any case, if you are a system implementor, you may want to check
your DOES> implementation with a microbenchmark that stores into the
does-defined word in a case where that word is not inlined.

>
Is that equally valid for indirect threaded code?
In indirect threaded code the instruction and data cache
are more separated, e.g. in a simple Forth all the low level
code could fit in the I-cache, if I'm not mistaken.
>

  Let's check. In kForth-64, an indirect threaded code system,
 .s
<empty>
  ok
f.s
fs: <empty>
  ok
ms@ b4 ms@ swap - .
4274  ok
ms@ b5 ms@ swap - .
3648  ok
 So b5 appears to be more efficient that b4 ( the version with DOES> ).
 

This discrepancy between b4 and b5 is due to the fact that, in kForth, DOES> not inline the code into the created word. So there is room for improvement in the implementation of DOES> in kForth. There are other important pressing issues to deal with, such as making the User's Manual more useful (the most important item) and adding other standardized words, but improving DOES> is low-hanging fruit.
--
Krishna
=== begin code ===
// DOES>  ( -- )
//
// Forth 2012
int CPP_does()
{
   // Allocate new opcode array
   byte* p = new byte[2*WSIZE+4];
   // Insert pfa of last word in dictionary
   p[0] = OP_ADDR;
   WordListEntry* pWord = *(pCompilationWL->end() - 1);
   *((long int*)(p+1)) = (long int) pWord->Pfa;
   // Insert current instruction ptr
   p[WSIZE+1] = OP_ADDR;
   *((long int*)(p+WSIZE+2)) = (long int)(GlobalIp + 1);
   p[2*WSIZE+2] = OP_EXECUTE_BC;
   p[2*WSIZE+3] = OP_RET;
   pWord->Cfa = (void*) p;
   pWord->WordCode = OP_DEFINITION;
   L_ret();
   return 0;
}
=== end code ==