Version 0.42 09/19/99 of sfront available for
pickup at:
http://www.cs.berkeley.edu/~lazzaro/sa/
From the change log:
Version 0.42 -- 09/19/99
[1] Rate optimization added
to sfront -- slower-rate
subexpressions are factored
out and executed in a slower
pass. Default is complete
optimization, new flags
control turning off parts of
the optimizer.
[2] Fixed dsound code generation
bugs (but not underlying sound
generation bugs). Thanks to
Michael Gogins.
The speedups available from the rate-optimization
pass is very program dependent -- a SAOL program that
benefits from the addition is version of pc.saol shipped
in sfront/examples/pc. Sfront 0.41 yielded this run time:
/usr/bin/time -p ./sa
real 88.99
user 88.56
sys 0.30
whereas sfront 0.42 yields:
/usr/bin/time -p ./sa
real 64.27
user 63.89
sys 0.18
These gains primarily come from the factoring
out the core opcode calls to cpsoct in these lines on
pc.saol:
a1 = oscil ( t1 , cpsoct ( ( i1 / 3 ) + k3 ) , - 1 ) ;
a2 = buzz ( cpsoct ( i1 ) , i5 , p7 - 1 , k2 ) ;
in instr smallgong and
a1 = oscil ( t1 , 0.7 * cpsoct ( i1 ) , - 1 ) ;
a2 = buzz ( cpsoct ( k4 ) , i9 , ( p7 - 1 ) , k2 ) * a6 ;
a3 = buzz ( p12 + cpsoct ( k4 ) , i9 , ( p7 - 1 ) , k2 ) * a6 ;
in instr medgong.
Search your sa.c files for "_tvr" to see the
optimizations in practice. On this first implementation,
the optimizer gives up on some of the "harder" cases --
cases where its not trivial to show that moving a k-rate
subexpression of an a-rate expression to k-rate does not
alter the semantics. The goal right now is to do first
implementations of the various classes of optimizations
like rate optimization, and then do a second pass to
be less conservative on the hard cases ...
--jl
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:37 EDT