«

On Jun 20, 11:14 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> Rasjid wrote:
> > 2) Does precedence of operators determine order of evaluation ? If
> > Yes, then in what situations.
>
> No, it doesn't, except accidentally. For example, it's hard to come up
> with an order of evaluation for x * y + z that doesn't do the
> multiplication before it does the addition.

An RPN-style evaluator might push z, then push x and y,
then mult, then add.

Old Wolf <> writes:
> On Jun 20, 11:14 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
>> Rasjid wrote:
>> > 2) Does precedence of operators determine order of evaluation ? If
>> > Yes, then in what situations.
>>
>> No, it doesn't, except accidentally. For example, it's hard to come up
>> with an order of evaluation for x * y + z that doesn't do the
>> multiplication before it does the addition.
>
> An RPN-style evaluator might push z, then push x and y,
> then mult, then add.

Which *does* do the multiplication before it does the addition.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Jun 25, 12:40 pm, Keith Thompson <k...@mib.org> wrote:
> > Richard Heathfield <r...@see.sig.invalid> wrote:
> >> No, it doesn't, except accidentally. For example, it's hard to come up
> >> with an order of evaluation for x * y + z that doesn't do the
> >> multiplication before it does the addition.
>
> Which *does* do the multiplication before it does the addition.

Sorry, I took R.H.'s comment to read: evaluates
the arguments of the multiplication before
evaluating those of the addition.

On Jun 22, 12:21 pm, Keith Thompson <k...@mib.org> wrote:
> If your reply is just plain text, you don't need a preview.

I used to use Google Groups preview feature to
check that my lines were short enough so that
others didn't see a long-short-long-short wrapping
effect when reading my posts. Since they removed
that option, I just have to cross my fingers..

In article <>,
Richard Heathfield <> wrote:
>For example, it's hard to come up
>with an order of evaluation for x * y + z that doesn't do the
>multiplication before it does the addition.

It might use a multiply-and-add instruction which does them both at
once.

(I assume multiply-and-add works domething like this: to do 12*23+45
it does 10*23 + 2*23 + 45, so that the multiplication might at least
not be finished before the addition.)

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Richard Tobin wrote, On 25/06/07 09:15:
> In article <>,
> Richard Heathfield <> wrote:
>> For example, it's hard to come up
>> with an order of evaluation for x * y + z that doesn't do the
>> multiplication before it does the addition.
>
> It might use a multiply-and-add instruction which does them both at
> once.
>
> (I assume multiply-and-add works domething like this: to do 12*23+45
> it does 10*23 + 2*23 + 45, so that the multiplication might at least
> not be finished before the addition.)

On the processors I've used with a MAC instruction, the add is the
result of the previous multiple not the current one, so it can be done
in parallel with the multiple. So if you had
a * b + a * c + a * d;
You could implement it as
ZAC ; Zero the accumulator
LT a ; Load a in to the T register
MPY b ; Multiple b by the T register
MAC c ; Add the product to the accumulator and multiple c * T
MAC d ; Add the product to the accumulator and multiple d * T
APAC ; Add the product to the accumulator

So here an add is always occurring at the same time (same clock cycle)
as a multiply, but the add is always the result of an earlier multiply.

The above was for the Texas Instruments TMS320C2x series of processors.

What I have done with hand coded assembler which is even screwier was
using some of the address registers for add/subtract whilst using the
accumulator & multiplier for other things. Because the addressing was
done in an earlier pipeline stage to the ALU, multiplier and
transferring data to/from the address registers, it ended up with
instructions using data in address registers appearing *after*
instructions overwriting the data in the register, although the parts
actually executed in the correct order. This was on a TMS320C80, and I
would not have written code like that if it was not for the fact that
even using every trick I could come up with we still did not have enough
processing power (I did it so it would work as much as possible with
what we had).

I don't know how much the compilers make use of these tricks, I know the
TMS320C80 C compiler was bad, but I generally found the TMS320C2x
compiler did a good enough job. However, the compiler writers *could* do
screwy things like this if they were clever enough.
--
Flash Gordon

Flash Gordon said:

> Richard Tobin wrote, On 25/06/07 09:15:
>> In article <>,
>> Richard Heathfield <> wrote:
>>> For example, it's hard to come up
>>> with an order of evaluation for x * y + z that doesn't do the
>>> multiplication before it does the addition.
>>
>> It might use a multiply-and-add instruction which does them both at
>> once.
>>
>> (I assume multiply-and-add works domething like this: to do 12*23+45
>> it does 10*23 + 2*23 + 45, so that the multiplication might at least
>> not be finished before the addition.)
>
> On the processors I've used with a MAC instruction, the add is the
> result of the previous multiple not the current one, so it can be done
> in parallel with the multiple. So if you had
> a * b + a * c + a * d;
> You could implement it as
> ZAC ; Zero the accumulator
> LT a ; Load a in to the T register
> MPY b ; Multiple b by the T register
> MAC c ; Add the product to the accumulator and multiple c * T
> MAC d ; Add the product to the accumulator and multiple d * T
> APAC ; Add the product to the accumulator
>
> So here an add is always occurring at the same time (same clock cycle)
> as a multiply, but the add is always the result of an earlier
> multiply.

A *really* clever compiler, if it were sure that no overflows would
result, could translate this to:

MOV T, b
ADD T, c
ADD T, d
MUL T, a

thus doing the adds before the multiply, QED.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote, On 25/06/07 20:54:
> Flash Gordon said:
>
>> Richard Tobin wrote, On 25/06/07 09:15:
>>> In article <>,
>>> Richard Heathfield <> wrote:
>>>> For example, it's hard to come up
>>>> with an order of evaluation for x * y + z that doesn't do the
>>>> multiplication before it does the addition.
>>> It might use a multiply-and-add instruction which does them both at
>>> once.
>>>
>>> (I assume multiply-and-add works domething like this: to do 12*23+45
>>> it does 10*23 + 2*23 + 45, so that the multiplication might at least
>>> not be finished before the addition.)
>> On the processors I've used with a MAC instruction, the add is the
>> result of the previous multiple not the current one, so it can be done
>> in parallel with the multiple. So if you had
>> a * b + a * c + a * d;
>> You could implement it as
>> ZAC ; Zero the accumulator
>> LT a ; Load a in to the T register
>> MPY b ; Multiple b by the T register
>> MAC c ; Add the product to the accumulator and multiple c * T
>> MAC d ; Add the product to the accumulator and multiple d * T
>> APAC ; Add the product to the accumulator
>>
>> So here an add is always occurring at the same time (same clock cycle)
>> as a multiply, but the add is always the result of an earlier
>> multiply.
>
> A *really* clever compiler, if it were sure that no overflows would
> result, could translate this to:
>
> MOV T, b
> ADD T, c
> ADD T, d
> MUL T, a
>
> thus doing the adds before the multiply, QED.

It would have to be very clever, since the processor cannot add to the T
register, nor can it multiply by the contents of the accumulator. I'm
talking about a real processor with a MAC instruction. As far is the
standard is concerned yes, it could do it your way.
--
Flash Gordon