Internal data representation

Internal data representation

[Richard A Lehman, DMSTB]

Bernard Badger of Harris states "I've been wondering why you 
*want* to access the ``internal'' respresentation.

Here at Johnson Space Center on the Space Station Program we
have to access the ``internal'' representation of Ada types
on many different tupes Heterogenous machines.  This is the only
way we can provide a common transmission format to communicate
amoung different type of ISAs.  

In fact a lot of our system software allows the user to view only
his machine and not to be concerned that the application on a SUN
may be communication complex Ada types to a VAX, Apollo, INTEL, 
Symbolic, or other one of a kind machines.

For the system software writer this is an important issue.  How
does the compiler writer represent the internal format of the
data.  This is one level of concern above portable software.  Not
only does the system utilities have to be able to compile and run
on different platforms, but the data also has be able to be exchanged.

Richard A Lehman
Lockheed Engineering & Sciences Co.
2400 NASA Rd 1
Houston, TX   77058
713.333.7074
lehman%asd.span@jpl-vlsi.arpa

Re: Internal data representation

[Barry Margolin]

In article <8902081403.AA15437@ajpo.sei.cmu.edu> LEHMAN%ASD.SPAN@STAR.STANFORD.EDU (Richard A Lehman, DMSTB) writes:
>Bernard Badger of Harris states "I've been wondering why you 
>*want* to access the ``internal'' respresentation.
>
>Here at Johnson Space Center on the Space Station Program we
>have to access the ``internal'' representation of Ada types
>on many different tupes Heterogenous machines.  This is the only
>way we can provide a common transmission format to communicate
>amoung different type of ISAs.  

Why do you have to use the internal representation as the interchange
representation?  What's wrong with something like (excuse my syntax --
I'm not really an Ada programmer):

package COLORS is

  type COLOR is (RED, ORANGE, YELLOW, GREEN, BLUE, VIOLET); -- rainbow order
  REP: constant array(COLOR'FIRST..COLOR'LAST) of COLOR :=
    (BLUE, GREEN, ORANGE, RED, VIOLET, YELLOW); -- alphabetical order

  procedure WRITE (S: STREAM, C: COLOR) is
  begin
    for I in REP'FIRST..REP'LAST loop
      if REP(I) = C then
	INTEGER_IO.WRITE (S, I);
	exit;
      end if;
    end loop;
  end WRITE;

  function READ (S: STREAM) return COLOR is
  begin
    return REP(INTEGER_IO.READ (S));
  end READ;

end COLORS;

My impression is that the ability to specify the internal
representation is strictly to permit enumerated types to be used to
access data whose representation is defined by external forces.  For
instance, if an Ada structure were mapped over the memory used for a
network packet buffer, an enumeriated type could be used to read the
packet type field.  The internal representation clause allows you to
map Ada values to values defined by a standard protocol.

But if all you care about is communication between programs that you
have full control over, you can define an arbitrary representation, as
I did above (notice that the order of the elements in REP is different
from the order in the type definition, to emphasize the arbitrariness
of the representation).

Barry Margolin
Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar