> It would appear that SAOL makes no provisions for
> showing data in any way, I would think that a printf-like opcode would
> be fairly simple to implement.
Saolc has a set of opcodes for this today, but they aren't part of the
SA standard itself. My plans are to develop a good set of debugging
opcodes for sfront, but until then I'd suggest:
-- Just hack the sa.c files and add the printf()'s into the C code.
Search for variable names of your SAOL program, and it will be pretty
obvious where things are happening.
> 2. Also, how many times will the "while" loop be executed? I am
> trying to get it to execute on the first pass only of the call to the
> instr.
Then you want to use an i-rate guard value for the while loop, and have
all i-rate statements in the while block, and this is the behavior you'll
get. In fact (as described in):
http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/exstat/index.html#while
you'll get a syntax error out of sfront if the rate of the guard and
all of the block statements don't match ... as you've written it, the
while statement runs at k-rate (guard and all block statements are
krate, and so the statement is legal and is a k-rate while statement).
> 3. After reading a few passages in the spec, it would appear that
> calls to any opcode only change at the start of a cycle (ie a k-rate
> opcode will only be called once per k-cycle, subsequent calls in the
> same k-cycle will return the same values).
No, this isn't correct, if you have this loop:
ksig k,i[10];
k = 0;
while (k < 10)
{
i[k] = krand(1);
k = k + 1;
}
you'll get 10 different values in i[0], i[1], ... As written, these
will change every k-cycle too, since k gets reset to 0 and the loop
runs again. Note, however, that if you didn't have the "k = 0;"
statement, it would just run at the first k-pass through -- all
SAOL variables are initialized to zero at instr invocation, but after
the first pass k will have the value of 10, which is will keep forever.
The passages you read were probably referring to dealt with issues
when an a-rate statement contained k-rate calls ... see:
http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/simple/index.html#opcode
and
http://www.cs.berkeley.edu/~lazzaro/sa/book/opcodes/user/index.html#calls
for info how these rules work for core opcodes and user-defined opcodes,
although for your examples this isn't an issue, since you weren't doing
calls like this ...
--jl
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:52 EST