Hi Robin,
I've been planning to post a series of "Rationales" on why
sfront implemented the points you describe -- and many others that are
contentious -- the way it did.
I'll probably create these in an IETF-like RFC format, to try
to start a tradition where implementation/extensions get proposed and
discussed in the group. The result wouldn't have any bearing on MPEG
ISO/IEC decisions, but would at least give a framework for
"independent" developers to get their tools working together well
("rough consensus and running code", in IETF parlence).
But until then, here's a quick rundown of the reasons
why sfront does what it does in this regard:
> 2) Use of i-rate expression in kopcodes.
> 2) Use of i-rate expressions in k-rate if clauses.
> 3) a-rate expressions in kopcodes.
These are all manifestions of the concept "an opcode
executes statements that run at the rate that the opcode is
called at, unless specifically dictated by text describing a
core opcode", which is the primary guide I used for all of
these rate-semantic opcode issues.
Since (for an a-rate opcode) the k-rate and i-rate lines
aren't running at the a-rate, they don't execute when the opcode
is called at arate (the only rate it can be called).
The explicit textual semantics in core opcode descriptions
override the rule, so that:
asig a;
a = oscil() * kline();
Is supposed to do the "right" thing, whereas a user-defined
opcode that replaced kline would not.
> 1) Precedence of argument declarations, variable declarations, standard
> names.
Basically, 5.8.2.2, 5.8.7.3. and 5.8.9 all have things to say
about this, I had asked Eric for an interpetation of 5.8.2.2
and based on it implemented what you describe. I could have,
of course, misinterpeted his interpetation ... and a quick
look through my email archives didn't reveal it, so I can't
quote it directly.
> 4) Calculation of opcode rates from arguments.
Basically, if you accept:
"an opcode executes statements that run at the rate that the
opcode is called at, unless specifically dictated by text describing a
core opcode".
Then having non-xsig arguments in user-defined poly-opcodes is of
limited usefulness -- any compiler smart enough to do good optimization
will have already figured out the actual rate of xsigs, and will base
its optimization on that rate anyways.
That's why sfront matches saolc's dislike of:
opcode ResonantFilter(asig aInput, xsig xCps, xsig xDbResonance)
Two concluding points:
[1] "The MP4-SA Book" had to address these things too -- we wanted
to write a book that showed how to quality SAOL code, for people who
didn't know that much about CS. One approach we took was the concept:
"well-written user-defined opcodes have all the statements run at
the rate of the opcode ({,i,k,a}opcode). If you don't follow this
rule, it may or may not be legal SAOL, and may or may not be well
implemented across different decoders."
[2] We're all better off if the standard is interpeted in a way that
its possible to write a simple, slow, interpeted decoder, as well as
a leading-edge optimizing interpeter. This means, no heavy analysis to
figure out how to get the "right" answer -- only how to get the right
answer faster.
-------------------------------------------------------------------------
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:03:54 EST