⟦19ff5d4b9⟧

TextFile

T_A_B_L_E_ _O_F_ _C_O_N_T_E_N_T_S_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _P_A_G_E_

1. INTRODUCTION ........................................... 1
1.1 Terminology ....................................... 1

2. PROCESS OVERVIEW ....................................... 9
2.1 Normal Operation .................................. 9
2.2 Initialisation (Open) and Termination (Close)
of an HPLC ........................................ 11
2.2.1 Initialisation ............................. 11
2.2.2 Termination ................................ 12
2.2.2.1 Termination Code .................. 13

3. IMPLEMENTATION DETAILS ................................. 15
3.1 Access to the Port Process: The Hook .............. 15
3.2 Time-Out Protection ............................... 16
3.3 Local Control Probe ............................... 21
3.4 Testoutput ........................................ 21

4. STORE REQUIREMENTS ..................................... 22
4.1 Program ........................................... 22
4.2 Stack (Variables Except Pools) .................... 23
4.3 Pools (Message Store) ............................. 25
4.4 Total Store Requirments ........................... 25

A_P_P_E_N_D_I_X_:

A. REFERENCES ............................................. 27
\f

ii
\f

1_._ _ _ _ _ _ _ _ _I_N_T_R_O_D_U_C_T_I_O_N_ 1.

In the Centernet Terminal Concentrator (TC) the Host Port Module
(HPM) is the part of the Host Interface (HI) that implements the
Host Port Protocol (HPP) (ref. 1). The purpose of the HPP is to
mulitplex a number of individual, bidirectional dataflows on one
Channel Link (CL) between the TC and the Host, in which the
Network Port Module (NPM) does a job similar to the one of the
HPM (ref. 6, 9).

Towards the RC8000 the Front Process Adaptor (FPA) may constitute
the CL when applying the FPA Data Link Control protocol (FDLC)
(Ref. 3, 4). In so far as the handlers are compatible, a
High-Level Data Link Control channel (HDLC) might alternatively
be used (ref. 5).

This manual describes the function and internal structure of the
HPM. The implementation is done in RC3502 Real Time Pascal (ref.
7, 8). The interface towards the user, the so-called
Subscriber (SB) is defined in ref. 2.

1_._1_ _ _ _ _ _ _ _T_e_r_m_i_n_o_l_o_g_y_ 1.1

The following lists the terminology and abbreviations used in
this manual.

ACK Acknowledge. In HPP acknowledge is carried out by
returning a block with YR-REF equal to MY-REF of
the last processed incoming block. ACK may be gi-
ven together with an LT or in a separate block;
in the latter case it may carry a Mode.

CL Channel Link. The data link layer supporting the
HPP. CL provides a reliable, bidirectional data-
path, performing the necessary flow control and
retransmission.
\f

CN Centernet. The network project of which the HI/NI
is a part.

CR Credit. Before an LT can be sent according to the
HPP, CR must be established from the receiving
party. This assures that the necessary resources
(buffers) are at hand when the LT actually
arrives.

FDLC FPA Data Link Control. A CL implemented on the
RC8000 Front Process Adaptor.

HDLC High-level Data Link Control. Another acceptable
CL.

HI Host Interface. The part of the CN software lo-
cated in the TC taking care of the communication
towards the Host computer.

HIA Host Interface Address. Port address identifying
the PT at the TC end.

HIM Host Interface Mapper. The SB of the HPM. Con-
stitutes the link between the HPM and the SC
mapping an HIA into an SC Port Address.

Host Independent computer hosting the applications of
the CN and having access to the network through a
TC.

HPLC Host Port Logical Channel. One of more logical
connections between SBs on each side of the HI/NI
multiplexed on the same physical CL.

HPM Host Port Module. The subpart (actually a Real
Time Pascal child process) of the HI doing the
interpretation of the HPP on the network side.
\f

HPP Host Port Protocol. Protocol multiplexing a num-
ber of individual, bidirectional dataflows on one
CL. Employed between the CN Host and the network,
represented by the TC.

LCP Local Control Probe. The part of the TC modules
(e.g. the HPM) which answers network control
requests and events as monitored by the NCC.

LT Letter. A block carrying information sent through
an HPLC.

Mode User defined value, passed along with an LT or an
ACK. The latter in cases where the ACK signals a
CR (R-bit is 0).

MY-REF My Reference. Sequence number labelling outgoing
LTs.

NCC Network Control Center. CN application monitoring
the network. Initiator of LCP requests and ulti-
mate receiver and LCP events via the NCP.

NCP Network Control Probe. TC module connected to the
NCC whose messages are routed to the LCPs.

NI Network Interface. The part of the CN software
located in the Host taking care of the communi-
cation towards the TC.

NIA Network Interface Address. Port address identify-
ing the PT at the Host end.

NPM Network Port Module. The subpart of the NI doing
the interpretation of the HPP on the Host side.

Opposite Party In connection with the HPM (i.e. throughout this
manual): The NPM or the NPM Subscriber or both.
\f

PT Port. The endpoint of an HPLC.

R-bit Immediate acknowledge Request. Field of every LT
saying if the protocol handler (HPM/NPM) should
immediately produce an ACK (R = 1) or rather
postpone it until receiver CR is again available
(R = 0). In the latter case it is the responsibi-
lity of the SB to produce the necessary resources
for a CR and hence the ACK.

SB Subscriber. The module, process or any other
suitable unit being the user of the HPM/NPM. The
HPM SB is the HIM. The NPM SB are the CN appli-
cations of the particular Host.

SC Session Control. TC module performing session
establishment, monitoring and removal and address
management of the network.

TC Terminal Concentrator. Computer hosting several
modules implementing the CN, e.g. the HI. The TC
represents the network towards the Host.

YR-REF Your Reference. Sequence number of an LT hereby
acknowledged. All earlier blocks are hereby
acknowledged as well.
\f

F_ The communication paths of fig. 1 are implemented by the
declarations:

p_r_o_c_e_s_s_ HPM (v_a_r_ request, channel _link (*..*): semaphore;
(*..*));

t_y_p_e_
PT = r_e_c_o_r_d_
sem (*..*): semaphore;
shad: shadow
e_n_d_;

HIA = 0..no _of _PTs;
portsempoint = a_r_r_a_y_ (HIA) o_f_ r_e_c_o_r_d_
sem _ (*..*): @semaphore
e_n_d_;

v_a_r_
port: a_r_r_a_y_ (HIA) o_f_ PT;
accessparam: portsempoint;
terminator: semaphore;
answerers: shadow;
(*..*)

p_r_o_c_e_s_s_ PT _pros (v_a_r_ request, parent,
channel _link (*..*): semaphore;
(*..*));

v_a_r_
queuein: r_e_c_o_r_d_
fifo: sempahore;
(*..*)
e_n_d_;
(*..*)
b_e_g_i_n_ (*..*) e_n_d_;
\f

p_r_o_c_e_s_s_ answerer (v_a_r_ channel _link, parent (*..*): semaphore;
port: portsempoint);
v_a_r_
answer: semaphore;
(*..*)
b_e_g_i_n_ (*..*) e_n_d_;

p_r_o_c_e_d_u_r_e_ initialise;
b_e_g_i_n_
f_o_r_ i: = 0 t_o_ no _of _PTs d_o_
w_i_t_h_ accessparam(i), port(i) d_o_
b_e_g_i_n_
sem _: = ref (sem);
(*..*)
e_n_d_;

z: = create ('Host _PT _answ',
answerer (channel _link, request, accessparam
(*..*)), answerers, anstore);

(*..*)
e_n_d_;

f_u_n_c_t_i_o_n_ alloc _PT (v_a_r_ i: HIA; (*..*)): boolean;
b_e_g_i_n_
(*..*);
i: = (*..*);
w_i_t_h_ port(i) d_o_
c_a_s_e_ create (*..*),
PT _pros (sem, request, channel _link (*..*)),
shad, store) o_f_
0: alloc _PT: = true;
(*..*)
e_n_d_;
(*..*)
e_n_d_;
\f

p_r_o_c_e_d_u_r_e_ server;
b_e_g_i_n_ (*..*) e_n_d_;

b_e_g_i_n_
initialise;
server
e_n_d_.

F_ 2_._ _ _ _ _ _ _ _ _P_R_O_C_E_S_S_ _O_V_E_R_V_I_E_W_ 2.

2_._1_ _ _ _ _ _ _ _N_o_r_m_a_l_ _O_p_e_r_a_t_i_o_n_ 2.1

The HPM process is subdivided into three cooperating processes,
the server, the answerer and the port process, with the following
duties.

The server is in fact no process in its own right but merely a
procedure called from the main process. The working cycle awaits
messages on the request semaphore, interprets and serves them.
The server does all the communication with the subscribers (SB)
and the NCP (see 3.3) and is moreover responsible of allocating
and disposing ports.

The answerer communicates towards the channel link. All input
messages originate from and return to the answerer, from where it
is rerouted to the proper port process, see below. The answerer
also keeps track of the state of the channel link handler, e.g.
by taking action when the line breaks.

For every HPLC initialised, the server creates and starts an
incarnation of the port process. Subsequently all messages for
that port is routed to the proper process by the server (from the
SB) or the answerer (from the opposite party). Thus it can be
seen that the main responsibility for the normal operation of an
HPLC during its lifetime rests with the actual port process
incarnation.

In the following description of the port process, the name of the
procedure in the program is mentioned in paranthesis at the end
of each paragraph.

When data is sent from the SB, it is queued into a time-out pro-
tected queue in the port process, queue _out, see section 3.2.
From there it is transmitted to the opposite party through the
channel link when the necessary sender credit is present
(sender _CR). A message header allocated within the port process
incarnation in question, a tag, is pushed upon the SB message to\f

make it return to the right place. A sequence number,
outgoing.MY _REF, is put into a header supplied by the SB and
carried on with the data message. MY _REF is counted up 1 modulo
256 (out _LT).

When the "empty" buffer returns from the channel link handler, it
enters another time-out protected queue, queue _in; the tag is
released. The message pends here until it is acknowledged by the
opposite party.

Acknowledge may principally be carried by any incoming block,
i.e. any messages passed from the answerer. By this action the
variables incoming.YR _REF and incoming.CR are updated. Messages
awaiting acknowledge are returned to the SB carrying a possible
mode given by the acknowledge (adjust _flowvalues).

When data is to be received by the SB, a suitable data message
must be signalled as buffer beforehand; this will constitute the
receiver credit. Here it is important to distinquish between
cases where the opposite party requests immediate acknowledge or
not, given by a bit in the operation code from there (R=1 or 0,
respectively). If the acknowledge was done immediately, nothing
is done now except to increase the variable outgoing.CR; it may
be reported to the opposite party (report) whenever appropriate.
The message itself pends at the semaphore rec _CR _buf. Otherwise,
if this message signals an acknowledge of earlier received data,
the variable outgoing.YR _REF must be increased now (by 1 modulo
256). It must furthermore be reported instantly, as the message
will carry a mode to go with the acknowledge. If resources in-
termediately lack for the report, the message pends at the sema-
phore not _CRed until it can be passed to the rec _CR _buf as above
(incredit).

When the data actually arrives through the channel link, the
variable incoming.MY _REF is updated. If immediate acknowledge is
requested, it is furthermore copied into outgoing.YR _REF and
outgoing.CR is decreased (decredit). A buffer is fetched from
rec _CR _buf and the data is copied (copy). The incoming data
message is resignalled to the channel link handler and the SB
message is returned (in _LT).

2_._2_ _ _ _ _ _ _ _I_n_i_t_i_a_l_i_s_a_t_i_o_n_ _(_O_p_e_n_)_ _a_n_d_ _T_e_r_m_i_n_a_t_i_o_n_ _(_C_l_o_s_e_)_ _o_f_ _a_n_ _H_P_L_C_ 2.2

This section contains a verbal explanation of the details of the
initialisation and termination of an HPLC, what is known to the
SBs as the opening and closing of a pair of ports.

At the end of each paragraph the name of the procedure in the
program is mentioned in parenthesis.

2_._2_._1_ _ _ _ _ _I_n_i_t_i_a_l_i_s_a_t_i_o_n_ 2.2.1

An Await Open message is submitted from the SB. It should be
assured that this always proceds the initiative from the opposite
party, as the initialisation otherwise will not succeed. This may
be done by signalling a suitable number of messages before start
of the HPM. The message is queued by the server.

When a block with the operation code of an initialisation is
received from the channel link, it is recognised by the answerer
and routed to the server.

The server now pairs the initialisation block (which was caused
by an open primitive at the opposite party) with an await open
message, if present, copying the contents from the former to the
latter and sends the two messages to the channel link handler and
back to the SB, respectively. If an Await Open message was not
present in the queue, a special semaphore, the terminator,
contains a suitable message to transmit a termination block to
the opposite party (send _TERM). Otherwise a port process is
created and started (send _INIT).

The port is not yet fully allocated, as it has not been accepted
by the local SB. It is in the accepting state. The port process
starts a timer, and if it runs out it will transmit a termination
block and deallocate itself as explained in the following subsec-
tion. If the opening is rejected, the same thing happens. In the
meantime only Supply and Await Initial Credit messages will be
accepted, see ref. 1 or 2 (initialise).
\f

The Await Open message returned to the SB contains the new port
address or Host Interface Address, HIA, being used in subsequent
messages to the HPM. It will therefore be appropriate for the SB
to reuse the message, altering the function code to Accept Open.
When it is received by the server it is passed to the port pro-
cess if it is in the accepting state as explained in section 3.1,
and at the same time the state is altered to present (pass).

At the port process, the message is tagged and used to transmit
an initialisation block to the channel link. From there it will
return to a semaphore again called the terminator, because this
is what it will be used for next time. Now please continue with
the following subsection.

2_._2_._2_ _ _ _ _ _T_e_r_m_i_n_a_t_i_o_n_ 2.2.2

The termination procedure propagates in the opposite direction,
as it is conceived by the port process.

The message from the SB, signalling an Accept Open, is fetched
and used as a means for transmitting a termination block to the
channel link (send _TERM). When a termination block is received
from the opposite party (whether this happens before or after a
block has been sent from here), the state is changed to absent,
which will stop the signalling of messages for this port process.
Then the returning of the message transmitting the outgoing ter-
mination block is awaited from the CL handler; the message will
return as the last of the outstanding transmit messages (termin-
ate).

When the close function is ready to be served, it is time to
clean up and leave the port process. All queues are emptied
(clean _up).

As a "last word" the Close message is signalled to the parent,
i.e. the server. Note that this will not happen before the PT has
been closed and confirmed, i.e. accepted or rejected. This is to
cope with the situation where an opening time-out (2.2.1) occurs
prior to an SB confirmation. As long as the Accept/Reject Open\f

message still rests with the SB it would be dangerous to dispose
of and hence possibly realoccate the port address, see below.

At the server, the close message will cause the port process to
be removed. The port address may now be reused. The close message
is returned to the SB, signalling the closing of the port
(dispose _PT).

2_._2_._2_._1_ _ _ _T_e_r_m_i_n_a_t_i_o_n_ _C_o_d_e_ 2.2.2.1

These codes are used to label a termination block when sent
through an HPLC, see ref. 1. Internally, the termination codes
received from the opposite party are used to distinguish diffe-
rent causes of termination. They are:

0: REQUEST: Normal case. The HPLC was requested closed by the
opposite party.

1: ACCEPT: Error. The HPLC was accepted closed by the opposite
party on request from the HPM. This will only occur
on error conditions.

2: NO-INIT: Should not occur. The opening of an HPLC is hereby
rejected. The initiative for opening, however,
solely rests with the host.

3: ERROR: Error. The error is recognized by the opposite
party.

For internal use is added

4: CL-error: Error. The channel link is disconnected or reset
from the other end. All ports are requested closed
by the answerer, generating this code.

5: simulated: Error. If an accept is not given by the opposite
party a time-out will generate this code. Same
explanation as for accept applies.
\f

6: aborted: Lack of resources. If the accept from the local SB
times out, the opening never completes. This code
is generated when the port process closes itself.
\f

F_ 3_._ _ _ _ _ _ _ _ _I_M_P_L_E_M_E_N_T_A_T_I_O_N_ _D_E_T_A_I_L_S_ 3.

3_._1_ _ _ _ _ _ _ _A_c_c_e_s_s_ _t_o_ _t_h_e_ _P_o_r_t_ _P_r_o_c_e_s_s_:_ _T_h_e_ _H_o_o_k_ 3.1

In order to communicate a port process, the state of the port in
question must be recognised. As this state may simultaneously be
read and altered be the server, the answerer or the port process,
mutual exclusion is implemented by means of a so-called hook.

The hook mechanism resembles a locked room in which someone is
either absent or present. To access the room, a key must be
fetched from a hook, known to all parties. After access the key
is replaced on the hook.

Thus we refine the declaration of chapter 2.

t_y_p_e_ PT = r_e_c_o_r_d_
sem, hook: semaphore;
shad: shadow
e_n_d_

Initially a message is signalled to each hook. The u1 user field
represents the state, which is extended with the one 'accepting',
meaning that the port has been requested by the opposite party
but not yet accepted by the local subscriber. The message is
equipped with a data part in which statistics for Network Control
purposes are stored, see section 3.3.

Now the access control may be programmed as follows:

p_r_o_c_e_d_u_r_e_ pass (v_a_r_ ref: reference;
accessible: s_e_t_ o_f_ present..absent);
v_a_r_ key: reference;
b_e_g_i_n_
ref@.u2:= no _answer;
l_o_c_k_ ref a_s_ h: HPP _format d_o_ i:= h.SOURC;
w_i_t_h_ port(i) d_o_
b_e_g_i_n_
wait (key, hook);
i_f_ key@.u1 i_n_ accessible t_h_e_n_
signal (ref, sem) \f

e_l_s_e_
result (ref, not _open);
signal (key, hook)
e_n_d_
e_n_d_ (*pass*);

3_._2_ _ _ _ _ _ _ _T_i_m_e_-_O_u_t_ _P_r_o_t_e_c_t_i_o_n_ 3.2

In the HPM time-out will occur at 4 different occasions if events
from the surroundings do not happen. They are
Local subscriber does not accept initialisation,
Opposite party does not submit the necessary credit,
Opposite party does not acknowledge letters properly or
Opposite party does not accept termination.

Figure 2: Time-outs.
\f

In Real Time Pascal the mechanism for time supervision of a
process consists of a process, Timer, which is able to return a
message after a given interval of time.

The mechanism suffers from a resource problem, because one
message must be allocated for each running supervision.
Furthermore a message cannot be called back, so you must also
keep track on returning messages which no longer have any
relevance.

It is important that resources are always present (that the pool
of messages for the timer does not empty), if the same process
incarnation does the jobs of allocating and releasing the mes-
sages. Otherwise a deadlock may occur (or you must administer
that it does not occur).

The solution presented here is based on only one message being
sent, which returns relatively soon (after 1 scaleunit, e.g. 1s).
Every time the message is returned, it is immediately resent. As
seen, it does require that the process resonably often examines
the semaphore that is supervised (compared to the scaleunit and
the desired accuracy), i.e. the process should not contain other
effective waiting points.

Messages from the timer must be counted when returning. This is
simple if only one supervision pends at a time. But otherwise a
resource must be allocated for each. A resource is in this case,
however, just a counter, which is only necessary until time-out
or the happening of the event, and which can furhtermore be
demanded supplied from outside.

In our cases of time-outs, they are represented by references to
databuffers. These references must be stored somewhere together
with the associated counters namely the u2 message user field.

The method applies the procedures wait _T, init _T, adjust _T,
set _T, clear _T, the function adjustment _T, two variables t and s
and a message pool.
\f

The conditions of operations are

- The supervisions must not decrease in period.
- The supervisions must be removed from the system in the same
sequence as they arrive. This conditions the use of the justi-
fication mechanism adjust _T, adjustment _T and the variable s.

The procedures are used as follows.

We declare
t_y_p_e_
timer = r_e_c_o_r_d_
sem: @semaphore;
p: p_o_o_l_ 1;
per: real;
t, s: integer
e_n_d_;
v_a_r_ t: timer;

and call
init _T (t, sem, unit)

The semaphore sem may now be supervised with a scaleunit given by
the last parameter.

A supervision is initiated by calling

set _T (t, duration)

where the duration is given in scaleunits. If already one
supervision pends, another should not be initiated. Instead the
pending one must be adjusted when it is finished. For that use a
justification value must be stored:

M_M_m_m_ a : = adjustment _T (t, duration)
P_P_ i
p_p_ \f

Messages are received on sem by the call

wait _T (ref, t)

If time-out occurred ref would be nil. When the time-out occurs
or the supervised event happens as planned, the supervision is
adjusted. If more supervisions are running

M_M_m_m_ adjust (t, a , time-out)
P_P_ i
p_p_
M_M_m_m_ is called, where a represents the new supervision. The last
P_P_ i
p_p_ return parameter shows whether the next time-out is immediately
at hand, i.e. simultaneous with the previous.

If no more supervisions are initiated

clear _T (t)

is called instead.

As mentioned, each supervision is given by a reference to a
message, and we therefore chain these references and the
M_M_m_m_ associated a in a queue:
P_P_ i
p_p_
t_y_p_e_
queue = r_e_c_o_r_d_
fifo: semaphore;
front: reference;
dur: integer;
t: timer
e_n_d_;
\f

p_r_o_c_e_d_u_r_e_ arrive (v_a_r_ ref: reference (*<> nil*);
v_a_r_ q: queue);
(*Queue message and start or prepare timer*)
b_e_g_i_n_
w_i_t_h_ q d_o_
i_f_ nil (front) (*q is empty*) t_h_e_n_
b_e_g_i_n_
front:=:ref;
set _T (t, dur)
e_n_d_
e_l_s_e_
b_e_g_i_n_
ref@.u2:= adjustment _T (t, dur);
signal (ref, fifo)
e_n_d_
e_n_d_ (*arrive*);

p_r_o_c_e_d_u_r_e_ depart (v_a_r_ ref: reference (* = nil*);
v_a_r_ q: queue;
v_a_r_ time _out: boolean);
(*Take message in front of queue, if any, and report if time
is out for the following message*)

b_e_g_i_n_
w_i_t_h_ q d_o_
b_e_g_i_n_
ref:=:front;
i_f_ n_o_t_ passive (fifo) (*More than 1 message in q*) t_h_e_n_
b_e_g_i_n_
sensesem (front, fifo);
adjust _T (t, front@.u2, time _out)
e_n_d_
e_l_s_e_
b_e_g_i_n_
clear _T (t)
time _out:= false
e_n_d_
e_n_d_
e_n_d_ (*depart*)
\f

The point of using u2 is obviously that the user (the owner of
ref) supplies a sufficient amount of variables so that a resource
allocation problem is avoided.

3_._3_ _ _ _ _ _ _ _L_o_c_a_l_ _C_o_n_t_r_o_l_ _P_r_o_b_e_ 3.3

Within the HPM a so-called Local Control Probe, LCP, is imple-
mented, reporting various events happening in the HPM and answer-
ing commands from the network control.

The mechanism in the communication with the Network Control Probe
is explained in ref. 11; the communication takes place through
the semaphore pointer NCP, given as a parameter. The identifica-
tion of the LCP is also given as a parameter.

The events and requests which will be answered by the LCP are
listed in ref. 10.

3_._4_ _ _ _ _ _ _ _T_e_s_t_o_u_t_p_u_t_ 3.4

Apart from the communication with the Network Control mentioned
in section 3.3, the HPM regularly, and primarily at error con-
ditions, sends messages to the operator semaphore, given as a
parameter, suited for display on the debug console.

The parameter is meant to be the system operator semaphore so as
to cause the output to be displayed on the debug console, but any
dummy process simulating the operator will make the HPM work.

If the messages are not removed from the semaphore and returned
properly, the HPM may run out of buffers and hence stop.

Ref. 2 lists and explains the possible texts.
\f

F_ 4_._ _ _ _ _ _ _ _ _S_T_O_R_E_ _R_E_Q_U_I_R_E_M_E_N_T_S_ 4.

The following section lists the necessary store requirements for
the HPM. The reader is warned that the numerical values are
subject to changes as new versions of the program, compiler or
allocator algorithm emerge.

The store requirement may be subdivided into two: the static re-
quirement and the dynamic. By static is meant store requirements,
which are determined at compile time or at least at load time.
Dynamic requirements are those postponed to the creation time of
the incarnations or run time.

Orthogonally, three different kinds of store exist: the program
store, the stack and pools.

The program store is statically allocated and is the same for all
incarnations of the process in question.

The stack requirement for each process is static if the program
does not declare variables of dynamic type, i.e. types in whose
definition a variable occurs. The HPM has no variables of dynamic
type. The number of incarnations of each process is, however,
determined at creation time, and the total stack requirement
therefore becomes dynamic.

The pool requirements follow the stack requirements in that they
must inevitably be static for each process. Pools are allocated
at runtime, i.e. initiating a new incarnation.

4_._1_ _ _ _ _ _ _ _P_r_o_g_r_a_m_ 4.1

The total program space comprises 11 314 bytes of store.

4_._2_ _ _ _ _ _ _ _S_t_a_c_k_ _(_V_a_r_i_a_b_l_e_s_ _E_x_c_e_p_t_ _P_o_o_l_s_)_ 4.2

An important number determining the static stack requirements for
each process is the maximum number of ports for which the HPM is
prepared, given by the constant no _of _PTs. The size of each
variable needed for a port is listed below as given in ref. 8.
The dynamic requirements are determined by the actual number of
opened ports, N, which may be smaller than no _of _PTs. If so, the
space not used may be utilised for something else. The actual
number of ports may be further limited by the Network Control,
see section 3.3. and ref. 10.

The stack also gives room for temporary variables not explicitly
declared in the program text. This space is dependent on the
dynamic procedure call structure, and therefore the most "hungry"
nested chain of procedure calls is listed below for each process.
The numbers given may be found as the "appetite" of the pass 5
summary from the Real Time Pascal compiler.

PT _pros: words

_ _ _exit _ _ _rc 36
exception 21
testout 115
send _TERM 21
terminate 23
initialise 29
PT _pros, main program 1_9_2_
437 or approx. 500 words.

answerer:

The process contains the declaration: Store requirement per PT:
port: portsempoint
t_y_p_e_
HIA = 0..no _of _PTs-1;
portsempoint = a_r_r_a_y_ (HIA) o_f_ r_e_c_o_r_d_
sem _, hook _: @semaphore 4_ _+_ _4_ _b_y_t_e_s_
end 8 bytes = 4 words

words
_ _ _exit _ _ _rc 36
exception 21
testout 115
initialise 27
M_M_m_m_ answerer, main program 109 + no _of _PTs * 4
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
308 + no _of _PTs * 4
or approx. 350 + no _of _PTs * 4 words.

HPM:
The process contains the declaration: Store requirement per PT:
port: a_r_r_a_y_ (HIA) o_f_ PT;
free _PT: a_r_r_a_y_ (HIA) o_f_ HIA; 1
accessparam: portsempoint 8 (see above)

t_y_p_e_
PT = r_e_c_o_r_d_
sem, hook: semaphore; 8 + 8
shad: shadow 12
e_n_d_ _ _ _ _ _ _ _
37 bytes = 18.5 word

words
_ _ _exit _ _ _rc 36
exception 21
testout 115
alloc _PT 53
server 36
M_M_m_m_ HPM, main program 150 + no _of _PTs * 18.5 words
P_P_p_p_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
411 + no _of _PTs * 18.5 words

or approx. 450 + no _of _PTs * 37 d_i_v_ 2 words.

Total stack requirements:

1600 + no _of _PTs * 41 + N * 1000 bytes

where N is the number of actually opened ports.

4_._3_ _ _ _ _ _ _ _P_o_o_l_s_ _(_M_e_s_s_a_g_e_ _S_t_o_r_e_)_ 4.3

The following pools are declared in the port process:
c_o_n_s_t_ LT _buf = 2; ACK _bufs = 1;

tags: p_o_o_l_ LT _bufs + 1 3 * 32 = 96
HPP _head: p_o_o_l_ ACK _bufs o_f_ HPP _buf; 1_ _*_(_3_2_+_6_0_)_ _ _=_ _9_2_
188 bytes

In the answerer process:
c_o_n_s_t_ c = no _of _PTs d_i_v_ 8 + 2;

buffer: p_o_o_l_ c o_f_ maxin; c * (32+2002) = 4068 + no _of _PTs * 254
eventbuf: p_o_o_l_ 1; 1_ _*_ _ _3_2_ _ _ _ _ _ _ _=_ _ _ _3_2_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
4100 + no _of _PTs * 254

In the parent process:

key: p_o_o_l_ no _of _PTs; no _of _PTs *32
HPP _header: p_o_o_l_ 1 o_f_ HPP _buf; 1 *(32+60) = 92
NCPhead: p_o_o_l_ 2; 2 * 32 = 64
NCPconn: p_o_o_l_ 1 o_f_ LCP _conn _type; 1_ _*_(_3_2_+_8_)_ _ _=_ _4_0_ _ _ _ _ _ _ _
196 + no _of _PTs *32

Total pool requirements:

4296 + no _of _PTs * 286 + N * 188

4_._4_ _ _ _ _ _ _ _T_o_t_a_l_ _S_t_o_r_e_ _R_e_q_u_i_r_e_m_e_n_t_s_ 4.4

comprises

17 210 + no _of _PTs * 327 + N* 1188 bytes.

The requirements may be viewed graphically on fig. 3.
\f

Figure 3: Graphic display of HPM store requirements.
\f

F_ A_._ _ _ _ _ _ _ _ _R_E_F_E_R_E_N_C_E_S_ A.

1 RCSL No 43-GL11209:
CENTERNET, Host Port Protocol, Report
Karsten Kynde, May 1981

2 RCSL No 43-GL11414:
CENTERNET, Host Port Module - HPM, Programming Guide
Karsten Kynde, August 1981

3 RCSL No 43-GL11425:
CENTERNET, FPA Data Link Control - FDLC, Reference Manual
Karsten Kynde, September 1981

4 RCSL No 43-GL11413:
CENTERNET, FPA Data Link Control - FDLC, Programming Guide
Karsten Kynde, August 1981

5 RCSL No 43-AA699:
RC3502 COM 201 HDLC Driver, Reference Manual
Harald Villemoes

6 RCSL No 43-GL11417:
CENTERNET, Network Port Module - NPM, Reference Manual
Niels Carsten Jensen, August 1981

7 RCSL No 52-AA964:
PASCAL80, Report
Jørgen Staunstrup, January 1980

8 RCSL No 42-i1542:
RC3502 - PASCAL80, Reference Manual
Bo Bagger Laursen, November 1980

9 RCSL No 43-GL10190:
CENTERNET, System Specifications
April 1980
\f

10 RCSL No 43-GL11418:
CENTERNET, Local Control Probe, Specification Sheets
Peter Bjerregård Lauridsen
(to be published)

11 RCSL No 43-GL11424:
NCP Data Structures, Reference Manual, Revision 1.02
Claus Houlberg Hansen
\f

«eof»

DataMuseum.dk

CP/M

⟦19ff5d4b9⟧ TextFile

Derivation

TextFile