Re: inchan/outchan vs inchannels/outchannels

From: John Lazzaro (lazzaro@cs.berkeley.edu)
Date: Sun Oct 17 1999 - 15:15:19 EDT


> inchan and outchan are standard names representing the number of input and
> output channels for the current scope. they can be used in any place an ivar
> is valid.

outchan sets the number of channels in the entire orchestra, not of the
scope (see:

http://www.cs.berkeley.edu/~lazzaro/sa/book/saol/bus/index.html#standard

or page 54 of the spec, 5.8.6.8.5. inchan works as you describe, including
coding the input width of the entire orchestra when used in the global
block (as part of, for example, an expression in a table or send statement).

> inchannels and outchannels are special tokes used only in array declarations
> to indicate that an array has the same number of elements as inchan or
> outchan respectively.

-- When used to specify the width of a parameter in a user-defined opcode,
outchannels indicates the width of the entire SAOL orchestra (defaults
to 1, may be altered by a global parameter), and so this is correct given
the description of outchan above. However, in variable declarations in
instr and opcodes, outchannels codes the width of the instr, which may
not necessarily be the same as outchan.

In the global block, using outchannels and inchannels as array specifiers
results in arrays the size of outchan and inchan. These actual values
are set by setting the global parameters, which also use the token names
inchannels and outchannels, i.e.

global {

outchannels 2;
inchannels 1;
ivar a[inchannels], b[outchannels];

}

shows both usages of the tokens outchannels and inchannels.

I believe this is correct, if there's an error hopefully Eric will
chime in and correct it ...

                                                                --jl

P.S. Sfront implements this all correctly, I believe, although one of
the real problems with having so few SAOL programs in existence is that
its hard to test all the edge cases ...



This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 11:46:35 EST