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

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> ).
--
Krishna
=== begin code ===
50000000 constant iterations
: faccum  create 1 floats allot? 0.0e f!
     does> dup f@ f+ fdup f! ;
: faccum-part2 ( F: r1 -- r2 ) ( a -- )
     dup f@ f+ fdup f! ;
faccum x4  2.0e x4 fdrop
faccum y4 -4.0e y4 fdrop
: b4 0.0e iterations 0 do x4 y4 loop ;
: b5 0.0e iterations 0 do
     [ ' x4 >body ] literal faccum-part2
     [ ' y4 >body ] literal faccum-part2
   loop ;
=== end code ===