Hi Everyone,
I'll be responding to a few of both Robin's and Giorgios
comments in this email, intermixed ...
/////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////
First, I'd like to agree with all of Giorgios "motherhood and apple
pie" statements, namely:
> I am not against this lack, if the behavior is explained.
> But as I said yesterday, I am mainly against open issues
> that are not clear.
[...]
> But I don't agree that what is done is an implementer's
> business. It should be clarified for all. All points regarding
> UDOs that should be result in degrees of freedom for the decoder
> implemeter.
[...]
> But I'd argue that this is a saol compiler issue, not a language issue.
> I am pretty convinced that this discussion can make the language stronger
> by a group of well conceived corrigenda, but I am a little worried about
> the tendency to mix together saol stuff and specific-saol-decoder stuff.
> I personally don't consider most things that can be solved at compile
> time, before execution, as a language problem.
These are the precise issues that worry me, and I'm in fundamental
agreement with the principles above.
[Robin asks ...]
> You say that you've implemented sophisticated optimizations like doing usage
> analysis of expressions and l-value assignments to determine whether a
> variable has integer or floating point storage type.
> So what's so difficult about evaluating opcodes with mixed statement rates?
See Giorgio's comments quoted above -- what's important is coming to
a consensus about what the document specifies today, and helping to
guide any corrigenda to clarify what is currently murky, in a way
that makes for a better language.
/////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////
[Giorgio writes, in response to my quoted comment from Robin]
> At 08:59 AM 5/16/00, Robin Davies wrote:
> > > As i-rate statements in a kopcode, these lines will never execute in
> > > sfront, and produce a warning message -- in compliance with the standard
> > > as I read it currently, as we discussed off-line.
> > >
> I admit I had my hard times in solving some of the standard clauses, but
> I can't remember I read a sentence saying that. Why an i-rate line in a
> kopcode should be not compliant ? Could you please explain ?
It's not that I believe the statement is illegal -- if it were, I would have
had sfront abort and print an error message, not print a warning message.
Rather, its that the slower statements don't execute, and so the code
doesn't do what the user expects -- this is why I generate a warning message.
Fundamentally, I base this view on this line of 5.8.6.7.6:
The statement block of the opcode shall be executed at
the current rate.
This seems unambiguous to me -- the way we execute an instr at the
current rate is to only execute statements that have the same rate
as the current rate. Email I exchanged with Eric on this topic
in August 1999 seemed to confirm my reading -- which is why sfront's
implementation is the way it is. But since Eric is (hopefully) alive
and well and listening in, it seems much better to let him weigh in
with his May 2000 viewpoint than to quote his private email from a year
ago on the topic.
I just finished coding up a complex physical model, using several
layers of opcodes, following the UDO rule -- and found that Robin's
description of this rule leading to "nightmare programming practices"
not true in practice. In addition, the efficiency concerns brought
up in this snippet:
> Why? Because I precalculated the arguments to
> fracdelay at i-rate. You say: Just write two halves for the library. I say:
> Can't be done. I have 8 arrays and 4 tables, each of which would have to be
> passed as copy-in-copy-out parameters, presumably at a-rate if the UDO rule
> holds.
don't resonante with me. Converting copy-in-copy-out parameters to
reference parameters in this case, given the knowledge that static
anaylsis can provide, combined with the guarantees of the UDO rule
itself, is quite doable. And so Giorgio's declaration:
> I personally don't consider most things that can be solved at compile
> time, before execution, as a language problem.
applies to this case. Details of the simplicity or difficulty of
doing an optimization in a particular compiler, be it SAINT, SAOLC,
sfront, or Sfx, shouldn't be guiding language decisions.
/////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////
This all said, its quite possible that the decision is made to alter
opcodes to not obey the UDO rule. If so, the focus shifts to pinning
down the detailed semantics for executing slower statements in an
opcode of a given rate.
I think a comparison of Robin's and Giorgio's description of how Sfx
and SAINT handles executiing the k-pass and i-passes of an aopcode
guarded by a conditional says it all:
[Robin writes]
Sfx currently evaluates the sub-guard-rate expressions unconditionally. This
is fairly sensible, and leads to a decent conceptual model of how things
work.
[Giorgio writes]
The k-rate expression, if it is broken into intermediate statements
like in saint, generates a k-block inside the a-rate-guarded block.
If such fundamental aspects of two implementations are so different on
this topic, it tells me that the semantics need to be spelled out in
precise detail in a corrigenda, and we should all go implement that --
with the goal of keeping the semantics simple enough for a high school
student SAOL programmer. In particular, these issues:
-- For a aopcode, when the k-rate and i-rate statements execute, and
how does this effect the values of the ksig and ivar parameters to
the opcode running at the different rates.
-- How do if and while statements with guards at all three rates act,
with respect to determining whether i-rate, k-rate, and a-rate lines
execute.
-- Ensuring the semantics work with regards to user-defined opcodes that
call user-defined opcodes that call user-defined opcodes, all of which
have statements at all three rates.
-- For the "opcodes that call opcodes that call opcodes" case, are there
any special considerations if some of those opcodes are in fact oparrays.
need to be addressed in a way that's clear both to high-school
SAOL programmers and to compiler writers.
--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:03:55 EST