Ok. I've made it through Corrigendum 1, and still have questions about
execution of Opcodes and oparrays in conditional expressions.
Although 1.12 goes partway toward adressing ambiguities about execution of
user-defined opcodes, it fails to address the question of how user-defined
opcodes containing mixed-rate statements behave when invoked from inside
conditionals.
Is the following a legal SAOL program?
aopcode aop() {
return (krand(0.5)); // *1*: legal declaration by virtue of COR1 1.12.
}
instr inst() {
asig aIndex;
asig a;
if ((aIndex & 1) == 0) {
a = aop(); // *2*: not illegal according to 5.8.7.6
aIndex = aIndex + 1;
out(kop());
}
}
The question is: is the use of a k-rate opcode inside an a-rate opcode legal
according to 5.8.6.7.6. The section is ambiguous for the following reason.
It is unclear whether enclosing guard statements are determined lexically
(in which case *1* is legal), or determined at execution time (in which case
*1* is illegal).
Further, it needs to be explicitly stated how often krand does get executed.
Possible answer are:
(1) never. It's illegal.
(2) Once every k-cycle regardless of whether the condition in the guard
statement is true or false.
(3) On the first a-rate use of the opcode state in any given k-cycle; not at
all if the opcode state is not referenced (e.g. if the a-rate guard
condition is false for the duration of a particular k-cycle).
My two cents worth.
(1) poses a signficant problem for users of SAOL. It means that user-defined
opcodes change their semantics depending on where they are called from. From
a language design and aesthetics point of view, this strikes me as highly
undesireable.
(2) You know I like this one. This is what sfxx does already. It's not
particularly difficult to implement, and conceptually highly predictable.
(3) It's consistent with the way oparrays work, but.. the oparray case seems
to be a necessary evil. This option is particularly inefficient from a code
generation point of view.
One other consideration: if (2) is accepted as normal behaviour, then the
restriction on use of sub-guard rate opcodes in 5.8.6.7.6 could be lifted as
well.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:11:07 EST