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 ? I perfectly
agree that the execution of an opcode block for user-defined opcodes is
"easily" explained in half a page, but the only sentence I read clearly is that
no statement should be faster, as Robin points out in his reply. For instance:
in SAINT we execute the i-block of an aopcode the first time the opcode is
called for a state, and k-block only the first time of a particular a-cycle.
Since SAINT executes both k-block and a-block at k-rate, on scalar and
on vectors respectively, this is even simpler than that. I will be happy to
correct this if it's wrong, but I'd like to understand why.
I agree that in a way or in another things must be clarified.
>(2) If opcodes were supposed to run at a uniform rate, why put rate tags on
>arguments at all? you could quite reasonably assume that the rate of
>arguments is the same as the rate of the opcode tag. e.g. aopcodes would
>have only asig arguments since they can't do any processing of arguments at
>a slower rate, so why bother?
As I said before, this in saint is instead very useful, since it permits to
execute instructions on scalar and instructions on vectors.
>(3) 6.8.7.6 "No statement shall be faster than the rate of the opcode". Note
>the lack of the resitriction that no statement shall be slower than the rate
>of the opcode.
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.
>(6) The construct is grammatically legal. In the absense of a semantic
>restriction the construct is semantically legal as well. What you decide to
>do semantically, I suppose is your business, but accepting it, giving a
>warning, and doing nothing seems dubious. If you're going to do nothing,
>then at least make it an error, not a warning.
I agree with Robin on this. 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.
>(3) Rate restrictions on statement execution imposed by if, else, while and
>oparray should be extended to the rate of formal arguments as well. It
>doesn't make sense to assign a k-rate expression to a k-rate formal argument
>within an a-rate-guarded code block.
The k-rate expression, if it is broken into intermediate statements like in saint,
generates a k-block inside the a-rate-guarded block. This is not meaningful,
it is wrong. This expression should be executed before. But on the other hand I
like the distinction between control parameters and signal parameters to be passed
to the opcode, even if it is an aopcode. I think it introduces more strict rules for good
programming, and it simplifies perhaps some core opcodes. When I wrote my
saol compiler, I would have liked to see passed to a kparam only numbers or
i-/k-identifiers, not operators. In the end, if I am in an a-rate-guarded block I am
executing on signals, I don't see what meaningful influence can have the expression
in the guard expression on the k-rate expression. But I need controls.
>Your version of gen_allpass (used by the small_room and large_room reverb)
>in elpelele.saol runs on my PII 333 laptop at 400% of real-time. My version
>runs at 15% of realtime. Why? Because I precalculated the arguments to
>fracdelay at i-rate.
This is also what we do in saint, through the intermediate register mechanism.
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.
Best regards,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Laboratory - DE/LSI - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:55 EST