7.15.5 Input-eval-output-loop

Page 267 of 800

Search internet

When the machine enters the input-eval-output-loop, the interface asks the engine to reduce the term t. The term t may be the one formed at machine invocation or it may be the one formed at the end of the previous execution of the loop.

The result of reducing t is supposed to be a list of output messages. The interface then executes the output messages one at a time as follows:

: Exit immediately with return code x. If x is not an integer, exit with return code zero. A quit request has no associated reply.
: Write the vector tree s to standard output. A write request has no associated reply. The write request is the only request which neither kills the machine (as quit does) nor produces a reply.
: Read one byte from standard input. Usually, reading is blocking, but this may be system dependent. Each read request results in a input message. The value of c is the input byte as a one byte string. The value of c is the empty string if reading is non-blocking and no input is available. The value of c is zero if the end of standard input has been reached.
: Write the vector tree s to a file and compile it using gcc, then dynamically load the result. The value of r must be the parse tree of a unary construct. After dynamic loading, one may use the construct r as a request for interfacing to the new code. Each extend request results in an input message. The value of x is the empty vector on success and a vector containing one zero byte on failure. For more on extend requests see the section on the lgcio interface.
: Discard all messages following the Exec and continue with the activities described below.

If the interface manages to execute all output events and does not encounter a quit or exec event, the machine exits with exit code 0.

If the interface encounters an exec request ( p , h ) it proceeds thus:

The value of p must be maptagged. The interface asks the engine to reduce p. During reduction of p there is an upper, system dependent limit on the time and memory the engine may use. Reduction of p may stop because of timeout, memory overflow, or external interrupts. Reduction may also stop because the engine succeeds to reduce p. We shall refer to the latter situation as an exit interrupt so that reduction of p always ends with an interrupt. Then the interface forms the term

$t = h apply << e _ { n } ,, "\ldots" ,, e _ { 1 } >>$

where $e _ { n } ,, "\ldots" ,, e _ { 1 }$ are reply messages. Then the interface reenters the input-eval-output-loop. Replies occur in the reverse order of their associated requests. In particular, $e _ { n }$ is the reply to the exec request.

The exec reply $e _ { n }$ has form

$e _ { n } = exec reply ( I , p ) = << << 0 ,, !"exec" >> ,, I ,, p >>$

The value of I indicates which interrupt has occurred. The value of p equals the value of the p of the exec request, but the value under the maptag may have been reduced. If one reduces the value under the maptag of the p of the exec reply then computation will continue from the point it had reached when the interrupt occurred. In particular, in case I is an exit interrupt then the value under the maptag of p is already on root normal form.

The value of I has form

$I = << << r ,, i >> ,, a _ { 1 } ,, "\ldots" ,, a _ { m } >>$

The values of r and i indicate what kind of interrupt has occurred and $a _ { 1 } ,, "\ldots" ,, a _ { m }$ are possible interrupt parameters.

The predefined interrupts (exit, time, and memory) take no parameters. An exit interrupt << << 0 ,, !"exit" >> >> indicates that p has been reduced. A time interrupt << << 0 ,, !"time" >> >> indicates that execution of p was stopped by a timer. A memory interrupt << << 0 ,, !"memory" >> >> indicates that execution of p ran out of memory. As a minimum, Logiweb machines must support the exit interrupt.

The current lgwam only supports the exit interrupt.

Page 267 of 800

Search logiweb.eu