Cross-platform issues

Cross-platform issues

[Leslie]

Hi,

        I'm working on an application that I would like to be capable of
communicating between hosts, and I wonder how the issue of
32-bit vs. 64-bit, and perhaps endianness should best be
handled?

Leslie

Re: Cross-platform issues

[John B. Matthews]

In article <hfeive$315$1@news.albasani.net>,
 Leslie <jlturriff@centurytel.net> wrote:

> I'm working on an application that I would like to be capable of 
> communicating between hosts, and I wonder how the issue of 32-bit vs. 
> 64-bit, and perhaps endianness should best be handled?

I'm guessing that would depend on how much and what kind of data, as 
well as a given compiler's support for representation. Here's an 
example of one vendor's documentation of this:

<http://gcc.gnu.org/onlinedocs/gcc-4.3.4/gnat_rm/Representation-Clauses-a
nd-Pragmas.html#Representation-Clauses-and-Pragmas>

Another approach is to avoid such problems altogether by using Ada Web 
Server (AWS) and defining all communication atop HTTP:

<http://libre.adacore.com/libre/tools/aws/>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Cross-platform issues

[Leslie]

John B. Matthews wrote:

> In article <hfeive$315$1@news.albasani.net>,
>  Leslie <jlturriff@centurytel.net> wrote:
> 
>> I'm working on an application that I would like to be capable
>> of communicating between hosts, and I wonder how the issue of
>> 32-bit vs. 64-bit, and perhaps endianness should best be
>> handled?
> 
> I'm guessing that would depend on how much and what kind of
> data, as well as a given compiler's support for representation.
> Here's an example of one vendor's documentation of this:
> 
>
<http://gcc.gnu.org/onlinedocs/gcc-4.3.4/gnat_rm/Representation-Clauses-a
> nd-Pragmas.html#Representation-Clauses-and-Pragmas>
> 
> Another approach is to avoid such problems altogether by using
> Ada Web Server (AWS) and defining all communication atop HTTP:
> 
> <http://libre.adacore.com/libre/tools/aws/>
> 
        What I'm working on is a product that I want to conform as
closely as possible to the one that inspired it.  The original
emits trace data with things like field length info in 4-byte 
integers, for example. I suppose that using a derived type to
ensure that in my implementation those fields conform with the
original is one way to do it, but is that accepted practice, or
is there a more usual one?

        BTW, I'm just getting into Ada, and the only books I have for
reference were from the early 90s, so at this point my ideas on
how to proceed are a bit vague. :-)

Leslie

Re: Cross-platform issues

[Per Sandberg]

Two good titles
John Barnes: Programming in Ada 2005
Alan Burns & Andy Wellings: Concurrent and Real-Time Programming in Ada
/Per


2009-12-07 00:39, Leslie skrev:
> John B. Matthews wrote:
>
>> In article<hfeive$315$1@news.albasani.net>,
>>   Leslie<jlturriff@centurytel.net>  wrote:
>>
>>> I'm working on an application that I would like to be capable
>>> of communicating between hosts, and I wonder how the issue of
>>> 32-bit vs. 64-bit, and perhaps endianness should best be
>>> handled?
>>
>> I'm guessing that would depend on how much and what kind of
>> data, as well as a given compiler's support for representation.
>> Here's an example of one vendor's documentation of this:
>>
>>
> <http://gcc.gnu.org/onlinedocs/gcc-4.3.4/gnat_rm/Representation-Clauses-a
>> nd-Pragmas.html#Representation-Clauses-and-Pragmas>
>>
>> Another approach is to avoid such problems altogether by using
>> Ada Web Server (AWS) and defining all communication atop HTTP:
>>
>> <http://libre.adacore.com/libre/tools/aws/>
>>
>          What I'm working on is a product that I want to conform as
> closely as possible to the one that inspired it.  The original
> emits trace data with things like field length info in 4-byte
> integers, for example. I suppose that using a derived type to
> ensure that in my implementation those fields conform with the
> original is one way to do it, but is that accepted practice, or
> is there a more usual one?
>
>          BTW, I'm just getting into Ada, and the only books I have for
> reference were from the early 90s, so at this point my ideas on
> how to proceed are a bit vague. :-)
>
> Leslie

Re: Cross-platform issues

[sjw]

On Dec 6, 11:39 pm, Leslie <jlturr...@centurytel.net> wrote:

>         What I'm working on is a product that I want to conform as
> closely as possible to the one that inspired it.  The original
> emits trace data with things like field length info in 4-byte
> integers, for example. I suppose that using a derived type to
> ensure that in my implementation those fields conform with the
> original is one way to do it, but is that accepted practice, or
> is there a more usual one?

I'd start by defining the data to be sent over the net. You could base
your data structures on the types in package Interfaces, then there's
no worry about the size of Interfaces.C.int.

Then I'd format the data to be sent using the stream attribute
('Write, most likely). The simpler your types the less likely is it
that compilers will disagree about the way the data is mapped to the
output stream of octets.

If you're using GNAT, the package GNAT.Sockets provides stream-
oriented interfaces to IP sockets.

Also if you're using GNAT you can transparently convert to/from
network byte order; take the file s-strxdr.adb from your compiler's
Ada library (.../adainclude/), copy to your source directory, rename
to s-stratt.adb, build using gnatmake -a to force local rebuild of the
affected parts of the RTL.

Re: Cross-platform issues

[Randy Brukardt]

"Leslie" <jlturriff@centurytel.net> wrote in message 
news:hfhf9l$2gh$1@news.albasani.net...
...
>        BTW, I'm just getting into Ada, and the only books I have for
> reference were from the early 90s, so at this point my ideas on
> how to proceed are a bit vague. :-)

I suggest that you look at the AdaIC site for a list of resources (including 
books that you can use online or download):

http://www.adaic.com/learn/index.html (general information);
http://www.adaic.com/learn/textbook.html (textbooks of all types);
http://www.adaic.com/free/freebook.html (online textbooks)

                                        Randy Brukardt, AdaIC webmaster

Re: Cross-platform issues

[tmoran]

> closely as possible to the one that inspired it.  The original
> emits trace data with things like field length info in 4-byte
> integers, for example. I suppose that using a derived type to
> ensure that in my implementation those fields conform with the
> original is one way to do it, but is that accepted practice, or
> is there a more usual one?
  Representation clauses and pragmas let you specify machine
characteristics, for instance that a particular field is 4 bytes long.
Types, and derived types, generally have to do with the logical nature of
the data
eg
type Field_Lengths is range 1 .. 64;
type Water_Temperatures is range 32 .. 212;
type Car_Mileages is range 0 .. 400_000;
etc
An item of any of those types would fit in a four byte field, even
though the first two types could fit in a single byte.  In the absence
of a representation clause, the compiler is allowed to choose whatever
it likes.  If you want something *represented* the same on two different
machines, or via two different compilers, use representation clauses.

Re: Cross-platform issues

[Martin]

On Dec 8, 12:33 am, tmo...@acm.org wrote:
> > closely as possible to the one that inspired it.  The original
> > emits trace data with things like field length info in 4-byte
> > integers, for example. I suppose that using a derived type to
> > ensure that in my implementation those fields conform with the
> > original is one way to do it, but is that accepted practice, or
> > is there a more usual one?
>
>   Representation clauses and pragmas let you specify machine
> characteristics, for instance that a particular field is 4 bytes long.
> Types, and derived types, generally have to do with the logical nature of
> the data
> eg
> type Field_Lengths is range 1 .. 64;
> type Water_Temperatures is range 32 .. 212;
> type Car_Mileages is range 0 .. 400_000;
> etc
> An item of any of those types would fit in a four byte field, even
> though the first two types could fit in a single byte.  In the absence
> of a representation clause, the compiler is allowed to choose whatever
> it likes.  If you want something *represented* the same on two different
> machines, or via two different compilers, use representation clauses.

...but not necessarily on the types that you use in the application -
that /can/ have a enormous performance hit. The compiler usually does
a great job of picking the most optimal size for a type that it can.

What you might then consider is deriving types with rep-clauses to,
well, represent the structure you need to be portable (e.g. if it
needs to go 'over a wire').

-- A type perhaps used a lot in an application
type Internal is record
   I : Integer;
   B : Boolean;
   F : Float;
end record;

-- A required external representation but one that might have a large
performance hit
type External is new Internal;
for External use record
   I at 0 range 0 .. 31;
   B at 1 range 0 ..  0;
   F at 2 range 0 .. 31;
end record;

procedure Write_To_Memory (My_Appliaction_Record : Internal) is
   My_Memory_Mapped_Record : Extenal;
   for My_Memory_Mapped_Record'Address use <address>;
begin
   My_Memory_Mapped_Record := External (My_Application_RecorD);
end;

And the compiler fills in the mapping. Note the reverse can be done as
well. This technique work especially well with 'wholey' enums, e.g.

-- Internal 'logical' representaion
type Internal is (Alpha, Beta, Gamma);

-- Required for an external interface
type External in new Internal;
for External ise (Alpha => 1, Beta => 2, Gamma => 4);

If the enumeration is being used to index into arrays a lot then you
will see a big performance hit if you had added the rep-clause to the
Internal type.

Cheers
-- Martin

Re: Cross-platform issues

[Leslie]

Leslie wrote:

> Hi,
> 
>         I'm working on an application that I would like to be
>         capable of
> communicating between hosts, and I wonder how the issue of
> 32-bit vs. 64-bit, and perhaps endianness should best be
> handled?
> 
> Leslie

        I want to thank all of you who responded to my post.  I just
noticed that my previous responses were going to individuals,
not to the list.

Leslie