> I have a been working on changing some opcodes to use the updated
> functionality, and have run across something I can't quite understand.
I wish this were an sfront bug, but unfortunately its one of the
remaining kinks in polymorphic table-relate core opcode rate
semantics. I ran up against this when I was doing QA for the sfront
release too ... here's what's going on:
> kopcode eg_table(ksig release, ivar ratescale, table rates, table levels) {
> ivar stages;
>
> stages = ftlen(rates);
Ftlen is a polymorphic core opcode, and its rate is determined by this
part of 5.8.7.7.2:
The rate of an "opcode" opcode for a particular call is the rate of the
fastest actual parameter expression (not formal parameter expression) in
the call, or the rate of the fastest formal parameter in the opcode
definition, or the rate of the fastest guarding if, while, or else
expression surrounding the opcode call, or the rate of the opcode
enclosing the opcode call, whichever is fastest. If an "opcode" opcode
has no non-table parameters, and is not enclosed in a guarded block or
an opcode call, IT IS A KOPCODE BY DEFAULT (emphases mine).
---
As noted by the all-caps section, for the code you wrote, none of
the rules in the quoted paragraph hold, and so you get the default --
ftlen() is a kopcode, which you are assigning to the ivar stages,
and so you get a rate error. The fix is trivial:
if (1) { stages = ftlen(rates); }
There are other classes of this type of behavior lurking in the standard
also, all involving table core opcodes ... some have syntax error
consequences, the trickier ones have semantic consequences, like
table t(empty, 100);
ksig k1, k2;
tablewrite(t, 0, k1);
k2 = tableread(t, 0);
Tablewrite and tableread are polymorphic -- the tablewrite call becomes
a kopcode, because k1 is a ksig, and so location 0 of t gets updated
every k-cycle. The tableread call, however, is a iopcode, and so by
the new semantics of slower-rate opcode calls, is only supposed to be
executed once, the first time it runs. So, non-intuitively, the table
read does not see updated values of t, but if you did:
table t(empty, 100);
ksig k1, k2, k3;
tablewrite(t, 0, k1);
k3 = 0;
k2 = tableread(t, 0, k3);
It would work as one would naively expect. I was considering making
sfront aware of this special case and either "do what the programmer
meant" or at least print a warning message, but I can't remember if
that got into sfront 0.70 or not ...
But in the long run, its clear that the topic of tables + polymorphism
needs a bit more work to be a really optimal language definition ...
-------------------------------------------------------------------------
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