VIEW THE NOTE			       E01
From: SMTP    --IINUS1                      Date and time    01/06/93 08:11:26
 =========================================================================
 Received: from life.ai.mit.edu by vnet.ibm.com (IBM VM SMTP V2R2) with TCP;
    Wed, 06 Jan 93 11:09:41 EST
 Received: from impulse (impulse.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10)
 id AA02680; Wed, 6 Jan 93 11:11:25 EST
 From: gill@ai.mit.edu (Gill Pratt)
 Received: by impulse (4.1/AI-4.10) id AA14947; Wed, 6 Jan 93 11:08:51 EST
 Date: Wed, 6 Jan 93 11:08:51 EST
 Message-Id: <9301061608.AA14947@impulse>
 To: NRDUDA@scrvm2.vnet.ibm.com
 In-Reply-To: NRDUDA@scrvm2.vnet.ibm.com's message of Mon, 4 Jan 93 12:05:22
 PST <9301042006.AB27391@life.ai.mit.edu>


 Here are my comments. The things between -><- are little errors I picked up.
 The things with --- marks are comments.

 I think in general, you are writing to someone who already knows what
 you are doing. You should flesh out the text with more information for
 the totally naive reader. Explain each new term you use, and give
  even more examples.

 In general, I really like it. It sounds like the perfect implementation
 for what it does, although the lack of handling for asynchrony bothers
 me.

 |- Gill

 ...

 environment is to equ->i<-p the generic microprocessor simulator with a

 the target environment as is desired.  SOTEST ->, the system described
 in this thesis, <- is an -><- example

 --- (Hardware simulators) --- How difficult would it be, conceptually,
 to write a conversion program from hardware to your SOTL language?


 --- Can your SOTL language handle arbitration for a common resource by
  asynchronous hardware ? ---

 --- $serial_port_speed; should probably be called serial_port_time, as
 real speed drops as this number gets larger.

 --- What if the time of the serial port device is not divisible by clock
 ticks (this gets back to my question about true asynchrony --

 -- You should explain that there is no guarantee on the order of execution
 between blocked events (i.e. if several events are unblocked, they execute
 in random order, and thus blocks (or other semaphores) must  be used to
 establish order --

 -- Is it reasonable to have your software have a mode of testing all orders
 of thread execution, or is this too hairy? I guess this is mostly for
 finding bugs in the writing of the SOTL program, not the main software.
 As I see it, a subtly timing bug in the SOTL program may be hard to find
 because of the random order phenomena. Any method (proof, spec, exhaustive
 order testing) you can think of that will help flush out such bugs would
 help.  --

 can subscribe ->to<- file descriptor or message queue events.


 ----- How do you efficiently check for event un-blocking? How much
 does this slow down the simulator? What does your simulator spend most
 of its time doing? How fast is it?
 :-) End File gnugo.c Part 0 (-: