On Thu, 2002-10-24 at 09:51, David M. Lloyd wrote:
> On Thu, 24 Oct 2002, Andi Gutmans wrote:
> > At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote:
> >
> > >The reality of twos-complement, bitwise arithmatic is that there are
> > >three basic shift operations:  shift left, bitwise shift right, and
> > >arithmetic shift right.  This simple fact is one of the basic ideas of
> > >dealing with twos-complement integers.
> >
> > I know that but I still wanted the opposite to be available to keep
> > things symmetrical. I'm not sure but I think CPU's do support both
> > logical and arithmetic shifts and just do the same with both (I might be
> > wrong though).
> Generally no, it's a waste of opcode space for modern CISC processors.
> RISC processors often have integrated barrel-shifters, so they don't need
> shift instructions at all.
> Intel carries over "arithmetic" shift right instructions from older
> architetures for backwards-compatibility with x86, but their RISC
> implementation (Itanium) does not contain support for the operation.
> One RISC example is ARM.  They give you four shift options: Logical left,
> logical right, arithmetic right, and rotate right.  Making the operation
> symmetrical is a waste of precious bit combinations, and would have meant
> either losing another shift operation or else adding another bit to the
> shift operation specifier, which means that another bit would have to be
> sacrificed elsewhere.
> Another example is SPARC, which implements shifting with discrete
> instructions, only implents one left shift operator.  PowerPC does not
> implement it either.

Alpha has 3 instructions as well (log left, log right, arith right)

> > >Given this fact, there is no reason to have a bogus fourth operator in the
> > >name of symmetry.  Mathematical operaters are simply not always
> > >symmetrical.  There is no such thing as 'arithmetic shift left' or
> > >'logical shift left' in terms of twos-complement integers, so why invent
> > >it?
> >
> > I agree that they don't *have* to be symmetrical but I think it's
> > better.
> Better why?  Anyone who understands twos-complement will understand (and
> expect) the ability to do those three operations, and will not be
> surprised by the lack of two left shifts.  I argue that they *should NOT*
> be symmetrical because it is wrong.

I have to say I agree, introducing a bogus operator could actually cause
confusion. Java, which has been used several times in past arguments of
"why we should not do XYZ", has not had a problem with having only the
operators that actually exist.

> > >Second of all, my understanding of the here-doc operator is that it acts
> > >as a unary operation.  I don't see the conflict with the binary
> > >application of <<<, given the example of unary and binary -, if it is
> > >absolutely neccessary to fulfill the (somewhat psychotic) need for
> > >symmetry where it is not realy needed, or even strictly correct.
> >
> > psychotic? Can we please have discussions on a professional and not
> > personal level?
> It is true though, unless you can give me a sound mathematical reason that
> the ops should exist... and saying "it looks right" or "it is easier" is
> not a valid reason, becuase to those with even basic twos-complement math
> background, it looks wrong and is not easier.
> > As far as I remember it does clash with here-docs. I'm pretty sure I
> > thought of an example a while back. I can try and think of one again. In
> > any case, I wouldn't want an overloaded operator. We try and keep away
> > of that kind of stuff with PHP.
Clashing can occur with Constant values, and functions with a \n in
front of the (). 
> Very well... then let's not put in the nonsense operator, and just have
> three shift operations: <<, >>, and >>>.

I agree
> - D
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php

Jason T. Greene <[EMAIL PROTECTED]>
                <[EMAIL PROTECTED]>

PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to