LEHMAN%ASD.SPAN@STAR.STANFORD.EDU (Richard A Lehman, DMSTB) (02/08/89)
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
barmar@think.COM (Barry Margolin) (02/09/89)
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