Re: SDL-News: A question on data transfer

Subject: Re: SDL-News: A question on data transfer
From: Rick Reed TSE (
Date: Thu Oct 11 2001 - 12:24:32 GMT

Become an SDL Forum Society member <>
The originator of this message is responsible for its content.
-----From Rick Reed TSE <> to sdlnews -----

Zhang Yongqian at wrote on 11/07/2000 07:27:

> Hi, SDL experts:
> I have a question about transfer data( variational length ) between SDL
> modules!
> For example:
> There are two modules: A and B. There is a message to be transfered from A to
> B.
> The length of the message is large and unfixed.
> Would you like to give some advice on such problems?
> BTW, I am now use Telegolic TAU.
> I want to malloc a buf in A as buf_A, put the message into the buf_A. Then use
> export/import,
> Is it OK?
> I'll appreciate if you can give some examples!
> Thanks a lot!
> BR,
> Carl Chang
> University of Science&Technology of China
> E-mail:

Dear Mr Chang/Zhang,

If you are using the current (or previous) version of Tau, it is my
understanding that this does not currently support the data as defined in
SDL-2000 (the standard in force since November 1999).

Instead you will either have to use SDL-96 features or proprietary features
of Tau. I think the the OWN REF feature of Tau (see Tau documentation) may
be useful - but is non-standard.

Of course, "malloc" itself is not a feature of SDL-96, and SDL has no
(explicit) concept of memory: there are variables and values but no
locations or memory addresses in SDL. Only processes have "identities" -
which is the nearest SDL comes to memory.

Furthermore, there is no language mechanism in SDL-96 for ensuring that two
processes have any shared memory (though this is implied between two
processes within a block if the deprecated VIEW/REVEAL feature is used: this
feature has now been removed from SDL). Each process instance could run on a
different processor and with its own memory space. SDL can be used for
distributed systems as well as mono-processor, single memory space systems.

Therefore in SDL-96 there is no language mechanism for passing a reference
to some data from one process to another. IMPORT and EXPORT does not achieve
what you want. When a variable is EXPORTed a copy is made in the process
owning the variable of the value contained in the variable. The declaration
of the EXPORTED variable needs space for the normal variable and a shadow
variable for this copy. When another process subsequently asks to IMPORT the
REMOTE variable, a signal is sent from the importer to the exporter
requesting a value, and the reply signal to the importer contains the value
of the shadow copy. Therefore, IMPORT/EXPORT causes the value to be copied
twice and requires space for both copies.

Within the scope of SDL-96 it is more efficient call a REMOTE PROCEDURE that
is EXPORTED in the exporting process and returns the value of the variable.
In this case the value is copied only once (but ignoring any copying to
buffers used for signals).

You mention also that the data is of infixed length. This would have to be a
STRING in SDL-96, unless the data type is defined in ASN.1 and included in
SDL according to Z.105.

It is possible to program around these restrictions: for example passing
addresses around as integers, and using an external C function to reference
the data. However, I would expect the idea is to write as much as possible
in SDL.


With SDL-2000 it becomes possible to write SDL that more closely matches the

SDL-2000 allows the same facilities as ASN.1 for specifying data that
varies: CHOICE, OPTIONAL and DEFAULT, as well a STRING for variable length

SDL-2000 also includes OBJECT data. Instead of using "malloc" the value can
be assigned to an OBJECT variable. An OBJECT is a reference. When an OBJECT
is passed within one process, the referenced value itself is not copied -
only the reference. To ensure that two or more processes have the same
"memory space" they can be encapsulated in another process. The container
process can define data that is shared between the processes.

There can also be shared data at a block (or the system) level, but in this
case the data is encapsulated in an implicit process and reading/writing the
data is by implicit remote procedures. Also in this case, OBJECT parameters
of a SIGNAL cause the referenced value to be copied and a new OBJECT to be
created in the receiver.

Rick Reed -
Tel:+44 1455 55 96 55 Fax:+44 1455 55 96 58 Mob.:+44 7970 50 96 50

--End text from Rick Reed TSE <> to sdlnews --- For extra SDL Forum Society benefits join at <>

This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:49 GMT