Re: Summary - Intel Bit/Byte Order Conversion for Alsys Ada ?

[alex@MIMSY.CS.UMD.EDU (Alex Blakemore)]

Dave Bashford from Loral wrote:

[problems converting different representations of the same record type
 between two computers, found another language more efficient]

> I ended up writing two different format conversion routines, one in Ada
> using generics, and one in "another" language.  The two conversions
> followed different algorithms, and I spent more time optimizing the one
> in "another" language.  ... the only way I could think of to solve
> the problem was to use bit-shifts, masking, and bit-sets, which are
> directly available in "another" language and are implemented with
> bit-arrays whose indices are "backwards" in this Ada compiler.
> 	Test 1. The conversion in Ada took 61.8 seconds.
> 	Test 2. The conversion in "another" language took  8.9 seconds.
> 	Test 3. The no-conversion base-line took 1.3 seconds.

I think there is an easy and efficient way to do
what you ask in Ada83 (and am sure of it in Ada9X)
but its hard to tell from your problem description.

here is a trick you may not be aware of: it may help somewhat.
a derived type can introduce a new rep spec, and then normal Ada conversion
operations not only change the type at compile time, but adjust representation
at run time.  Here's a simple example.

type unpacked_record is -- no rep clause, could have one though
  record
    field1 : integer;
    field2 : colors;
    field3 : boolean;
  end record;

type packed_record is new unpacked_record;

for packed_record use record
    field1 at 0 range ...;
    field2 at 0 range ...;
    field3 at 0 range ...;
end record;

pr  : packed_record;
upr : unpacked_record;

you can then convert between the two types by

pr  := packed_record (upr);  -- this packs
upr := unpacked_record (pr); -- this unpacks

the compiler handles all the shifts, and masks etc.

(you need to be careful to do most of the work in one format or the other,
 its easy to generate lots of conversions without realizing it
 since it just looks a "caste" in lesser languages but actually
 can generate lots of code)

you could have both a Motorola and an Intel type derived
from a common parent type - each with the appropriate rep spec.

I dont think this solves endian problems. for that I'ld try converting
(as above) to a representation that was spacious, and then swapping
any integer bits needed via a tuned assembly/C/machine code routine
and then repacking using the method above. escaping to a low level
language to do something like byte swapping is ok. and byte swapping should
be simple after all the representation related shifting etc is handled
by the compiler.

above all I'ld try to get the compiler to do as much of the complex work
as possible, its safer and probably faster that way. certainly more maintainabl
e.

I dont understand why you need to use generics.
they may add increase the time further.

good luck.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted