comp.lang.ada
 help / color / mirror / Atom feed
* Array of bytes type
@ 2000-05-19  0:00 Joseph P Vlietstra
  2000-05-19  0:00 ` James S. Rogers
                   ` (4 more replies)
  0 siblings, 5 replies; 14+ messages in thread
From: Joseph P Vlietstra @ 2000-05-19  0:00 UTC (permalink / raw)


Hi all,
I'm on a project which reuses/modifies code from several sources
and previous projects.  While integrating these packages together
we found 5 different declarations for an "array of bytes" type.
The declarations are similar enough that UC will copy slices from
one type to another but different enough to prevent any "clever"
conversions (e.g., overlays will fail due to different sizes in
index type).

We will probably standardize on one array of bytes type, play with
renames, etc.  But this effort has raises a question: what is the
plainest, simplest to reuse, declaration of an array of bytes?
(I would hope that some future project will steal/reuse my code
without the headaches I'm facing.)

Alternatives:

1. Roll my own.  For example:
   type Byte_Array is array(Integer range <>) of Interfaces.Unsigned_8;

   This seems like a universally useful array of bytes type;
   but I already have 5 different opinions of what a useful array
   of bytes type should look like.  So I'm thinking about hijacking
   something that is already defined in the LRM.

2. Use Stream_Element_Array.
   We do a lot of UC between our byte arrays and other data types.
   (Commmands come in and telemetry goes out in byte arrays.)
   This approach allows the possibility of using 'Read and 'Write
   to perform conversions on the byte array (using memory stream).
   The problem, of course, is that Stream_Element is implementation
   defined and need not match Storage_Element.
   BTW: Does anyone know of an implementation where Stream_Element
   doesn't match Storage_Element?

3. Use Storage_Element_Array.
   Again, this is implementation defined.
   (We're using a 32-bit processor, but a lot of spacecraft still
   use 1750A processors where the storage element is 16 bits.)

4. FLAME PROTECTION ON
   Use String
   FLAME PROTECTION OFF

5. Any other ideas?




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-19  0:00 Array of bytes type Joseph P Vlietstra
  2000-05-19  0:00 ` James S. Rogers
  2000-05-19  0:00 ` Jeff Carter
@ 2000-05-19  0:00 ` Ken Garlington
  2000-05-21  0:00   ` Robert Dewar
  2000-05-19  0:00 ` Marin D. Condic
  2000-05-19  0:00 ` DuckE
  4 siblings, 1 reply; 14+ messages in thread
From: Ken Garlington @ 2000-05-19  0:00 UTC (permalink / raw)


"Joseph P Vlietstra" <joevl@concentric.net> wrote in message
news:3924E094.6B03B5BD@concentric.net...
>    (We're using a 32-bit processor, but a lot of spacecraft still
>    use 1750A processors where the storage element is 16 bits.)

If you want your code to be compatible with implementations that still use
the 1750A, you may want to consider using code that's compliant with Ada83.
In this case, I would probably "roll my own" with my own definition of
Unsigned_8.






^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-19  0:00 Array of bytes type Joseph P Vlietstra
@ 2000-05-19  0:00 ` James S. Rogers
  2000-05-19  0:00 ` Jeff Carter
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 14+ messages in thread
From: James S. Rogers @ 2000-05-19  0:00 UTC (permalink / raw)



Joseph P Vlietstra wrote in message <3924E094.6B03B5BD@concentric.net>...
>2. Use Stream_Element_Array.
>   We do a lot of UC between our byte arrays and other data types.
>   (Commmands come in and telemetry goes out in byte arrays.)
>   This approach allows the possibility of using 'Read and 'Write
>   to perform conversions on the byte array (using memory stream).
>   The problem, of course, is that Stream_Element is implementation
>   defined and need not match Storage_Element.
>   BTW: Does anyone know of an implementation where Stream_Element
>   doesn't match Storage_Element?

Ada a matter of fact, yes. Some implementations of streams will use the
size of the base type as the stream element size, no matter what is
specified
for the 'Size attribute.

My project found the only reliable work-around for that compiler was to
convert all bytes to and from characters when using streams.

>5. Any other ideas?

One more possibility:

type Byte is mod 2**8;

type Byte_Array is array(Positive range <>) of Byte;

Jim Rogers
Colorado Springs, Colorado USA






^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-19  0:00 Array of bytes type Joseph P Vlietstra
  2000-05-19  0:00 ` James S. Rogers
@ 2000-05-19  0:00 ` Jeff Carter
  2000-05-20  0:00   ` Ken Garlington
  2000-05-19  0:00 ` Ken Garlington
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 14+ messages in thread
From: Jeff Carter @ 2000-05-19  0:00 UTC (permalink / raw)


Joseph P Vlietstra wrote:
> 1. Roll my own.  For example:
>    type Byte_Array is array(Integer range <>) of
> Interfaces.Unsigned_8;

Why "Integer range <>"? Are the following likely to be meaningful or
useful?

A : Byte_Array (-350 .. -279);
B : Byte_Array (-10 .. 10);

I have generally found

type Byte_List is array (Positive range <>) of Interfaces.Unsigned_8;

useful.

-- 
Jeff Carter
"Son of a silly person."
Monty Python & the Holy Grail




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-19  0:00 Array of bytes type Joseph P Vlietstra
                   ` (3 preceding siblings ...)
  2000-05-19  0:00 ` Marin D. Condic
@ 2000-05-19  0:00 ` DuckE
  4 siblings, 0 replies; 14+ messages in thread
From: DuckE @ 2000-05-19  0:00 UTC (permalink / raw)


Here is the answer we use:
PACKAGE BDTbaseDataTypes IS

  TYPE anInt32BDT IS RANGE - (2 ** 31) .. (2 ** 31) - 1;

  FOR anInt32BDT'SIZE USE 32;

  TYPE anInt32ArrayBDT IS ARRAY( Natural RANGE <> ) OF anInt32BDT;

  PRAGMA PACK (anInt32ArrayBDT);

  TYPE anInt16BDT IS RANGE -32768 .. +32767;

  FOR anInt16BDT'SIZE USE 16;

  TYPE anInt16ArrayBDT IS ARRAY( Natural RANGE <> ) OF anInt16BDT;

  PRAGMA PACK (anInt16ArrayBDT);

  TYPE anInt8BDT IS RANGE -128 .. +127;

  FOR anInt8BDT'SIZE USE 8;

  TYPE anInt8ArrayBDT IS ARRAY( Natural RANGE <> ) OF anInt8BDT;

  PRAGMA PACK (anInt8ArrayBDT);

  TYPE aUInt32BDT IS MOD 2**32;

  FOR aUInt32BDT'SIZE USE 32;

  TYPE aUInt32ArrayBDT IS ARRAY( Natural RANGE <> ) OF aUInt32BDT;

  PRAGMA PACK (aUInt32ArrayBDT);

  TYPE aUInt16BDT IS MOD 2**16;

  FOR aUInt16BDT'SIZE USE 16;

  TYPE aUInt16ArrayBDT IS ARRAY( Natural RANGE <> ) OF aUInt16BDT;

  PRAGMA PACK (aUInt16ArrayBDT);

  TYPE aUInt8BDT IS MOD 2**8;

  FOR aUInt8BDT'SIZE USE 8;

  TYPE aUInt8ArrayBDT IS ARRAY( Natural RANGE <> ) OF aUInt8BDT;

  PRAGMA PACK (aUInt8ArrayBDT);

  SUBTYPE aFloatBDT IS FLOAT;

  TYPE aFloatArrayBDT IS ARRAY( Natural RANGE <> ) OF aFloatBDT;

  PRAGMA PACK (aFloatArrayBDT);

  SUBTYPE aDoubleBDT IS LONG_FLOAT;

  TYPE aDoubleArrayBDT IS ARRAY( Natural RANGE <> ) OF aDoubleBDT;

  PRAGMA PACK (aDoubleArrayBDT);

END BDTbaseDataTypes;

For what it's worth,

SteveD







^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-19  0:00 Array of bytes type Joseph P Vlietstra
                   ` (2 preceding siblings ...)
  2000-05-19  0:00 ` Ken Garlington
@ 2000-05-19  0:00 ` Marin D. Condic
  2000-05-19  0:00 ` DuckE
  4 siblings, 0 replies; 14+ messages in thread
From: Marin D. Condic @ 2000-05-19  0:00 UTC (permalink / raw)


Joseph P Vlietstra wrote:
> We will probably standardize on one array of bytes type, play with
> renames, etc.  But this effort has raises a question: what is the
> plainest, simplest to reuse, declaration of an array of bytes?

I would use the stuff in Ada.Streams. Given that its part of the
language standard, many features become available automatically as a
result. Also, add-on software is likely to utilize it as well. As for
the stream element being other than a byte in size, I'd guess this is
likely to be a non-issue. Most machines use byte oriented storage and
I'd think (but have never surveyed) most compilers would match this. It
is the most universally used size for so many things that an implementor
would be foolish to do otherwise. The only exception I could think of
would be if someone had an implementation for a machine like the
Mil-Std-1750a where the standard storage unit is a 16 bit word. Those
cases are so rare that I wouldn't worry about it. (The standard probably
didn't explicitly specify a byte just in case there was an oddball
architecture like this being targeted, but I'd guess most everyone
expected this would normally be done as a byte.)

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-19  0:00 ` Jeff Carter
@ 2000-05-20  0:00   ` Ken Garlington
  0 siblings, 0 replies; 14+ messages in thread
From: Ken Garlington @ 2000-05-20  0:00 UTC (permalink / raw)


"Jeff Carter" <jrcarter@acm.org> wrote in message
news:3925B355.6C6565E6@acm.org...
> Why "Integer range <>"? Are the following likely to be meaningful or
> useful?
>
> A : Byte_Array (-350 .. -279);
> B : Byte_Array (-10 .. 10);

Actually, there's a few cases where it might be useful - e.g.

Target_Count : Byte_Array (-90 .. 90);  -- number of objects detected in
a -90 degree .. +90 degree arc, to 1 degree resolution.

Other uses include values related to floors of a building that contains
sub-basements, lookup tables that are indexed by +/- temperature,...

Even if you don't like negative numbers, at least starting with zero permits
certain small but useful optimizations on some architectures.






^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-19  0:00 ` Ken Garlington
@ 2000-05-21  0:00   ` Robert Dewar
       [not found]     ` <8gae49$tr5$1@slb7.atl.mindspring.net>
  0 siblings, 1 reply; 14+ messages in thread
From: Robert Dewar @ 2000-05-21  0:00 UTC (permalink / raw)


In article <oabV4.16593$wb7.1451403@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> If you want your code to be compatible with implementations
> that still use the 1750A, you may want to consider using code
> that's compliant with Ada83. In this case, I would probably
> "roll my own" with my own definition of Unsigned_8.

An interesting product would be a conversion from Ada 95 to
Ada 83 to take care of those using "obsolete" processors for
which only Ada 83 compilers are available.

This would not be trivial, but it could certainly be done (the
-gnatG output of GNAT is an interesting starting point).

This might possibly be a viable option for some legacy programs.


Sent via Deja.com http://www.deja.com/
Before you buy.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-22  0:00       ` Marin D. Condic
  2000-05-22  0:00         ` Jean-Pierre Rosen
@ 2000-05-22  0:00         ` Ken Garlington
  2000-05-22  0:00           ` David Kristola
  2000-05-22  0:00           ` Marin D. Condic
  1 sibling, 2 replies; 14+ messages in thread
From: Ken Garlington @ 2000-05-22  0:00 UTC (permalink / raw)


"Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote in message
news:39294D42.7519F6F4@quadruscorp.com...
> The 1750 may still be the only available game for deep space at the
> moment. I had heard that Plessey stopped making their rad-hard version.
> (They kept threatening to do this unless we gave them more money.) I
> think LockMart may have one they build for themselves. The 1750 may be
> 1970's technology, but it seems to refuse to die - more from lack of a
> successor than anything else.

I don't think LM builds a 1750 anymore, but I could be wrong.

The "new" game in town is to build 32-bit processors that emulate the 1750
ISA. Aviation Week had a brief story on this not too long ago. I don't know
if they've sold very many. Raytheon (nee TI) has a 1750 design, but I don't
know if it comes in a rad-hard version.






^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-22  0:00         ` Ken Garlington
@ 2000-05-22  0:00           ` David Kristola
  2000-05-23  0:00             ` Paul Warren
  2000-05-22  0:00           ` Marin D. Condic
  1 sibling, 1 reply; 14+ messages in thread
From: David Kristola @ 2000-05-22  0:00 UTC (permalink / raw)


On Mon, 22 May 2000 6:10:23 -0700, Ken Garlington wrote
(in message <3laW4.23155$wb7.1639706@news.flash.net>):

> I don't think LM builds a 1750 anymore, but I could be wrong.
> 
> The "new" game in town is to build 32-bit processors that emulate the 1750 
> ISA. Aviation Week had a brief story on this not too long ago. I don't know 
> if they've sold very many. Raytheon (nee TI) has a 1750 design, but I don't 
> know if it comes in a rad-hard version.

Honeywell has the RH32, a rad-hard 32 bit processor.  Rational
has an Ada95 cross compiler for it, but Ada Core Technologies
does not (we checked).  I have heard that there is a 32 bit
rad-hard CPU from Lockheed Martin, but i don't know any details.

I would love to see a rad-hard CPU in the PowerPC or MIPS family.


-- 
--djk, keeper of arcane lore & trivial fluff
Home: David95036 plus 1 at america on-line
Spam: goto.hades@welovespam.com





^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
       [not found]     ` <8gae49$tr5$1@slb7.atl.mindspring.net>
@ 2000-05-22  0:00       ` Marin D. Condic
  2000-05-22  0:00         ` Jean-Pierre Rosen
  2000-05-22  0:00         ` Ken Garlington
  0 siblings, 2 replies; 14+ messages in thread
From: Marin D. Condic @ 2000-05-22  0:00 UTC (permalink / raw)


Richard D Riehle wrote:
> The 1750A is not "obsolete."  It is still specified  for many communications
> satellites and other systems where a radiation hardened computer is required.
> At present, the Ada compilers for this platform are of the Ada 83 variety.
> 
I heard that Honeywell was working on a 32 bit processor for deep space
missions - RH32? It was supposed to be sufficiently rad-hard and had its
instruction set pruined for a higher level of determinism. I've not
heard if a) it has made its way into production, b) found much
acceptance or c) had an Ada compiler ported to it.

The 1750 may still be the only available game for deep space at the
moment. I had heard that Plessey stopped making their rad-hard version.
(They kept threatening to do this unless we gave them more money.) I
think LockMart may have one they build for themselves. The 1750 may be
1970's technology, but it seems to refuse to die - more from lack of a
successor than anything else.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-22  0:00         ` Ken Garlington
  2000-05-22  0:00           ` David Kristola
@ 2000-05-22  0:00           ` Marin D. Condic
  1 sibling, 0 replies; 14+ messages in thread
From: Marin D. Condic @ 2000-05-22  0:00 UTC (permalink / raw)


Ken Garlington wrote:
> I don't think LM builds a 1750 anymore, but I could be wrong.
> 
It's been a while since I've played the deep-space-microprocessor game,
so I'm a little out of touch. At one time, they were making them. Maybe
they came up with a better alternative?

> The "new" game in town is to build 32-bit processors that emulate the 1750
> ISA. Aviation Week had a brief story on this not too long ago. I don't know
> if they've sold very many. Raytheon (nee TI) has a 1750 design, but I don't
> know if it comes in a rad-hard version.

By definition, the space-processor business is a very small niche
market. Nobody is going to sell a lot of a chip that will fit that
niche. The best we could hope for is for someone to take a commercial
processor and make it rad-hard. Of course there would still be
weaknesses in commercial instruction sets. Maybe we'd have to learn to
live with it.

I'd be disappointed to see 1750 emulation on a 32 bit processor because
I think that the industry should move into the new millenium and start
building the infrastructure for the next generation. (Someone had to
bite the bullet and build compilers for the 1750, eh?) But I suppose
there are lots of legacy systems that need the capability, so it has a
reason to exist.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-22  0:00       ` Marin D. Condic
@ 2000-05-22  0:00         ` Jean-Pierre Rosen
  2000-05-22  0:00         ` Ken Garlington
  1 sibling, 0 replies; 14+ messages in thread
From: Jean-Pierre Rosen @ 2000-05-22  0:00 UTC (permalink / raw)


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


Marin D. Condic <mcondic-nospam@quadruscorp.com> a �crit dans le message : 39294D42.7519F6F4@quadruscorp.com...
> The 1750 may still be the only available game for deep space at the
> moment. I had heard that Plessey stopped making their rad-hard version.
> (They kept threatening to do this unless we gave them more money.) I
> think LockMart may have one they build for themselves. The 1750 may be
> 1970's technology, but it seems to refuse to die - more from lack of a
> successor than anything else.
>
I've heard that ESA used a lot of ERC32 - rad-hard version of the Sparc

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog






^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Array of bytes type
  2000-05-22  0:00           ` David Kristola
@ 2000-05-23  0:00             ` Paul Warren
  0 siblings, 0 replies; 14+ messages in thread
From: Paul Warren @ 2000-05-23  0:00 UTC (permalink / raw)


David Kristola <David95037@See-My.Sig> writes:

> Honeywell has the RH32, a rad-hard 32 bit processor.  Rational
> has an Ada95 cross compiler for it, but Ada Core Technologies
> does not (we checked).  I have heard that there is a 32 bit
> rad-hard CPU from Lockheed Martin, but i don't know any details.
> 
> I would love to see a rad-hard CPU in the PowerPC or MIPS family.

The European Space Agency has a 32 bit processor chipset, called
the ERC32.  The processor is SPARC V7. See
http://www.estec.esa.nl/wsmwww/erc32/erc32.html for more details.

I believe that this is being used in a few projects, though
the names and details elude me at the moment.

Aonix provide an Ada 83 compilation system which directly
targets the DEM32 target board (an ERC32 instance), and an
Ada 95 solution is currently in progress.  The Ada95 solution
only supports the Ravenscar profile (i.e. it is not full Ada 95).

I believe that ACT are doing some work on GNAT in this area,
though I don't know what the details are.

Cheers,

Paul




^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2000-05-23  0:00 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-19  0:00 Array of bytes type Joseph P Vlietstra
2000-05-19  0:00 ` James S. Rogers
2000-05-19  0:00 ` Jeff Carter
2000-05-20  0:00   ` Ken Garlington
2000-05-19  0:00 ` Ken Garlington
2000-05-21  0:00   ` Robert Dewar
     [not found]     ` <8gae49$tr5$1@slb7.atl.mindspring.net>
2000-05-22  0:00       ` Marin D. Condic
2000-05-22  0:00         ` Jean-Pierre Rosen
2000-05-22  0:00         ` Ken Garlington
2000-05-22  0:00           ` David Kristola
2000-05-23  0:00             ` Paul Warren
2000-05-22  0:00           ` Marin D. Condic
2000-05-19  0:00 ` Marin D. Condic
2000-05-19  0:00 ` DuckE

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox