Re: using MISC (post 1987 Forth hardware) opcodes

Bernd Paysan wrote:

Jeff Fox wrote:

Thanks for the overview.


But it may be important to note that it is not the same as null
just as the non-destructive IF is not the same as DUP IF
because DUP is destructive.


Yes, that's obvious. That means you can't use DUP IF if you have a full
stack and want to branch on the top of stack element. That's the up side:
you save one stack element. The cost is that you lose the destructive IF,
and you need to DROP the flags when you don't need them (maybe it's my
programming style, but that's the majority). Finally, on my code, the
coincidence of having a DUP IF and a full stack at the same time was zero,
so I reverted to a destructive IF in the two b16 variants that are used in
our products.

Have either of you guys considered a flag *register* rather than a flag in the stack? I think it has some serious advantages.

1. You don't have to worry about either DUP or DROP of flags: the flag persists until the next test.

2. Explicit arithmetic with flag values is relatively rare, and "short-circuit evaluation" is often a good (and more efficient!) substitute anyway.

3. A persistent flag register makes it easy to return success or failure up through several levels of code, handling it appropritely at each level without stack gymnastics.

Nondestructive IF seems to me to fight with the stack data flow: it leaves the flag blocking your other operands so you're almost always going to need stack gymnastics immediately after. But the need to reuse the flag is fairly common in my code, so a register allows me to have my cake and eat it too. The thing I hardly ever want is a stack of flags: one at a time is usually enough.

--
---
John Doty, Noqsi Aerospace, Ltd.
---
His diagnosis of the hostility ... reflects the willful blindness of the invader who assures himself that the natives are only made unfriendly by some other provocation than his own. -Barbara W. Tuchman
.

Relevant Pages

  • Re: using MISC (post 1987 Forth hardware) opcodes
    ... because DUP is destructive. ... stack and want to branch on the top of stack element. ... Have either of you guys considered a flag *register* rather than a flag ... A persistent flag register makes it easy to return success or failure ...
    (comp.lang.forth)
  • Re: using MISC (post 1987 Forth hardware) opcodes
    ... You don't have to worry about either DUP or DROP of flags: the flag persists until the next test. ... Explicit arithmetic with flag values is relatively rare, and "short-circuit evaluation" is often a good substitute anyway. ... leaves the flag blocking your other operands so you're almost always going to need stack gymnastics immediately after. ...
    (comp.lang.forth)
  • Re: Forth Frustrations
    ... DUP BEGIN DUP WHILE (widn ... ... This is easier if you give yourself a few variables or a third stack. ... ROT DROP SWAP 1- SWAP ELSE ... switchovers to rearrange the closest three cars. ...
    (comp.lang.forth)
  • Re: Is C99 the final C? (some suggestions)
    ... You mean vague terminologies like "stack"? ... wrap whatever "spawn" mechanism you have in your language (or use some ... >> and because of Java's bignum class, it meant that exposing a widening multiply ... >> you use to determine this is just related to examining the carry flag. ...
    (comp.lang.c)
  • Re: Forth Frustrations
    ... DUP BEGIN DUP WHILE (widn ... ... This is easier if you give yourself a few variables or a third stack. ... ROT DROP SWAP 1- SWAP ELSE ... switchovers to rearrange the closest three cars. ...
    (comp.lang.forth)
Loading