64bit access to an array of 8bit values

64bit access to an array of 8bit values

[Dave Poirier]

I'm trying to modelize a small virtual machine, and I'm stuck on the 
memory model.  I'm defining the memory as an array of 8bit values, so 
that I am able to access every byte individually.  The problem comes 
when I try to access them with other data size, like 16/32/64bit.  GNAT 
simply refuses to do the pointer conversion (yeah, probably a bad habit).

So, what would be a "clean" way to do it?  here's what I tried

------
procedure test is
   type Bit8 is mod 2**8;
   type Bit64 is mod 2**64;
   type Bit8Acc is access Bit8;
   type Bit64Acc is access Bit64;

   type RamRange is range 0 .. 4000;

   Ram : array (RamRange) of aliased Bit8;
   Value : Bit64Acc;

begin
   Value := Ram(0)'Access;
end test;
------

test.adb:14:18: expected type "Bit64Acc" defined at line 6
test.adb:14:18: found type access to "bit8" defined at line 14

and also..
------
procedure test is
   type Bit8 is mod 2**8;
   type Bit64 is mod 2**64;
   type Bit8Acc is access all Bit8;
   type Bit64Acc is access all Bit64;

   type RamRange is range 0 .. 4000;

   Ram : array (RamRange) of aliased Bit8;
   Value : Bit64Acc;

begin
   Value := Bit64Acc(Ram(0)'Access);
end test;
------

test.adb:14:12: argument of conversion cannot be access
test.adb:14:12: use qualified expression instead

I'm just a smooth skinned Ada95 newbie, so don't get too big weapons to 
send replies ;)

Thanks for helping me learn :)
EKS - Dave Poirier

Re: 64bit access to an array of 8bit values

[Jim Rogers]

Dave Poirier wrote:

> I'm trying to modelize a small virtual machine, and I'm stuck on the 
> memory model.  I'm defining the memory as an array of 8bit values, so 
> that I am able to access every byte individually.  The problem comes 
> when I try to access them with other data size, like 16/32/64bit.  GNAT 
> simply refuses to do the pointer conversion (yeah, probably a bad habit).
> 


Please excuse me if I do not accurately understand your goals here.
It looks to me like you are trying to allocate different globs of
data from a reserved chunk of bytes.

If this is true then I suggest you read about Ada Storage Pools.
I believe Storage Pools are the mechanism you want.

Jim Rogers

Re: 64bit access to an array of 8bit values

[Dave Poirier]

John R. Strohm wrote:
> The short answer is that you can't do what you want to do.
> 
> The Ada compiler is not required to allocate precisely one byte per array
> element, and it probably didn't.  Instead, it will probably allocate one
> "word" per array element, because word access is probably faster than byte
> access.
> 
> Consider for a moment a processor like the TI 320C30 floating-point digital
> signal processor.  It provides a 32-bit word, but it does NOT provide any
> direct mechanism for addressing individual bytes within the word.  Location
> N is 32 bits wide.  Location N+1 is the next 32 bits.
> 
> Consider for a moment the old Harris superminicomputers.  They used a 24-bit
> word.  There is NOTHING the Ada compiler can do for you in that case,
> because 32-bit and 64-bit access DOESN'T EXIST on that machine.
> 
> I was told in school many years ago that there was also a German standard
> architecture, that specified a 48-bit word, of which three bits were
> reserved for type tagging.  So you effectively had a 45-bit word that you
> COULDN'T coerce to a different type without a lot of pain.
> 
> The first easy answer is that you model your memory as an array of Bit64,
> and do the necessary bitpicking to extract the Bit8, Bit16, and Bit32 values
> yourself.  If your machine doesn't support Bit64-like objects, then do it as
> Bit32 and hack around the Bit64 access.
> 
> The other easy answer is that you model your memory as an array of Bit8, and
> then you build up your Bit16, Bit32, and Bit64 accesses by doing multiple
> Bit8 fetches and stores.
> 
> The UGLY answer is to create several procedures, MyPeek8, MyPoke8, MyPeek16,
> MyPoke16, MyPeek32, ..., and then do assembly language interface to hide
> your memory model under them.  If you are a real glutton for punishment,
> look at the Ada machine code insertion capability.  Trust me: you DON'T want
> to do this.  (I had to do a VMEbus interface for a DSP board this way
> several years ago.  It worked, but it was NO FUN AT ALL.)

hrm, thanks for the information here, I see now why it can't be done.
I'll follow your tip and just make an array of 64bit values.  Otherwise
the cost of multiplication to reconstruct a 64bit or even 32bit value
from individual 8bits elements is too great.

Thanks again! :)

EKS - Dave Poirier
Ada95... where portability takes you in another dimension altogether!

Re: 64bit access to an array of 8bit values

[Jeffrey Creem]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:0CFB5EECF8614F8D.52C8F36A468D2F14.3AD3D533D2B72FDB@lp.airnews.net...
> The short answer is that you can't do what you want to do.


The longer answer is that it is this abstract philosophical academic mindset
that convinces
people that nothing can be done in Ada.  In fact you can do what you want to
do.

There are several "as portable as C or better" approches that could be taken
to solve this problem
(involving rep spec and either unchecked conversion of access types or array
slices) that
will solve this problem just fine. Some of these would probably break on
some compiler with
lack of full annex support or strange word sizes..But most of the time it
would be fine.



>
> The Ada compiler is not required to allocate precisely one byte per array
> element, and it probably didn't.  Instead, it will probably allocate one
> "word" per array element, because word access is probably faster than byte
> access.
>
> Consider for a moment a processor like the TI 320C30 floating-point
digital
> signal processor.  It provides a 32-bit word, but it does NOT provide any
> direct mechanism for addressing individual bytes within the word.
Location
> N is 32 bits wide.  Location N+1 is the next 32 bits.
>
> Consider for a moment the old Harris superminicomputers.  They used a
24-bit
> word.  There is NOTHING the Ada compiler can do for you in that case,
> because 32-bit and 64-bit access DOESN'T EXIST on that machine.
>
> I was told in school many years ago that there was also a German standard
> architecture, that specified a 48-bit word, of which three bits were
> reserved for type tagging.  So you effectively had a 45-bit word that you
> COULDN'T coerce to a different type without a lot of pain.
>
> The first easy answer is that you model your memory as an array of Bit64,
> and do the necessary bitpicking to extract the Bit8, Bit16, and Bit32
values
> yourself.  If your machine doesn't support Bit64-like objects, then do it
as
> Bit32 and hack around the Bit64 access.
>
> The other easy answer is that you model your memory as an array of Bit8,
and
> then you build up your Bit16, Bit32, and Bit64 accesses by doing multiple
> Bit8 fetches and stores.
>
> The UGLY answer is to create several procedures, MyPeek8, MyPoke8,
MyPeek16,
> MyPoke16, MyPeek32, ..., and then do assembly language interface to hide
> your memory model under them.  If you are a real glutton for punishment,
> look at the Ada machine code insertion capability.  Trust me: you DON'T
want
> to do this.  (I had to do a VMEbus interface for a DSP board this way
> several years ago.  It worked, but it was NO FUN AT ALL.)
>
> "Dave Poirier" <instinc@users.sf.net> wrote in message
> news:3C823A1A.6030006@users.sf.net...
> > I'm trying to modelize a small virtual machine, and I'm stuck on the
> > memory model.  I'm defining the memory as an array of 8bit values, so
> > that I am able to access every byte individually.  The problem comes
> > when I try to access them with other data size, like 16/32/64bit.  GNAT
> > simply refuses to do the pointer conversion (yeah, probably a bad
habit).
> >
> > So, what would be a "clean" way to do it?  here's what I tried
> >
> > ------
> > procedure test is
> >    type Bit8 is mod 2**8;
> >    type Bit64 is mod 2**64;
> >    type Bit8Acc is access Bit8;
> >    type Bit64Acc is access Bit64;
> >
> >    type RamRange is range 0 .. 4000;
> >
> >    Ram : array (RamRange) of aliased Bit8;
> >    Value : Bit64Acc;
> >
> > begin
> >    Value := Ram(0)'Access;
> > end test;
> > ------
> >
> > test.adb:14:18: expected type "Bit64Acc" defined at line 6
> > test.adb:14:18: found type access to "bit8" defined at line 14
> >
> > and also..
> > ------
> > procedure test is
> >    type Bit8 is mod 2**8;
> >    type Bit64 is mod 2**64;
> >    type Bit8Acc is access all Bit8;
> >    type Bit64Acc is access all Bit64;
> >
> >    type RamRange is range 0 .. 4000;
> >
> >    Ram : array (RamRange) of aliased Bit8;
> >    Value : Bit64Acc;
> >
> > begin
> >    Value := Bit64Acc(Ram(0)'Access);
> > end test;
> > ------
> >
> > test.adb:14:12: argument of conversion cannot be access
> > test.adb:14:12: use qualified expression instead
> >
> > I'm just a smooth skinned Ada95 newbie, so don't get too big weapons to
> > send replies ;)
> >
> > Thanks for helping me learn :)
> > EKS - Dave Poirier
> >
>
>

Re: 64bit access to an array of 8bit values

[John R. Strohm]

The short answer is that you can't do what you want to do.

The Ada compiler is not required to allocate precisely one byte per array
element, and it probably didn't.  Instead, it will probably allocate one
"word" per array element, because word access is probably faster than byte
access.

Consider for a moment a processor like the TI 320C30 floating-point digital
signal processor.  It provides a 32-bit word, but it does NOT provide any
direct mechanism for addressing individual bytes within the word.  Location
N is 32 bits wide.  Location N+1 is the next 32 bits.

Consider for a moment the old Harris superminicomputers.  They used a 24-bit
word.  There is NOTHING the Ada compiler can do for you in that case,
because 32-bit and 64-bit access DOESN'T EXIST on that machine.

I was told in school many years ago that there was also a German standard
architecture, that specified a 48-bit word, of which three bits were
reserved for type tagging.  So you effectively had a 45-bit word that you
COULDN'T coerce to a different type without a lot of pain.

The first easy answer is that you model your memory as an array of Bit64,
and do the necessary bitpicking to extract the Bit8, Bit16, and Bit32 values
yourself.  If your machine doesn't support Bit64-like objects, then do it as
Bit32 and hack around the Bit64 access.

The other easy answer is that you model your memory as an array of Bit8, and
then you build up your Bit16, Bit32, and Bit64 accesses by doing multiple
Bit8 fetches and stores.

The UGLY answer is to create several procedures, MyPeek8, MyPoke8, MyPeek16,
MyPoke16, MyPeek32, ..., and then do assembly language interface to hide
your memory model under them.  If you are a real glutton for punishment,
look at the Ada machine code insertion capability.  Trust me: you DON'T want
to do this.  (I had to do a VMEbus interface for a DSP board this way
several years ago.  It worked, but it was NO FUN AT ALL.)

"Dave Poirier" <instinc@users.sf.net> wrote in message
news:3C823A1A.6030006@users.sf.net...
> I'm trying to modelize a small virtual machine, and I'm stuck on the
> memory model.  I'm defining the memory as an array of 8bit values, so
> that I am able to access every byte individually.  The problem comes
> when I try to access them with other data size, like 16/32/64bit.  GNAT
> simply refuses to do the pointer conversion (yeah, probably a bad habit).
>
> So, what would be a "clean" way to do it?  here's what I tried
>
> ------
> procedure test is
>    type Bit8 is mod 2**8;
>    type Bit64 is mod 2**64;
>    type Bit8Acc is access Bit8;
>    type Bit64Acc is access Bit64;
>
>    type RamRange is range 0 .. 4000;
>
>    Ram : array (RamRange) of aliased Bit8;
>    Value : Bit64Acc;
>
> begin
>    Value := Ram(0)'Access;
> end test;
> ------
>
> test.adb:14:18: expected type "Bit64Acc" defined at line 6
> test.adb:14:18: found type access to "bit8" defined at line 14
>
> and also..
> ------
> procedure test is
>    type Bit8 is mod 2**8;
>    type Bit64 is mod 2**64;
>    type Bit8Acc is access all Bit8;
>    type Bit64Acc is access all Bit64;
>
>    type RamRange is range 0 .. 4000;
>
>    Ram : array (RamRange) of aliased Bit8;
>    Value : Bit64Acc;
>
> begin
>    Value := Bit64Acc(Ram(0)'Access);
> end test;
> ------
>
> test.adb:14:12: argument of conversion cannot be access
> test.adb:14:12: use qualified expression instead
>
> I'm just a smooth skinned Ada95 newbie, so don't get too big weapons to
> send replies ;)
>
> Thanks for helping me learn :)
> EKS - Dave Poirier
>

Re: 64bit access to an array of 8bit values

[David C. Hoos, Sr.]

How about something like this?

with Ada.Text_IO;
with Interfaces;
procedure Test is

   type Ram_Range is range 0 .. 2 ** 12 -1;

   Ram : array (Ram_Range) of Interfaces.Unsigned_8;

   function Value (Index : Ram_Range) return Interfaces.Unsigned_8
   is
      Result : Interfaces.Unsigned_8;
      for Result'Address use Ram (Index)'Address;
   begin
      return Result;
   end Value;

   function Value (Index : Ram_Range) return Interfaces.Unsigned_64
   is
      Result : Interfaces.Unsigned_64;
      for Result'Address use Ram (Index)'Address;
   begin
      return Result;
   end Value;

   procedure Set (Value : Interfaces.Unsigned_8; Index : Ram_Range)
   is
      Target : Interfaces.Unsigned_8;
      for Target'Address use Ram (Index)'Address;
   begin
      Target := Value;
   end Set;

   procedure Set (Value : Interfaces.Unsigned_64; Index : Ram_Range)
   is
      Target : Interfaces.Unsigned_64;
      for Target'Address use Ram (Index)'Address;
   begin
      Target := Value;
   end Set;

   Value_64 : Interfaces.Unsigned_64;

begin
   Set (Interfaces.Unsigned_64'(12345678901234567890), 1234);
   Value_64 := Value (1234);
   Ada.Text_IO.Put_Line
     ("Interfaces.Unsigned_64 value:" &
      Interfaces.Unsigned_64'Image (Value_64));
   for B in Ram_Range'(1234) .. 1241 loop
      Ada.Text_IO.Put_Line
        ("Interfaces.Unsigned_8 value at index" & Ram_Range'Image (B) & ":" &
         Interfaces.Unsigned_8'Image (Value (B)));
   end loop;
end Test;

----- Original Message ----- 
From: "Dave Poirier" <instinc@users.sourceforge.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: March 03, 2002 8:58 AM
Subject: 64bit access to an array of 8bit values


> I'm trying to modelize a small virtual machine, and I'm stuck on the 
> memory model.  I'm defining the memory as an array of 8bit values, so 
> that I am able to access every byte individually.  The problem comes 
> when I try to access them with other data size, like 16/32/64bit.  GNAT 
> simply refuses to do the pointer conversion (yeah, probably a bad habit).
> 
> So, what would be a "clean" way to do it?  here's what I tried
> 
> ------
> procedure test is
>    type Bit8 is mod 2**8;
>    type Bit64 is mod 2**64;
>    type Bit8Acc is access Bit8;
>    type Bit64Acc is access Bit64;
> 
>    type RamRange is range 0 .. 4000;
> 
>    Ram : array (RamRange) of aliased Bit8;
>    Value : Bit64Acc;
> 
> begin
>    Value := Ram(0)'Access;
> end test;
> ------
> 
> test.adb:14:18: expected type "Bit64Acc" defined at line 6
> test.adb:14:18: found type access to "bit8" defined at line 14
> 
> and also..
> ------
> procedure test is
>    type Bit8 is mod 2**8;
>    type Bit64 is mod 2**64;
>    type Bit8Acc is access all Bit8;
>    type Bit64Acc is access all Bit64;
> 
>    type RamRange is range 0 .. 4000;
> 
>    Ram : array (RamRange) of aliased Bit8;
>    Value : Bit64Acc;
> 
> begin
>    Value := Bit64Acc(Ram(0)'Access);
> end test;
> ------
> 
> test.adb:14:12: argument of conversion cannot be access
> test.adb:14:12: use qualified expression instead
> 
> I'm just a smooth skinned Ada95 newbie, so don't get too big weapons to 
> send replies ;)
> 
> Thanks for helping me learn :)
> EKS - Dave Poirier
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: 64bit access to an array of 8bit values

[Dave Poirier]

David C. Hoos, Sr. wrote:
> How about something like this?
> 
> with Ada.Text_IO;
> with Interfaces;
> procedure Test is
> 
>    type Ram_Range is range 0 .. 2 ** 12 -1;
> 
>    Ram : array (Ram_Range) of Interfaces.Unsigned_8;
> 
>    function Value (Index : Ram_Range) return Interfaces.Unsigned_8
>    is
>       Result : Interfaces.Unsigned_8;
>       for Result'Address use Ram (Index)'Address;
>    begin
>       return Result;
>    end Value;
> 
>    function Value (Index : Ram_Range) return Interfaces.Unsigned_64
>    is
>       Result : Interfaces.Unsigned_64;
>       for Result'Address use Ram (Index)'Address;
>    begin
>       return Result;
>    end Value;

considering the issues mentioned by John R. Strohm about 48 bits 
processors and other weirdies, would that code works under all of them? 
It sure does look like an interesting, just wonder about portability..

Thanks for the suggestion,
EKS - Dave Poirier

Re: 64bit access to an array of 8bit values

[David C. Hoos, Sr.]

The issue of portability would be governed by the requirements
of the LRM for a conforming implementation, viz.

(From LRM B.2)

Implementation Requirements

7 An implementation shall provide the following declarations
in the visible part of package Interfaces:

8 � Signed and modular integer types of n bits, if supported by the
target architecture, for each n that is at least the size of a storage
element and that is a factor of the word size. The names of these types
are of the form Integer_n for the signed types, and Unsigned_n for the
modular types;
9 � For each such modular type in Interfaces, shifting and rotating
subprograms as specified in the declaration of Interfaces above. These
subprograms are Intrinsic. They operate on a bit-by-bit basis, using
the binary representation of the value of the operands to yield a
binary representation for the result. The Amount parameter gives the
number of bits by which to shift or rotate. For shifting, zero bits are
shifted in, except in the case of Shift_Right_Arithmetic, where one
bits are shifted in if Value is at least half the modulus



In addition, for some architectures it might be necessary to specify
pragma Pack for the Ram array, and it wouldn't hurt for those
architectures for which it is unnecessary.

.
----- Original Message -----
From: "Dave Poirier" <instinc@users.sourceforge.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: March 03, 2002 4:51 PM
Subject: Re: 64bit access to an array of 8bit values


<snip>
> considering the issues mentioned by John R. Strohm about 48 bits
> processors and other weirdies, would that code works under all of them?
> It sure does look like an interesting, just wonder about portability..
>
> Thanks for the suggestion,
> EKS - Dave Poirier
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: 64bit access to an array of 8bit values

[Pat Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

"Dave Poirier" <instinc@users.sf.net> wrote in message
news:3C823A1A.6030006@users.sf.net...
> I'm trying to modelize a small virtual machine, and I'm stuck on the
> memory model.  I'm defining the memory as an array of 8bit values, so
> that I am able to access every byte individually.  The problem comes
> when I try to access them with other data size, like 16/32/64bit.  GNAT
> simply refuses to do the pointer conversion (yeah, probably a bad habit).
>
> So, what would be a "clean" way to do it?  here's what I tried
<snip>

The predefined way to manipulate values of arbitrary types at arbitrary
locations is to use the generic package
System.Address_to_Access_Conversions:

generic
    type Object (<>) is limited private;
package System.Address_To_Access_Conversions is
    type Object_Pointer is access all Object;
    function To_Pointer( Value : Address ) return Object_Pointer;
    function To_Address( Value : Object_Pointer ) return Address;
    pragma Convention( Intrinsic, To_Pointer );
    pragma Convention( Intrinsic, To_Address );
end System.Address_To_Access_Conversions;


For example, if you wanted to swap the two bytes at an arbitrary address
(assuming that was
the reasonable thing to do), you could do it like this:


with Interfaces;
with System.Address_To_Access_Conversions;
package body Byte_Swapping is

    type Word is new Interfaces.Unsigned_16;

    package Word_Ops is new System.Address_To_Access_Conversions( Word );
    use Word_Ops;

    procedure Swap2( Location : in System.Address ) is
        X : Word renames To_Pointer(Location).all;
    begin
        X := ( Shift_Left(X,8) and 16#FF00# ) or
               ( Shift_Right(X,8) and 16#00FF# );
    end Swap2;

    �

end Byte_Swapping;

There are other ways, of course, but this illustrates the idea.

Note that there is no guarantee that the address you provide to To_Pointer is
actually a meaningful address for a value of a given type.  You have to be
concerned with issues such as padding and alignment, for example.

Having described the above, let me also say that you can do unchecked
conversions from addresses into access values if you are knowledgeable about how
access values are implemented for your given machine/vendor.  For example, there
is no reason to think that an access value is simply a single address -- it
might be an address pair, and it depends upon the type designated.

By the way, depending on exactly what you are doing, if you want to model
contiguous memory you should consider using the type
System.Storage_Elements.Storage_Array -- it is guaranteed contiguous, unlike
other array types.  That may not be an issue for your model, but if you are
doing address calculations it is worth thinking about.

Hope that helps,

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: 64bit access to an array of 8bit values

[David Starner]

On Sun, 03 Mar 2002 17:51:57 -0500, Dave Poirier <instinc@users.sf.net> wrote:
> considering the issues mentioned by John R. Strohm about 48 bits 
> processors and other weirdies, would that code works under all of them?

Probably not.
 
> It sure does look like an interesting, just wonder about portability..

It's not a good idea if you want *Portability*. But if you're willing to
settle for something less, a carefully designed version of that code
(whatever you do, watch out for endian troubles) should work on 80x86s,
PowerPCs, M68ks, Alphas, and most of the other consumer level systems
out there. If that's your target audience, it may be worth sacrificing
that last .1% if you can get a decent speed increase out of it. 

-- 
David Starner - starner@okstate.edu
What we've got is a blue-light special on truth. It's the hottest thing 
with the youth. -- Information Society, "Peace and Love, Inc."

Re: 64bit access to an array of 8bit values

[Jeffrey Carter]

If you're willing to limit yourself to those machines that actually have
8-bit byte access (which your code would require), you can do

type Bit8 is new Interfaces.Unsigned_8;
-- This won't compile on machines that don't have 8-bit byte access.

type Bit64 is mod 2 ** 64;

type Ram_List is array (Natural range <>) of aliased Bit8;
for Ram_List'Component_Size use Bit8'Size;
pragma Pack (Ram_List);

Bytes_Per_Quad_Word : constant := 8;

subtype Quad_Word_As_Ram_List is Ram_List (1 .. Bytes_Per_Quad_Word);

function To_Quad_Word is new Ada.Unchecked_Conversion
(Source => Quad_Word_As_Ram_List, Target => Bit64);
function To_Ram_List is new Ada.Unchecked_Conversion
(Source => Bit64, Target => Quad_Word_As_Ram_List);

Ram   : Ram_List (0 .. Whatever);
Value : Bit64;
...
Value := To_Quad_Word (Ram (Ram'First .. Ram'First + Bytes_Per_Quad_Word
- 1) );

If you really need to have access values then you should look into
System.Address_To_Access_Conversions, and convert the address of the
first byte of the 64-bit value to the access-to-64-bit-value type.

To be really portable, you need to decide what byte order you want your
64-bit values to have, and do the appropriate conversion on machines
with a different endianness.

-- 
Jeff Carter
"Nobody expects the Spanish Inquisition!"
Monty Python's Flying Circus

Re: 64bit access to an array of 8bit values

[Robert Dewar]

"John R. Strohm" <strohm@airmail.net> wrote in message news:<0CFB5EECF8614F8D.52C8F36A468D2F14.3AD3D533D2B72FDB@lp.airnews.net>...

> The short answer is that you can't do what you want to 
> do.

short, but wrong :-)

> 
> The Ada compiler is not required to allocate precisely 
> one byte per array element, 

Well you can perfectly well use

  for x'component_size use 8;

to enforce that

> and it probably didn't.

Yes, of course it did
  
> Instead, it will probably allocate one
> "word" per array element,

No, of course it won't

> because word access is probably faster than byte
> access.

Not on any machine the questioner is likely to be using. 
This post sure had a lot of misinformation. Have not seen
yet whether there is anything useful in the rest of the
posts. The previous post about storage pools was even 
more irrelevant. The right answer of course is to use
unchecked conversion, and you can quite easily do what
you want. There is nothing wrong with pointer conversion
when it makes sense.

Re: 64bit access to an array of 8bit values

[Robert Dewar]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message news:<mailman.1015194302.22754.comp.lang.ada@ada.eu.org>...
> How about something like this?

and then suggests using address clauses. Yes, that will
work, but really the use of unchecked conversion of 
pointer types is so much closer to what the original
question asked for!

Re: 64bit access to an array of 8bit values

[Larry Kilgallen]

In article <5ee5b646.0203040229.6ffc7ee3@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:

<large snip>

> you want. There is nothing wrong with pointer conversion
> when it makes sense.

Probably there _is_ a problem with pointer conversion when it does
not make sense.  The issue is sorting out the two cases :-)

Re: 64bit access to an array of 8bit values

[Dave Poirier]

Larry Kilgallen wrote:
> In article <5ee5b646.0203040229.6ffc7ee3@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
> 
> <large snip>
> 
>>you want. There is nothing wrong with pointer conversion
>>when it makes sense.
>>
> 
> Probably there _is_ a problem with pointer conversion when it does
> not make sense.  The issue is sorting out the two cases :-)
> 

well, to help out a bit about this problem of mine, is that I want to 
create a virtual-computer out of Ada95, and I would greatly appreciate 
if the code could run on as many platform as possible.

Considering the endianness, I somehow doubt now that pointer conversion 
is what I want, I see how it can be done but I see how my bytes are not 
going to end up at the right place on some architectures.

So from what I gather, the best solution for as much portability as 
possible is to use an array of larger elements, then return only the 
part of each element that is required.

Thanks for all the great replies! :)

EKS - Dave Poirier

Re: 64bit access to an array of 8bit values

[Warren W. Gay VE3WWG]

David C. Hoos, Sr. wrote:

> How about something like this?
> 
...

>    function Value (Index : Ram_Range) return Interfaces.Unsigned_64
>    is
>       Result : Interfaces.Unsigned_64;
>       for Result'Address use Ram (Index)'Address;
>    begin
>       return Result;
>    end Value;

I don't think you'll find this particularly portable. Even if

the compiler allows it, on some UNIX (for example) platforms
you may get a SIGBUS error if the Index value is not on a word
boundary (some CPUs like SPARC and other big endian machines
seem to come to mind in this regard).

There is another nit-pick with regards to safety if you try
using Index values that would address the last 3 bytes of the
available "RAM", returning a 4-byte value.


-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: 64bit access to an array of 8bit values

[John R. Strohm]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:s2tg8.43726$%b6.11496771@typhoon.ne.ipsvc.net...
>
> "John R. Strohm" <strohm@airmail.net> wrote in message
> news:0CFB5EECF8614F8D.52C8F36A468D2F14.3AD3D533D2B72FDB@lp.airnews.net...
> > The short answer is that you can't do what you want to do.
>
>
> The longer answer is that it is this abstract philosophical academic
mindset
> that convinces
> people that nothing can be done in Ada.  In fact you can do what you want
to
> do.
>
> There are several "as portable as C or better" approches that could be
taken
> to solve this problem
> (involving rep spec and either unchecked conversion of access types or
array
> slices) that
> will solve this problem just fine. Some of these would probably break on
> some compiler with
> lack of full annex support or strange word sizes..But most of the time it
> would be fine.

The key phrase in there is "most of the time".  I've spent too many years
fixing something that should have worked "most of the time" because I
happened to stumble into the part of the time where it DIDN'T.

The one that I remember was a rep spec for an 8-bit device control register,
on a 32-bit machine.  The LRM requires the compiler to preserve the other 32
bits, which means that every write of the device control register was also
generating a read, to get the 24 bits that I apparently wasn't planning on
changing so they could be pasted back in.  Unfortunately, it was rather
crucial that the register NOT be read at that particular moment.

What this taught me is that solutions that work "most of the time" DON'T
work ALL of the time, and the right answer is never be satisfied with
something that doesn't work ALL of the time.  Correctness is a binary
property.

Re: 64bit access to an array of 8bit values

[Jeffrey Creem]

> What this taught me is that solutions that work "most of the time" DON'T
> work ALL of the time, and the right answer is never be satisfied with
> something that doesn't work ALL of the time.  Correctness is a binary
> property.


I don't entirely disagree but when face with an answer like "Sorry you can't
do that [in Ada]" a
person asking such a question will go off and say well I better do that in C
then when in reality all of the
problems you bring up would exist there as well....Your answer was not "No
do it this way instead" but
rather "You can't do that". I suspect following that advice I could convince
myself that I can not write any software
so perhaps I should be a gardener. (After all, Hello World will not work on
an embedded machine with no display so it is clearly not possible to write
Hello World in Ada)

Re: 64bit access to an array of 8bit values

[John R. Strohm]

Well, that is precisely what I did.  After explaining why the pointer
hacking he wanted to do did not work in the EXTREME GENERAL case, I showed
several alternatives that all WOULD work in the EXTREME GENERAL case.

The object of programming in a high-order language is that you DO *NOT* WANT
to deal with the idiosyncrasies of the target machine's architecture.  To a
first approximation, 99.9% of the code in a serious embedded system is
totally, utterly, completely INDEPENDENT of the target architecture.  The
other 0.1% (say 1000 lines out of a million LOC system) is heavily
target-dependent, and has to cope with it all.  For that 0.1%, Ada provides
machine code insertions, and every implementation I have seen provided a
capability for interfacing to assembly language code ("pragma linkage", as I
recall: it has been several years since I last dealt with Ada and assembly
language interface).  (Yes, I have done Ada machine code insertions, on a TI
320C40.  It was NOT fun.  We had a very tight limit on the amount of real,
live assembly language we could write, but machine code insertions didn't
count against the limit, so...)

Close to thirty years ago, one of the Big Names in computer science had an
article in "Software Practice and Experience".  I think it was Nicklaus
Wirth.  They had just ported their PASCAL compiler to a PDP-11, and were
testing something that had to do with character strings.  They set up what
they THOUGHT should have printed as "ABCD", and were quite disconcerted when
it printed "BADC".  They asked, in the article, for enlightenment as to what
had gone wrong.  THEY WERE MYSTIFIED.  This was in the early days, when the
problems created by the little-endianness of the PDP-11 were still eating
everyone alive.  (In fact, the terms "endian-ness", "little-endian", and
"big-endian" were not yet in common use in computing.)  The catch is that
they had written code that implicitly assumed big-endianness, because every
machine they'd ever encountered was big-endian.  (If memory serves me, the
PDP-11 was the very first little-endian architecture.)

The underlying problem with what the original poster wanted to do was this:
the endian-ness of his emulated machine MAY OR MAY NOT have matched the
endian-ness of his target hardware.  With a pointer-coercing scheme, you
explicitly accept whatever endian-ness the target hardware imposes on you.
This is not necessarily good: consider what happens, FOR EXAMPLE, when you
try to model a (big-endian) 68020 on a (little-endian) Pentium.  It gets
even worse if you have a process with a mode bit that SWITCHES endian-ness
on the fly for you.

Running a pointer-coercing scheme also runs the risk, as someone else
pointed out, of encountering SIGBUS traps, if the emulated machine allows
unaligned multibyte transfers but the target hardware (running the emulator)
doesn't.  Try simulating a 68040 (which allows unaligned transfers) on a
68000 (which doesn't).

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:YSch8.50282$%b6.13414165@typhoon.ne.ipsvc.net...
>
> > What this taught me is that solutions that work "most of the time" DON'T
> > work ALL of the time, and the right answer is never be satisfied with
> > something that doesn't work ALL of the time.  Correctness is a binary
> > property.
>
>
> I don't entirely disagree but when face with an answer like "Sorry you
can't
> do that [in Ada]" a
> person asking such a question will go off and say well I better do that in
C
> then when in reality all of the
> problems you bring up would exist there as well....Your answer was not "No
> do it this way instead" but
> rather "You can't do that". I suspect following that advice I could
convince
> myself that I can not write any software
> so perhaps I should be a gardener. (After all, Hello World will not work
on
> an embedded machine with no display so it is clearly not possible to write
> Hello World in Ada)
>
>
>

Re: 64bit access to an array of 8bit values

[Jeffrey Creem]

"John R. Strohm" <strohm@airmail.net> wrote in message
news:482822EEF13389AC.7CF0F33D21F3D96D.C977F409C9057456@lp.airnews.net...
> Well, that is precisely what I did.  After explaining why the pointer
> hacking he wanted to do did not work in the EXTREME GENERAL case, I showed
> several alternatives that all WOULD work in the EXTREME GENERAL case.

Sorry..Upon re-reading I see you did give the correct  alternative

"The first easy answer is that you model your memory as an array of Bit64,
and do the necessary bitpicking to extract the Bit8, Bit16, and Bit32 values
yourself.  If your machine doesn't support Bit64-like objects, then do it as
Bit32 and hack around the Bit64 access.

The other easy answer is that you model your memory as an array of Bit8, and
then you build up your Bit16, Bit32, and Bit64 accesses by doing multiple
Bit8 fetches and stores."

(Note that the statement "The Ada compiler is not required to allocate
precisely one byte per array
element, and it probably didn't." is still incomplete since it fails to
discuess various rep spec issues). In fairness the rep
spec issues are mostly irrelevant with the solution you propose..

However, my initial concern still stands (and this is not just true here but
I've seen similar discussions crop up
on the C++ and other mailing lists)... The problem with the way the response
is phrased is people walk away with the understanding that they can not use
the simple straightforward approach in Ada so they have to resort to
something more complicated. In fact, the problems you point out are common
to all languages (with the possible exception of Java which always runs with
the same endianness regardless of host but then of course would probably now
allow the evil pointer arithmetic that seemed to be desired so perhaps in
that case the answer really could have been you can't do it like
that  in XX lang).


>
> The object of programming in a high-order language is that you DO *NOT*
WANT
> to deal with the idiosyncrasies of the target machine's architecture.  To
a
> first approximation, 99.9% of the code in a serious embedded system is
> totally, utterly, completely INDEPENDENT of the target architecture.  The
> other 0.1% (say 1000 lines out of a million LOC system) is heavily
> target-dependent, and has to cope with it all.  For that 0.1%, Ada
provides
> machine code insertions, and every implementation I have seen provided a
> capability for interfacing to assembly language code ("pragma linkage", as
I
> recall: it has been several years since I last dealt with Ada and assembly
> language interface).  (Yes, I have done Ada machine code insertions, on a
TI
> 320C40.  It was NOT fun.  We had a very tight limit on the amount of real,
> live assembly language we could write, but machine code insertions didn't
> count against the limit, so...)
>
> Close to thirty years ago, one of the Big Names in computer science had an
> article in "Software Practice and Experience".  I think it was Nicklaus
> Wirth.  They had just ported their PASCAL compiler to a PDP-11, and were
> testing something that had to do with character strings.  They set up what
> they THOUGHT should have printed as "ABCD", and were quite disconcerted
when
> it printed "BADC".  They asked, in the article, for enlightenment as to
what
> had gone wrong.  THEY WERE MYSTIFIED.  This was in the early days, when
the
> problems created by the little-endianness of the PDP-11 were still eating
> everyone alive.  (In fact, the terms "endian-ness", "little-endian", and
> "big-endian" were not yet in common use in computing.)  The catch is that
> they had written code that implicitly assumed big-endianness, because
every
> machine they'd ever encountered was big-endian.  (If memory serves me, the
> PDP-11 was the very first little-endian architecture.)
>
> The underlying problem with what the original poster wanted to do was
this:
> the endian-ness of his emulated machine MAY OR MAY NOT have matched the
> endian-ness of his target hardware.  With a pointer-coercing scheme, you
> explicitly accept whatever endian-ness the target hardware imposes on you.
> This is not necessarily good: consider what happens, FOR EXAMPLE, when you
> try to model a (big-endian) 68020 on a (little-endian) Pentium.  It gets
> even worse if you have a process with a mode bit that SWITCHES endian-ness
> on the fly for you.
>
> Running a pointer-coercing scheme also runs the risk, as someone else
> pointed out, of encountering SIGBUS traps, if the emulated machine allows
> unaligned multibyte transfers but the target hardware (running the
emulator)
> doesn't.  Try simulating a 68040 (which allows unaligned transfers) on a
> 68000 (which doesn't).
>
> "Jeffrey Creem" <jeff@thecreems.com> wrote in message
> news:YSch8.50282$%b6.13414165@typhoon.ne.ipsvc.net...
> >
> > > What this taught me is that solutions that work "most of the time"
DON'T
> > > work ALL of the time, and the right answer is never be satisfied with
> > > something that doesn't work ALL of the time.  Correctness is a binary
> > > property.
> >
> >
> > I don't entirely disagree but when face with an answer like "Sorry you
> can't
> > do that [in Ada]" a
> > person asking such a question will go off and say well I better do that
in
> C
> > then when in reality all of the
> > problems you bring up would exist there as well....Your answer was not
"No
> > do it this way instead" but
> > rather "You can't do that". I suspect following that advice I could
> convince
> > myself that I can not write any software
> > so perhaps I should be a gardener. (After all, Hello World will not work
> on
> > an embedded machine with no display so it is clearly not possible to
write
> > Hello World in Ada)
> >
> >
> >
>
>

Re: 64bit access to an array of 8bit values

[John R. Strohm]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:Lnnh8.54694$%b6.13828382@typhoon.ne.ipsvc.net...
> However, my initial concern still stands (and this is not just true here
but
> I've seen similar discussions crop up
> on the C++ and other mailing lists)... The problem with the way the
response
> is phrased is people walk away with the understanding that they can not
use
> the simple straightforward approach in Ada so they have to resort to
> something more complicated. In fact, the problems you point out are common
> to all languages (with the possible exception of Java which always runs
with
> the same endianness regardless of host but then of course would probably
now
> allow the evil pointer arithmetic that seemed to be desired so perhaps in
> that case the answer really could have been you can't do it like
> that  in XX lang).

No.

Let me try it again.

The problem with the "simple straightforward approach", in Ada or in any
other language, is that it MAY OR MAY NOT WORK.  A "simple straightforward"
solution that DOESN'T WORK is not a solution.  Rather, it is a waste of
time.

In this case, the "simple straightforward approach" INHERENTLY inherits the
endian-ness of the target machine, which MAY OR MAY NOT match the endianness
of the simulated instruction set architecture.  If the endiannesses do not
match, the "simple straightforward approach" fails, forcing the programmer
to spend much time scratching his head, wondering what went wrong, and then
eventually figuring out that he has an endianness problem.

Even if the language is specified to run with the same endianness,
regardless of target architecture, requiring the compiler to generate
appropriate byteswapping code, the "simple straightforward approach in Ada"
STILL fails if the simulated instruction set architecture endianness does
not match the language endianness.

Part of the programmer's job is recognizing when the "simple straightforward
approach", in Ada, or in any other language, might not work.