Hi byte and Lo Byte Question

Hi byte and Lo Byte Question

[mop]

I need to parse data into hi byte and lo byte. Does Ada have some built in
macros or .... I could use?  From the looks of it no.

here's the C version .... Need the Ada version as am new to Ada.

lo = LOBYTE(Value);   -- need Ada version for this LOBYTE macro
hi = HIBYTE(Value);    -- need Ada version for this HIBYTE macro
WORD.Data.Word5_Data_Value_In_HB_LB_Order[0] = hi;
WORD.Data.Word5_Data_Value_In_HB_LB_Order[1] = lo;

Re: Hi byte and Lo Byte Question

[Larry Kilgallen]

In article <9m0gn6$b6j$1@zeus.orl.lmco.com>, "mop" <mop65715@pegasus.cc.ucf.edu> writes:
> 
> I need to parse data into hi byte and lo byte. Does Ada have some built in
> macros or .... I could use?  From the looks of it no.

Check the section on "Representation clauses" in your Ada text.

> here's the C version .... Need the Ada version as am new to Ada.
> 
> lo = LOBYTE(Value);   -- need Ada version for this LOBYTE macro
> hi = HIBYTE(Value);    -- need Ada version for this HIBYTE macro
> WORD.Data.Word5_Data_Value_In_HB_LB_Order[0] = hi;
> WORD.Data.Word5_Data_Value_In_HB_LB_Order[1] = lo;

Re: Hi byte and Lo Byte Question

[Ted Dennison]

In article <9m0gn6$b6j$1@zeus.orl.lmco.com>, mop says...
>I need to parse data into hi byte and lo byte. Does Ada have some built in
>macros or .... I could use?  From the looks of it no.

You mean attributes or subprograms of course. Ada has no macros (which I am
quite happy about).

>here's the C version .... Need the Ada version as am new to Ada.
>
>lo = LOBYTE(Value);   -- need Ada version for this LOBYTE macro
>hi = HIBYTE(Value);    -- need Ada version for this HIBYTE macro
>WORD.Data.Word5_Data_Value_In_HB_LB_Order[0] = hi;
>WORD.Data.Word5_Data_Value_In_HB_LB_Order[1] = lo;

This doesn't tell us much. What do these macros do *exactly*? If it has
something to do with byte values in multi-byte words, how does what they do
differ on big-endian and little-endian machines?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Hi byte and Lo Byte Question

[Mark Johnson]

mop wrote:

> I need to parse data into hi byte and lo byte. Does Ada have some built in
> macros or .... I could use?  From the looks of it no.
>

Let's assume you have a two byte unsigned integer. You want to get the two
bytes out of it. At least two ways come to mind...
[1] The "C" way - see below.
[2] An unchecked conversion from a 16 bit integer to a [record or] array of
two bytes.
and there can certainly be others.
As Ted mentioned, you don't mention byte order as being significant. Since
you are porting from C however, I'll assume you want to treat the 16 bit
value as an integer & get the "low byte" to refer to the least significant 8
bits - no matter what machine you run this on.

>
> here's the C version .... Need the Ada version as am new to Ada.
>
> lo = LOBYTE(Value);   -- need Ada version for this LOBYTE macro
> hi = HIBYTE(Value);    -- need Ada version for this HIBYTE macro
> WORD.Data.Word5_Data_Value_In_HB_LB_Order[0] = hi;
> WORD.Data.Word5_Data_Value_In_HB_LB_Order[1] = lo;

I guess I can assume...
#define LOBYTE(Value) (Value&0xff)
#define HIBYTE(Value) (Value >>8)
if Value is unsigned, or if Value might be signed...
#define HIBYTE(Value) ((Value >>8)&0xff)
The "C" way in Ada would be to do the same arithmetic in a function. In Ada
95, modular types work great on this. If you think you have a stupid
optimizer - use pragma Inline to expand it in line. Yes, it is ten lines of
text instead of two, but in this case, GNAT will generate pretty much the
same code as gcc will do for C.

I'll leave the unchecked conversion as an exercise. I don't recommend it due
to the byte order problem. Also, you generally use Ada to use strong typing,
not get away from it.
  --Mark

Re: Hi byte and Lo Byte Question

[Darren New]

> #define LOBYTE(Value) (Value&0xff)
> #define HIBYTE(Value) (Value >>8)

Why not (value % 256) and (value / 256)? Or the Ada equivalent?

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
           When was sliced bread invented?

Re: Hi byte and Lo Byte Question

[Mark Johnson]

Darren New wrote:

> > #define LOBYTE(Value) (Value&0xff)
> > #define HIBYTE(Value) (Value >>8)
>
> Why not (value % 256) and (value / 256)? Or the Ada equivalent?
>

They work, along with several others. I picked the ones w/ mask & shifts
because older compilers tend to generate good code for them [the
examples you provide require the compiler to detect division by a power
of two and convert...].

[OT] As a side note, there was a pretty interesting discussion on the
Linux kernel mailing list about min & max & the new "incompatible"
version that requires the data type to do the comparison. Apparently
this came from the discovery of several independent definitions of the
min & max functions [sigh]. NIH lives on.
  --Mark

Re: Hi byte and Lo Byte Question

[Darren New]

> They work, along with several others. I picked the ones w/ mask & shifts
> because older compilers tend to generate good code for them [the
> examples you provide require the compiler to detect division by a power
> of two and convert...].

I was using C compilers under CP/M that could handle this, so it
couldn't be *that* hard. :-)

I like it because it's symetric in the case of non-binary bases.

high_digit := (value mod 10)
low_digit  := (value / 10)

-- 
Darren New / Senior MTS & Free Radical / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand. dnew@san.rr.com
           When was sliced bread invented?

Re: Hi byte and Lo Byte Question

[Robert Dewar]

Mark Johnson <mark_h_johnson@raytheon.com> wrote in message news:<3B850FA6.21711F4@raytheon.com>...
> They work, along with several others. I picked the ones w/ mask & shifts
> because older compilers tend to generate good code for them [the
> examples you provide require the compiler to detect division by a power
> of two and convert...].

But shifts and masking operations don't exist in Ada 83!

So "older compilers" won't get far that way (and in any case, a
compiler that does not recognize division by powers of 2 is a bit
creaky -- are there really such?)

Re: Hi byte and Lo Byte Question

[Martin Dowie]

> But shifts and masking operations don't exist in Ada 83!

Unless you consider arrays of booleans to allow masking. If
a compiler managed to optimise that, I would definitely consider
that to be pretty smart! :-)

Re: Hi byte and Lo Byte Question

[Marin David Condic]

If you are working with Modular types, its not too hard. Two examples below
compile and specifically work with Interfaces.Unsigned_16. They could be
modified or made generic with some effort if a more general solution is
desired.

with Interfaces ;

use Interfaces ;

function High_Byte (
    Value    : in     Interfaces.Unsigned_16) return Interfaces.Unsigned_16
is
begin
    return Interfaces.Shift_Right (
        Value     => (Value and 16#FF00#),
        Amount    => 8) ;
end High_Byte ;

with Interfaces ;

use Interfaces ;

function Low_Byte (
    Value    : in     Interfaces.Unsigned_16) return Interfaces.Unsigned_16
is
begin
    return (Value and 16#00FF#) ;
end Low_Byte ;




Here's a proposition worth discussing:

In a lot of embedded apps and/or other apps that need to deal with things
like communication streams, it would be very handy to be able to easily
translate whatever data you have into raw bytes or turn raw bytes into the
data you want. You typically need to do this efficiently and don't want to
move the data. You can certainly get there with Unchecked_Conversion, but
this can be a pain in the ASCII and might be inefficient - requiring the
data to be moved. You can also get there by laboriously creating your own
overlays - but this can rewuire a lot of declaring if you have a lot of
things you want to treat as raw bytes.

What about an attribute of any type that yields an array of
Ada.Streams.Stream_Element_Array ? Similarly, going in the other direction:

for X in My_Type'Raw_Data (My_Data)'Range loop
    Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ;
end loop ;

or

Some_Field := My_Type'Overlay (Some_Stream_Element_Array).Other_Field ;

Maybe it should be an attribute of an Object rather than a Type? Don't know
what can be done about safety in the event that the sizes don't line up, but
I'll leave that to the compiler guys.

I'm not fussy about the details (like the names) but it sure would be nice
to have a means of very easily, efficiently and quickly treating any object
as a stream of bytes - with the caveat being that I've just removed the
safety net (as with Unchecked_Conversion) and I can now royally shoot myself
in the foot.

Comments?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Mark Johnson" <mark_h_johnson@raytheon.com> wrote in message
news:3B843C0C.9A3282B@raytheon.com...
> mop wrote:
>
> > I need to parse data into hi byte and lo byte. Does Ada have some built
in
> > macros or .... I could use?  From the looks of it no.
> >
>
> Let's assume you have a two byte unsigned integer. You want to get the two
> bytes out of it. At least two ways come to mind...
> [1] The "C" way - see below.
> [2] An unchecked conversion from a 16 bit integer to a [record or] array
of
> two bytes.
> and there can certainly be others.
> As Ted mentioned, you don't mention byte order as being significant. Since
> you are porting from C however, I'll assume you want to treat the 16 bit
> value as an integer & get the "low byte" to refer to the least significant
8
> bits - no matter what machine you run this on.
>
> >
> > here's the C version .... Need the Ada version as am new to Ada.
> >
> > lo = LOBYTE(Value);   -- need Ada version for this LOBYTE macro
> > hi = HIBYTE(Value);    -- need Ada version for this HIBYTE macro
> > WORD.Data.Word5_Data_Value_In_HB_LB_Order[0] = hi;
> > WORD.Data.Word5_Data_Value_In_HB_LB_Order[1] = lo;
>
> I guess I can assume...
> #define LOBYTE(Value) (Value&0xff)
> #define HIBYTE(Value) (Value >>8)
> if Value is unsigned, or if Value might be signed...
> #define HIBYTE(Value) ((Value >>8)&0xff)
> The "C" way in Ada would be to do the same arithmetic in a function. In
Ada
> 95, modular types work great on this. If you think you have a stupid
> optimizer - use pragma Inline to expand it in line. Yes, it is ten lines
of
> text instead of two, but in this case, GNAT will generate pretty much the
> same code as gcc will do for C.
>
> I'll leave the unchecked conversion as an exercise. I don't recommend it
due
> to the byte order problem. Also, you generally use Ada to use strong
typing,
> not get away from it.
>   --Mark
>
>

Re: Hi byte and Lo Byte Question

[Peter Dulimov]

This is a really good idea.
I have spent a lot of time doing this manually, and inefficiently (in terms of
produced code, as well as the speed at which I produce it), in Ada83 (so not
even modular types available.)
Also, the original poster's problem --- switching byte order --- becomes easy.

Cheers,

Peter Dulimov.

Marin David Condic wrote:

[snip - stuff deleted]

> Here's a proposition worth discussing:
>
> In a lot of embedded apps and/or other apps that need to deal with things
> like communication streams, it would be very handy to be able to easily
> translate whatever data you have into raw bytes or turn raw bytes into the
> data you want. You typically need to do this efficiently and don't want to
> move the data. You can certainly get there with Unchecked_Conversion, but
> this can be a pain in the ASCII and might be inefficient - requiring the
> data to be moved. You can also get there by laboriously creating your own
> overlays - but this can rewuire a lot of declaring if you have a lot of
> things you want to treat as raw bytes.
>
> What about an attribute of any type that yields an array of
> Ada.Streams.Stream_Element_Array ? Similarly, going in the other direction:
>
> for X in My_Type'Raw_Data (My_Data)'Range loop
>     Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ;
> end loop ;
>
> or
>
> Some_Field := My_Type'Overlay (Some_Stream_Element_Array).Other_Field ;
>
> Maybe it should be an attribute of an Object rather than a Type? Don't know
> what can be done about safety in the event that the sizes don't line up, but
> I'll leave that to the compiler guys.
>
> I'm not fussy about the details (like the names) but it sure would be nice
> to have a means of very easily, efficiently and quickly treating any object
> as a stream of bytes - with the caveat being that I've just removed the
> safety net (as with Unchecked_Conversion) and I can now royally shoot myself
> in the foot.
>
> Comments?
>
> MDC

Re: Hi byte and Lo Byte Question

[Warren W. Gay VE3WWG]

Peter Dulimov wrote:

> This is a really good idea.
> I have spent a lot of time doing this manually, and inefficiently (in terms of
> produced code, as well as the speed at which I produce it), in Ada83 (so not
> even modular types available.)
> Also, the original poster's problem --- switching byte order --- becomes easy.
...


>>What about an attribute of any type that yields an array of
>>Ada.Streams.Stream_Element_Array ? Similarly, going in the other direction:
>>
>>for X in My_Type'Raw_Data (My_Data)'Range loop
>>    Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ;
>>end loop ;
>>
>>or
>>
>>Some_Field := My_Type'Overlay (Some_Stream_Element_Array).Other_Field ;
...


>>Comments?


I see where you're going on the "efficiency" argument, but ignoring that
for a moment, what about a different approach..

Someone could craft an Ada subset (declaration) language, that is
compiled by a small compiler (like a CORBA IDL compiler), and
generates a resulting package body and spec, in existing Ada95
terms to accomplish what you want.

A better way might be to use ASIS with the necessary "code" added to
generate your packages (some commercial venture has probably already
done this at some point).


Of course, the draw back to this approach is that you don't avoid the
data copying that would be required by the generated code. The advantage
however, would be to keep the language from growing in size. If you
look at:

 >>for X in My_Type'Raw_Data (My_Data)'Range loop
 >>    Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ;
 >>end loop ;


there is some data copying on a Some_Storage_Element basis anyway.

Unless Ada0Y were to gain endian representation features, I think
a certain amount of copying (internal or external) would be
necessary anyway. But I have to admit, that a representation
clause for endianess would be extremely convenient. Then at least
the compiler can do it in the most effective manner for the
platform it was compiled on.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Hi byte and Lo Byte Question

[Marin David Condic]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B867ECA.80502@home.com...
>
> I see where you're going on the "efficiency" argument, but ignoring that
> for a moment, what about a different approach..
>
> Someone could craft an Ada subset (declaration) language, that is
> compiled by a small compiler (like a CORBA IDL compiler), and
> generates a resulting package body and spec, in existing Ada95
> terms to accomplish what you want.
>
> A better way might be to use ASIS with the necessary "code" added to
> generate your packages (some commercial venture has probably already
> done this at some point).
>

I'd really hate to have to be running some sort of preprocessor just to get
automatic creation of all the Unchecked_Conversions I might want. This would
be more painful than simply creating the Unchecked_Conversion or declaring
an overlay of a Stream_Element_Array on top of all the types I might want to
convert.

You aren't really extending the language per se. You're just adding another
type/object attribute, so syntactically it remains the same. I believe
implementations might have some latitude to create attributes like this and
not be in violation of the standard, so it could be an extension without a
language update.


>
> Of course, the draw back to this approach is that you don't avoid the
> data copying that would be required by the generated code. The advantage
> however, would be to keep the language from growing in size. If you
> look at:
>
>  >>for X in My_Type'Raw_Data (My_Data)'Range loop
>  >>    Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ;
>  >>end loop ;
>
>
> there is some data copying on a Some_Storage_Element basis anyway.
>

But no motion of My_Data to some intermediate structure just to be able to
treat it as bytes. The Some_Storage_Element part was just there to
demonstrate something syntactically correct. The important part is the
My_Type'Raw_Data (My_Data) (X) part. You can reference all the bytes of
My_Data without having to do:

Another_Block_Of_Data := My_Unchecked_Conversion (My_Data) ;

which requires allocation of two objects instead of one *and* requires
motion of the data from one place to the other (o.k. not if you pull stunts
with pointers, but thats a side issue.) **and** requires an appropriate
instantiation of Unchecked_Conversion ***AND*** has to be done for each and
every data type that you want to turn into a stream. Gimme the raw bytes in
an easy manner and I promise not to blame Ada when I shoot myself in the
foot.



> Unless Ada0Y were to gain endian representation features, I think
> a certain amount of copying (internal or external) would be
> necessary anyway. But I have to admit, that a representation
> clause for endianess would be extremely convenient. Then at least
> the compiler can do it in the most effective manner for the
> platform it was compiled on.

What's wrong with ARM 13.5.3 Bit Ordering and using "for X'Bit_Order use
High_Order_First ;" and similar (Low_Order_First )? I'm pretty sure that
should work and do what you want - never needed to mess with it myself -
yet. (Day ain't over, yet!)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

Re: Hi byte and Lo Byte Question

[Warren W. Gay VE3WWG]

Marin David Condic wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
> news:3B867ECA.80502@home.com...
> 
>>I see where you're going on the "efficiency" argument, but ignoring that
>>for a moment, what about a different approach..
>>
>>Someone could craft an Ada subset (declaration) language, that is
>>compiled by a small compiler (like a CORBA IDL compiler), and
>>generates a resulting package body and spec, in existing Ada95
>>terms to accomplish what you want.
>>
>>A better way might be to use ASIS with the necessary "code" added to
>>generate your packages (some commercial venture has probably already
>>done this at some point).
> 
> I'd really hate to have to be running some sort of preprocessor just to get
> automatic creation of all the Unchecked_Conversions I might want. This would
> be more painful than simply creating the Unchecked_Conversion or declaring
> an overlay of a Stream_Element_Array on top of all the types I might want to
> convert.


I wasn't suggesting a pre-processor, although the "tool" could be used
that way. I was just suggesting a tool that took Ada declarations, and
did the grunt work for you (a one-shot deal).  After that, you have the
option of processing any changes again, or maintaining it by hand.
I admit, this is not an elegant solution ;-)


> You aren't really extending the language per se. You're just adding another
> type/object attribute, so syntactically it remains the same. I believe
> implementations might have some latitude to create attributes like this and
> not be in violation of the standard, so it could be an extension without a
> language update.
> 
>>Of course, the draw back to this approach is that you don't avoid the
>>data copying that would be required by the generated code. The advantage
>>however, would be to keep the language from growing in size. If you
>>look at:
>>
>> >>for X in My_Type'Raw_Data (My_Data)'Range loop
>> >>    Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ;
>> >>end loop ;
>>
>>there is some data copying on a Some_Storage_Element basis anyway.
> 
> But no motion of My_Data to some intermediate structure just to be able to
> treat it as bytes. The Some_Storage_Element part was just there to
> demonstrate something syntactically correct. The important part is the
> My_Type'Raw_Data (My_Data) (X) part. You can reference all the bytes of
> My_Data without having to do:


Yes, I understand your point.


> Another_Block_Of_Data := My_Unchecked_Conversion (My_Data) ;

...

> 
>>Unless Ada0Y were to gain endian representation features, I think
>>a certain amount of copying (internal or external) would be
>>necessary anyway. But I have to admit, that a representation
>>clause for endianess would be extremely convenient. Then at least
>>the compiler can do it in the most effective manner for the
>>platform it was compiled on.
>>
> 
> What's wrong with ARM 13.5.3 Bit Ordering and using "for X'Bit_Order use
> High_Order_First ;" and similar (Low_Order_First )? I'm pretty sure that
> should work and do what you want - never needed to mess with it myself -
> yet. (Day ain't over, yet!)


I had forgotten about that (and not used it yet).  But I was under
the impression that it only affects the numbering of the bits -- not
the actual implementation of the "word". I'll have to review it again.

However, there are endian situations that cannot be described by
"for'Bit_Order". Thankfully they are rare on modern architectures.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Hi byte and Lo Byte Question

[Simon Wright]

"Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:

> Marin David Condic wrote:

> > What's wrong with ARM 13.5.3 Bit Ordering and using "for X'Bit_Order use
> > High_Order_First ;" and similar (Low_Order_First )? I'm pretty sure that
> > should work and do what you want - never needed to mess with it myself -
> > yet. (Day ain't over, yet!)
> 
> I had forgotten about that (and not used it yet).  But I was under
> the impression that it only affects the numbering of the bits -- not
> the actual implementation of the "word". I'll have to review it again.

From the 3.13p GNAT RM:

  In the case where the non-standard value is specified, the effect is
  to renumber bits within each bit, but the ordering of bytes is not
  affected.

  [...]

  Components occuping an integral number of bytes These are components
  that exactly fit in two or more bytes.  Such component declarations
  are allowed, but have no effect, since it is important to realize that
  the Bit_Order specification does not affect the ordering of bytes. In
  particular, the following attempt at getting an endian-indepedent
  integer does not work:

     type R2 is record
	A : Integer;
     end record;

     for R2'Bit_Order use High_Order_First;

     for R1 use record
	A at 0 range 0 .. 31;
     end record;

  This declaration will result in a little-endian integer on a
  little-endian machine, and a big-endian integer on a big-endian
  machine. if byte flipping is required for interoperability between
  big- and little-endian machines, this must be explicitly
  programmed. This capability is not provided by Bit_Order.

This doesn't appear to have changed at 3.14a1.

Re: Hi byte and Lo Byte Question

[Warren W. Gay VE3WWG]

Simon Wright wrote:

> "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes:
>>Marin David Condic wrote:
>>>What's wrong with ARM 13.5.3 Bit Ordering and using "for X'Bit_Order use
>>>High_Order_First ;" and similar (Low_Order_First )? I'm pretty sure that
>>>should work and do what you want - never needed to mess with it myself -
>>>yet. (Day ain't over, yet!)
>>>
>>I had forgotten about that (and not used it yet).  But I was under
>>the impression that it only affects the numbering of the bits -- not
>>the actual implementation of the "word". I'll have to review it again.
> 
> From the 3.13p GNAT RM:
> 
>   In the case where the non-standard value is specified, the effect is
>   to renumber bits within each bit, but the ordering of bytes is not
>   affected.


So this confirms my suspicion. It does not change the external
representation in any way, just gives you the facility to renumber
the bits, presumably for convenience or to specifically state what
bit ordering is assumed in the source code.

>   Components occuping an integral number of bytes These are components
>   that exactly fit in two or more bytes.  Such component declarations
>   are allowed, but have no effect, since it is important to realize that
>   the Bit_Order specification does not affect the ordering of bytes. In
>   particular, the following attempt at getting an endian-indepedent
>   integer does not work:
> 
>      type R2 is record
> 	A : Integer;
>      end record;
> 
>      for R2'Bit_Order use High_Order_First;
> 
>      for R1 use record
> 	A at 0 range 0 .. 31;
>      end record;
> 
>   This declaration will result in a little-endian integer on a
>   little-endian machine, and a big-endian integer on a big-endian
>   machine. if byte flipping is required for interoperability between
>   big- and little-endian machines, this must be explicitly
>   programmed. This capability is not provided by Bit_Order.
> 
> This doesn't appear to have changed at 3.14a1.


Given that this is a "language mandated thing" (ARM 13.5.3), I
would not expect it to change.
-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Hi byte and Lo Byte Question

[DuckE]

You don't really say anything about the data types you're working with, so
I'll just assume you're using Interfaces.Unsigned_16.  This sample Ada
program fairly closely matches the C example you gave, although you didn't
give any examples of types.

with Interfaces;
 use Interfaces;
with Ada.Text_Io;

procedure testbytes is

  package Unsigned_16_Io is new Ada.Text_Io.Modular_Io( Unsigned_16 );

  function LOBYTE( value : Unsigned_16 ) return Unsigned_16 is
  pragma Inline( LOBYTE );
  begin
    return value and 16#FF#;
  end LOBYTE;

  function HIBYTE( value : Unsigned_16 ) return Unsigned_16 is
  pragma Inline(HIBYTE);
  begin
    return Shift_Right( value, 8 );
  end HIBYTE;

begin
  declare
    a : Unsigned_16;
  begin
    a := 16#0102#;
    Ada.Text_Io.Put( "Value:  " );
    Unsigned_16_Io.Put( a, 8, 16 );
    Ada.Text_Io.New_Line;
    Ada.Text_Io.Put( "LOBYTE: " );
    Unsigned_16_Io.Put( LOBYTE( a ), 8, 16 );
    Ada.Text_Io.New_Line;
    Ada.Text_Io.Put( "HIBYTE: " );
    Unsigned_16_Io.Put( HIBYTE( a ), 8, 16 );
    Ada.Text_Io.New_Line;
  end;
end testbytes;

BTW: In Ada things are usually described in a more abstract manner, except
sometimes when dealing with interfaces.

SteveD


"mop" <mop65715@pegasus.cc.ucf.edu> wrote in message
news:9m0gn6$b6j$1@zeus.orl.lmco.com...
>
> I need to parse data into hi byte and lo byte. Does Ada have some built in
> macros or .... I could use?  From the looks of it no.
>
> here's the C version .... Need the Ada version as am new to Ada.
>
> lo = LOBYTE(Value);   -- need Ada version for this LOBYTE macro
> hi = HIBYTE(Value);    -- need Ada version for this HIBYTE macro
> WORD.Data.Word5_Data_Value_In_HB_LB_Order[0] = hi;
> WORD.Data.Word5_Data_Value_In_HB_LB_Order[1] = lo;
>
>
>