Does that „split-action” have any merits behind it? Or is it just on the rule: „well, someone years ago" made it this way, and then all the followers copied that because it worked doing no harm”?

"NEXT is a run-time routine of the address interpreter. IP usually points to the next word to be executed in a colon definition. After the current word is executed, the contents of IP is moved into W and now IP is incremented, pointing to the next word to be executed. Now, W contains the address of
the current word to be executed, and an indirect jump to the address in W starts the execution process of this word. In the mean time, W is also incremented to point to the parameter field address of the word being executed. All code definitions ends with the routine NEXT, which allows the next word after this code definition to be pulled in and executed." C.H.Ting, Systems Guide to figForth

Does this help?

It's not an answer to my question.
1. „Moving Forth” by Brad Rodriguez actually describes usage of „W” a bit differently
(„This illustrates an important but rarely-elucidated principle: the address of the Forth word just entered is kept in W. CODE words don't need this information, but all other kinds of Forth words do”).
2. Please, note that dr. Thing wrote: „In the meantime, W is also incremented to point to the parameter field address of the word being executed”. Well actually it isn't; it's only half-incremented (at least when talking about implementation for x86-
PC, not for PDP-11). That's why I raised my question.
I don't see much sense in raising W's value „a little” during NEXT's execution, only then „a second little” during DOCOL's time. But maybe there is any rationale behind it?
But indeed I forgot that solution for PDP-11; it shows that probably it was solved „one way, or another”. Just being curious, why „partially here, then partially there”? „Just like that” or for some particular reason?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, May 17, 2022 at 5:31:25 PM UTC-5, Zbig wrote:

Does that „split-action” have any merits behind it? Or is it just on the rule: „well, someone years ago" made it this way, and then all the followers copied that because it worked doing no harm”?

"NEXT is a run-time routine of the address interpreter. IP usually points to the next word to be executed in a colon definition. After the current word
is executed, the contents of IP is moved into W and now IP is incremented, pointing to the next word to be executed. Now, W contains the address of
the current word to be executed, and an indirect jump to the address in W starts the execution process of this word. In the mean time, W is also incremented to point to the parameter field address of the word being
executed. All code definitions ends with the routine NEXT, which allows the next word after this code definition to be pulled in and executed."
C.H.Ting, Systems Guide to figForth

Does this help?
--
me

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Advantage of doing it in NEXT: Less code; you don't need the
incrementing code replicated in DOCOL, DOVAR, maybe DOCON, DODOES.

Disadvantage of doing it in NEXT: It costs time that is wasted if the
next word does not use W (primitives), or can do it cheaper as part of
an addressing mode (maybe DOCON, DODOES).

Unless I need to save the last byte, I would not put it in NEXT on the
8086.

Indeed that was my understanding of this, that's why I saw that „undecided”,
„splitted” solution as kind of code littering. But I thought: „maybe there's a valid reason”?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Incrementing W in NEXT by at least one was unavoidable. It would have aided portability to have W point to the same place in every FIG implementation.

Thanks. I didn't work with 8080 assembly before; could you, please,
take a look did I properly „decode” your listing:
NEXT: LDAX B ;(W) <- ((IP)) // A := BC C@
INX B ;(IP) <- (IP)+2 // BC := BC + 1
MOV L,A // L := A
LDAX B // A := BC C@
INX B // BC := BC + 1
MOV H,A ;(HL) <- CFA // H := A
; IP uses BC, W uses HL
; So now W = (IP) and IP = former_IP + 2
NEXT1: MOV E,M ;(PC) <- ((W)) // E := HL C@
INX H // HL := HL + 1 (which means W := W + 1)
MOV D,M // D := HL C@ // X := (W)
XCHG // HL and DE pairs swap their contents (W turns into X and vice versa) PCHL ;NOTE: (DE) <- CFA+1 // JMP (HL) which means JMP (X)

So all this because 8080 has no command to do 16-bit transfer -- and sometime later
the translation of the code to x86 has been done „literally”, 1:1 -- no optimization at all?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Be prepared to find vestigial organs in fig.

I'm afraid I'm already found a few; just I'd like to be sure I'm not missing the details.

Replace it with:

NEXT: LODSW
MOV BX,AX
JMP [BX]
NEXT1: MOV DX,BX
INC DX
JMP [BX]

Do I really need to do DX incremention at all in simplified solution you propose?
What for? Unmodified it'll still contain real CFA, not (a bit senseless) CFA+1.

They were not familiar to the very powerful (?!) 8086 instruction set

DOCOL:
DEC BP }
DEC BP } push si on the returns stack
MOV [BP],SI }
MOV SI,[BX+2]
JMP NEXT

Saving the manipulation with reg DX.

Indeed. Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

They were not familiar to the very powerful (?!) 8086 instruction set

DOCOL:
DEC BP }
DEC BP } push si on the returns stack
MOV [BP],SI }
MOV SI,[BX+2]
JMP NEXT

Saving the manipulation with reg DX.

But MOV SI,[BX+2] means „copy contents pointed by BX+2” rather than „copy BX+2 to SI”, correct? So it won't work here as replacement.

Anyway eliminated superfluous use of DX from NEXT, DOCOL, DOCON, DOVAR,
DOUSE and DODOE — everything replaced by BX manipulation only — and... it still
seems to work just fine. :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)