Interoperability: differing storage units and/or endianess

Interoperability: differing storage units and/or endianess

[Bibb Latting]

Hi, I am working on a distributed application where the processors
have differing storage unit sizes and/or endianess.  My problem is how
to handle the specification of memory contents and the delivery of
data to applications with minimal variation between implementations. 
I'd like to know what solutions have worked well for others.

Re: Interoperability: differing storage units and/or endianess

[Jeffrey Carter]

Bibb Latting wrote:

> Hi, I am working on a distributed application where the processors
> have differing storage unit sizes and/or endianess.  My problem is how
> to handle the specification of memory contents and the delivery of
> data to applications with minimal variation between implementations. 
> I'd like to know what solutions have worked well for others.

If you can use Annex E (for example, GNAT/GLADE), then this is handled 
for you. If you have to roll your own, you could probably use the 
marshalling/unmarshalling code from GLADE to achieve this.

The basic idea is to pick a representation for transmission, and ensure 
that every box converts to this representation before transmission, and 
converts from this representation after reception.

-- 
Jeff Carter
"Apart from the sanitation, the medicine, education, wine,
public order, irrigation, roads, the fresh water system,
and public health, what have the Romans ever done for us?"
Monty Python's Life of Brian
80

Re: Interoperability: differing storage units and/or endianess

[Michael Paus]

Bibb Latting wrote:

> Hi, I am working on a distributed application where the processors
> have differing storage unit sizes and/or endianess.  My problem is how
> to handle the specification of memory contents and the delivery of
> data to applications with minimal variation between implementations. 
> I'd like to know what solutions have worked well for others.

And I'd like to know which currently used processors have a storage
unit size other than 8.

Michael

Re: Interoperability: differing storage units and/or endianess

[Stephen Leake]

Michael Paus <pausnospam@nospamib-paus.com> writes:

> Bibb Latting wrote:
> 
> > Hi, I am working on a distributed application where the processors
> > have differing storage unit sizes and/or endianess.  My problem is how
> > to handle the specification of memory contents and the delivery of
> > data to applications with minimal variation between implementations.
> > I'd like to know what solutions have worked well for others.
> 
> And I'd like to know which currently used processors have a storage
> unit size other than 8.

Many DSPs use 16 bit words.

-- 
-- Stephe

Re: Interoperability: differing storage units and/or endianess

[Michael Paus]

Stephen Leake wrote:

> Michael Paus <pausnospam@nospamib-paus.com> writes:
> 
> 
>>Bibb Latting wrote:
>>
>>
>>>Hi, I am working on a distributed application where the processors
>>>have differing storage unit sizes and/or endianess.  My problem is how
>>>to handle the specification of memory contents and the delivery of
>>>data to applications with minimal variation between implementations.
>>>I'd like to know what solutions have worked well for others.
>>
>>And I'd like to know which currently used processors have a storage
>>unit size other than 8.
> 
> 
> Many DSPs use 16 bit words.

Interesting! I haven't worked with DSPs for a very long time. Could
you tell me how they map, e.g. a character. Does it always have
16 bits or don't they have the type character at all anymore?

Michael

Re: Interoperability: differing storage units and/or endianess

[Petter Fryklund]

UNISYS 2200 and followers has 36 bit words usually diveded into 4 x 9
bit bytes or 6 x 6.

Re: Interoperability: differing storage units and/or endianess

[Martin Dowie]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:li6Zb.293$aT1.271@newsread1.news.pas.earthlink.net...
> Bibb Latting wrote:
>
> > Hi, I am working on a distributed application where the processors
> > have differing storage unit sizes and/or endianess.  My problem is how
> > to handle the specification of memory contents and the delivery of
> > data to applications with minimal variation between implementations.
> > I'd like to know what solutions have worked well for others.
>
> If you can use Annex E (for example, GNAT/GLADE), then this is handled
> for you. If you have to roll your own, you could probably use the
> marshalling/unmarshalling code from GLADE to achieve this.
>
> The basic idea is to pick a representation for transmission, and ensure
> that every box converts to this representation before transmission, and
> converts from this representation after reception.

Another thing to consider is the relative processing power and system
demands of the nodes on the network. I worked on one system which
used an Alpha and a PowerPC. The PowerPC had little spare processing
time and the Alpha was _much_ quicker_, so we did all conversions on the
Alpha.

You could set up lookup tables and index them based on 'source' and
'destination' and thus keep all the transforms in one set of source code.

Cheers

-- Martin

Re: Interoperability: differing storage units and/or endianess

[Dmitry A. Kazakov]

On Fri, 20 Feb 2004 11:54:02 +0100, Michael Paus
<pausnospam@nospamib-paus.com> wrote:

>Stephen Leake wrote:
>
>> Michael Paus <pausnospam@nospamib-paus.com> writes:
>> 
>>>Bibb Latting wrote:
>>>
>>>>Hi, I am working on a distributed application where the processors
>>>>have differing storage unit sizes and/or endianess.  My problem is how
>>>>to handle the specification of memory contents and the delivery of
>>>>data to applications with minimal variation between implementations.
>>>>I'd like to know what solutions have worked well for others.
>>>
>>>And I'd like to know which currently used processors have a storage
>>>unit size other than 8.
>> 
>> Many DSPs use 16 bit words.
>
>Interesting! I haven't worked with DSPs for a very long time. Could
>you tell me how they map, e.g. a character. Does it always have
>16 bits or don't they have the type character at all anymore?

Do you mean Ada or C? In Ada the type Character need not to be
aliased. As for C, I remotely remember a DSP compiler that used 32
bits per char. It is allowed in ANSI C, AFAIK.

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: Interoperability: differing storage units and/or endianess

[Randy Brukardt]

"Petter Fryklund" <petter.fryklund@atero.se> wrote in message
news:95234e08.0402200443.1dbc7aa3@posting.google.com...
> UNISYS 2200 and followers has 36 bit words usually diveded into 4 x 9
> bit bytes or 6 x 6.

Right. We did a version of Janus/Ada 95 for that machine a few years back. I
don't know if they're still maintaining it. We ended up using a storage unit
of 9 with strong alignment requirements so that strings packed naturally.
'twas very interesting to build the bootstrap cross-compiler on Intel-based
Unix boxes (we were always a bit short...)

             Randy.

Re: Interoperability: differing storage units and/or endianess

[Steve]

Check out:
  http://www.ietf.org/rfc/rfc1832.txt
For a description of XDR.
It is close to what we use for specifying data in our distributed
application.

Steve
(The Duck)


"Bibb Latting" <bibb.latting@cox.net> wrote in message
news:9fb7e8e1.0402190429.49b37b16@posting.google.com...
> Hi, I am working on a distributed application where the processors
> have differing storage unit sizes and/or endianess.  My problem is how
> to handle the specification of memory contents and the delivery of
> data to applications with minimal variation between implementations.
> I'd like to know what solutions have worked well for others.