(1) Any study based on benchmarks cannot go far enough.
	- Go into Intro section. (1 or 1.something)

(2) Limited benchmarks because Monsoon doesn't have C & Fortran.
	- goes where (1) goes.

(3) Not a parallelizing compiler; loop bounds equivalent to array
syntax or distribution directives.
	- goes ?

(4) Monsoon has many limitations; university project; no human
resources for caches, 10 MHz.
	- goes into 1 or 1.something too. (i.e. at the beginning)

(5) Fortran & C never a goal.
	- this should go with (2) above.

(6) study of performance of architecture, not implementation.
	- probably goes with justfication of comparing cycles 
	  and not absolute time. (May want to see where the 
	  latter belongs.)

(7) Threaded code is still dataflow, but harder to compile;
    pure dataflow code eaiser to generate; try to convey intellectual
    difficulty of asynchronous execution.
	- I'm not sure if I agree with this.  This depends on what we
	  mean by dataflow.
	- if it has to go somewhere, it is probably the end, when we
	  talk about compiling threaded code.

(8) Loop setting: perhaps some sort of simple default that will allow
most code to run to completion; could not do these studies on a
simulator. 
	- We should consolidate all discussions about loop bound
	  together.  This should go into that section.

(9) Historical aspects:
	* first machine on which we could study resource management.
	  sequentialization of RTS requests.
	* ? ?
	- where? Intro or conclusion?  Probably Intro.

	* how about historical perspective in terms of the dataflow
	  hardware out there?
	
(10) Make more interesting: what is of interest and what is not? 
Make more readable.

*****************************************************************************

Things to be added according to where they should do:

(a) Intro: (1), (2), (4), (5), (9) (maybe 6)

(b) Loop bounds stuff: (3), (8)

(c) Calibration/justification for using cycles: (6)

(d) Conclusion/future work: (7)

*****************************************************************************

Other points to take note of:

(1) Dimensions we persue as comparison criteria.
    * why not compare with super computers such as cray-2.
    * why not compare with other existing dataflow machines?

(2) Claims that we make.
    * Our claim that the machine is indeed able to exploit parallelism
    in symbolic computation is not well justified.  (We should make a
    concession now and wait for results from the Id-in-Id project.)
    * We did not claim that Monsoon is THE dataflow machine.

    * claims about Monsoon's scalability.  We need to make some
    concessions to the effect that we do need to go beyond 8 or 64
    fold parallelism.  This will come when we work with *T.

(3) Formatting of bibliography.

(4) Does the general JPDC readership want to investigate the level of
detail presented?  We think so, but perhaps we should explain why such
an investigation is worthwhile research.  Such detailed understanding
will/does help us in designing the next machine, and to see what to
expect of parallel computation efficiency and speedup.  

(5) Available from ISCA-92 dataflow workshop proceedings?  Not an
issue, but perhaps I should take a look and see what's there.

(6) That threads are *obviously* more efficient than pure dataflow
code?

(7) Shorten the paper?  Unless required by JPDC, I don't think so.  We
can perhaps suggest parts that can be skipped over for readers who
are't interested in certain details.

(8) A referee asks for details about memory type; I think we already
have some of these.  He also ask for details like cycle time, number
of chips, orgranization... ; question pertains to memory heirarchy of
Monsoon.

(9) Pipeline stage complexity of Monsoon  == that of Mips?  We need to
justify.

(10) Why temp regsiters in Monsoon aren't useful.  have to explain
more carefully.

(11) Improvements to sequential loops: why so bad initially, how it is
improved.  Should mention problems introduced by asynchronouse
parallel execution.  Cite Boon's FPCA paper.

(12) Asked for more details about idels, bubbles and identities
related to joins.  "specifically as reards the manner in which these
overheads are incurred by dataflow versus threaded codes, or, for e.g.
idels, long pipeline versus short pipeline machines.  

*****************************************************************************

Goals of the paper: 
	* assess performance of Monsoon.
	* understand short-comings
	* suggest improvements
	* draw implications about parallel computing/data-flow
	  computing in general?