"Coos Haak" <chforth@[EMAIL PROTECTED]
> wrote in message
news:1n6bn53j9k93u.r2aah2jez3ac.dlg@[EMAIL PROTECTED]
> Op Fri, 14 Mar 2008 13:39:47 +1100 schreef Ed:
>
> > "Anton Ertl" <anton@[EMAIL PROTECTED]
> wrote in message
news:2008Mar13.111759@[EMAIL PROTECTED]
> >> Albert van der Horst <albert@[EMAIL PROTECTED]
> writes:
> >>>In article <20080312075319.57514ec7.jethomas5@[EMAIL PROTECTED]
>,
> >>>Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> wrote:
> >>>>William James <w_a_x_man@[EMAIL PROTECTED]
> wrote:
> >>>>> "Ed" <nos...@[EMAIL PROTECTED]
> wrote:
> >>>>>
> >>>>> > Playing with the algorithm for WITHIN (A.6.2.2440) one gets:
> >>>>> >
> >>>>> > : BETWEEN ( n1|u1 n2|u2 n3|u3 -- flag ) OVER - -ROT - U< 0= ;
> >>>>>
> >>>>> Stuff like this leads one to believe that Forth code is
> >>>>> unreadable, cryptic, unsharable, and unmaintainable.
> >>>>> It's worse than some assembly language I've seen.
> >>>>> Forth needs to become a higher-level language.
> >>>>
> >>>>What are your standards for readability?
> >>>>
> >>>>I see six commands, and I understand every one of them. No control
> >>>>structures. It doesn't get much clearer than that.
> >>
> >> It does some stack shuffling, it uses the wrap-around properties of
> >> computer arithmetic (even a collegue of mine who likes to do much
more
> >> low-level optimization than is good for the code did not know the
> >> trick used by BETWEEN and WITHIN), so there can be clearer words. We
> >> can do something about the stack shuffling by using locals:
> >>
> >>: between { x l u -- f }
> >> x l - u l - u<= ;
> >>
> >> I believe this to be correct. And obviously the factoring here is at
> >> least as good as with the stack-shuffling version.
> >>
> >> Still, if for religious or practical reasons people want to avoid
> >> locals, I think the original version also becomes a little more
> >> readable by using the return stack:
> >>
> >>: between ( x l u -- f )
> >> over - >r - r> u<= ;
> >
> > Forth should be coded for performance. I posted the -ROT
> > version because it's likely to work out better for most users.
> > Most forths have -ROT ; it results in one item less and thus
> > hopefully faster; x86 optimizers I tried did a better job on it.
>
> I disagree, using the pair >R and R> would be faster than -ROT, some
> primitive implementations could define : ROT SWAP >R SWAP R> ;
Very amusing.
If such a forth exists then I doubt performance is high on its
priority list.
> But it would make no difference with a native compiler that makes full
use
> of registers I assume.
It depends on the compiler. As a general rule, less operators means
better performance. On VFX and SwiftForth the -ROT version works
out better because when they see >R ... R> they do, in fact, use the
return stack. DTC/ITC forths, also, benefit from the -ROT version.
As far as the algorithm is concerned both forms are identical.
If one wishes to express it in Standard words, then by all means
use >R ... R> .
For myself, I would use the code version because primitives
should be fast.
|
