Re: Towards normative opcode behaviour: A SAOL Question

From: John Lazzaro (lazzaro@CS.Berkeley.EDU)
Date: Tue Mar 27 2001 - 21:47:52 EST


> That being said, I got tied up very early in the process with a standards
> question that I need to resolve before I get any further.

My opinions below --

> Answers for the Sfxx compiler:
>
> Question 1: (1) Zero for the left channel, one for the right channel.

I'd vote for the normative behavior here being (1,1), which is what
sfront does. Basically, 5.7.3.3.6 (Decoder execution while streaming),
item 2, says at instrument birth, all of the i-rate statements get
executed, in order. Since:

    iValue = 0;
    iValue = 1;

are both irate, and the only irate, statements in TestInstrument(),
they would execute one after the other, and the knowledge of iValue
ever having the value 0 would be gone.

> Question 2: (1) Zero for the left channel, one for the right channel.

I'd vote for the normative behavior here being (1,1) -- sfront does
this today for -O0 flag (all optimizations off), but it looks like
an incorrect optimization is preventing it from getting the right
answer with optimization right now. The basic reasoning goes like
this:

The first time TestOpcode() is called, it first runs all of its
i-rate statements (according to the Corrigenda 1.11 item):

    iValue = 0;
    iValue = 1;

It then runs its a-rate statements:

    aVar1 = IValue(iValue);
    aVar2 = IValue(iValue);

Per Corrigenda 1.12, it runs its a-rate statements by realizing Ivalue()
is an iopcode, and so only executes its semantics the first time it
is called (returning 1 for each line), and in all subsequent calls
just uses the value it returns the first time (1).

----

Basically, the second example (and sfront's bug :-) indicate that i-rate and k-rate now have two meanings -- the actual i-rate and k-rate of an instr, and the "pseudo-irate" that occurs during an i-rate statement of an aopcode or kopcode, and the "pseudo-krate" that occurs during a k-rate statement of an aopcode. Sfront is still struggling with this concept in parts, thus the bug -- and a few others of this nature people have sent in recently, too.

--jl

------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -------------------------------------------------------------------------



This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:11:07 EST