Re: S'Write and How To Count Bytes

Re: S'Write and How To Count Bytes

[Mario Amado Alves]

The "bottom line" was very simple: you may define the representation in
primary storage but not in secondary. This is what the ARM prescribes. I
also would like to see this changed in Ada20XX.

On Mon, 2 Oct 2000 tmoran@bix.com wrote:

> >... I will get out what I expect.
>   type Temperature is new Integer range 60 .. 80;
>   for Temperature'size use 8; -- or 7
> Is a Temperature'Write going to produce one byte, because that's how
> big Temperature is, or 4 bytes, because that's how big Integer is?
>   type R is record
>     Speed : Long_Integer;
>   end record;
>   for R use record
>     S at 0 range 0 .. 7;
>   end record;
> Will an R'Write produce one byte for S, or 8 or what?
> 
> >A perfect solution would be controlled representation of the (tagged)
> >record types and a fast overlay of a Stream_Element_Array.
>   I remember this discussion, but not the bottom line.  What's wrong
> with
>   TAG_SIZE : constant := 4;
>   ...
>   type This_Buffer is new Buffer with record
>     Speed : Integer;
>     T : Temperature;
>   end record;
>   for This_Buffer use record
>     Speed at TAG_SIZE range 0 .. 7;
>     T at Tag_Size+1 range 0 .. 7;
>   end record;
> and then overlay a Stream_Element_Array?  (Or a
> System.Storage_Elements.Storage_Array?)
>   I'd rather trust to TAG_SIZE being 4, or at least a single thing to
> change, as I move between compilers, rather than trusting Stream stuff.
> 

| |,| | | |RuaFranciscoTaborda24RcD 2815-249CharnecaCaparica 351+939354002
|M|A|R|I|O|
|A|M|A|D|O|DepartmentoDeInformaticaFCT/UNL 2825-114 Caparica 351+212958536
|A|L|V|E|S|                                                  fax 212948541
| | | | | |                 maa@di.fct.unl.pt                FCT 212948300

Re: S'Write and How To Count Bytes

[Marin David Condic]

Mario Amado Alves wrote:

> The "bottom line" was very simple: you may define the representation in
> primary storage but not in secondary. This is what the ARM prescribes. I
> also would like to see this changed in Ada20XX.

Not quite. You can get around the whole mess very simply by creating a
Stream_Element_Array of the appropriate size (minus the tag) and overloaying
it on the object of your record type 'class. With the overlay you can compute
checksums and whatever else you need, then blip the overlay down the wire. It
could all be done in a class-wide operation so that it will handle all
descendent types and avoids all the overhead of moving stuff around in memory
and calling a bunch of small subprograms to convert the elementary objects to
stream elements. You're guaranteed that your representation of data in memory
is what you blipped down the wire because you just overlayed memory with a
byte interpretation of it.

The problem comes in when you try to start slamming representation clauses on
tagged record types. You encounter a) problems with freezing rules. b)
problems with alignments on descendent types, c) compiler bugs, d) no
attributes for determining the size/placement of the tag within the record
(implementation dependence is about all this causes) e) compiler obstinance in
refusing to give you what you want.

IMHO, it would work much nicer and more efficiently than relying on the stream
attributes, but you just can't seem to get it to work all the way through.

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/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Rep clause problems, was Re: S'Write and How To Count Bytes

[tmoran]

>The problem comes in when you try to start slamming representation clauses on
>tagged record types. You encounter a) problems with freezing rules. b)
>...
>but you just can't seem to get it to work all the way through.
  So the basic problem is representation clauses, and Streams only come
into the picture because the rep clauses are giving too many problems.
And the rep clause problems are specific to tagged types.
Right?

Re: Rep clause problems, was Re: S'Write and How To Count Bytes

[Marin David Condic]

tmoran@bix.com wrote:

>   So the basic problem is representation clauses, and Streams only come
> into the picture because the rep clauses are giving too many problems.
> And the rep clause problems are specific to tagged types.
> Right?

Well, using the Stream attributes seems to be more of "The Ada Way" to do it, but
as noted, you may not be able to control the representation of individual elements
very well. (Also, there are overhead issues - just in case you're building hard
realtime systems. But thats a complaint that is not universal.) You'd be dependent
on the good graces of your compiler to do the right thing, and changing compilers
or getting new releases might mess up your format. (Obvious example: With a field
of type Integer, a given compiler may give you 16 bits and another might give you
32 bits. The ARM says you should get the normal in-memory representation, but it
is not a promise and you're up against system dependencies.)

So with my technique, you could avoid the whole mess just so long as you could
absolutely control the representation of a tagged record. Various suggestions have
been made to, for example, put a well-rep'd record inside the tagged record, but
this has problems with not allowing class-wide operations to be built. You've got
to build a new set of operations for each new type in the class. Yeah, you can do
it, but then you're defeating the elegance of the solution and forcing a lot of
work on building the descendent types. Also, its tough to come up with good ways
of doing things like checksumming the records and other things that rely on
looking at the whole thing as a unit.

The rep clauses may or may not be specific to tagged records. Some of it seems to
be language rules, but there is some debate about the legalities of it all. Some
of it may be specific to the compiler you pick - after all, it is perfectly legal
for a compiler to say: "I don't give a rat's corpse what you asked for in the rep
clause, this is what you're going to get." Legal - just not useful. I've built a
number of small test examples to try to coerce the representation of tagged
records into what I want and have just never been able to get it to work. Perhaps
I need to find a couple of different compilers and see if the behavior is
universal.

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/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Rep clause problems, was Re: S'Write and How To Count Bytes

[Simon Wright]

Marin David Condic <mcondic.nospam@acm.org> writes:

> So with my technique, you could avoid the whole mess just so long as
> you could absolutely control the representation of a tagged
> record. Various suggestions have been made to, for example, put a
> well-rep'd record inside the tagged record, but this has problems
> with not allowing class-wide operations to be built. You've got to
> build a new set of operations for each new type in the class. Yeah,
> you can do it, but then you're defeating the elegance of the
> solution and forcing a lot of work on building the descendent
> types. Also, its tough to come up with good ways of doing things
> like checksumming the records and other things that rely on looking
> at the whole thing as a unit.

I thought you had predefined message formats, which have to be
understood by code over which you have little control. So this format
will specify field locations and (if you're lucky) endianness. What it
certainly won't contain is a space for an Ada tag.

Seems to me you need packages to handle the wire formats and packages
to handle your tagged types; and when it comes to send a message you
might use streams in your tagged type package, but the implementation
of the 'Output etc will need to use the appropriate wire format
package. And the input wire format package will create and return some
object(s) in your tagged world.

I'm assuming that your tagged types are in your application domain,
not the comms domain? if the former, I've found that messages rarely
map at all to application classes; if the latter, the message set
rarely maps straightforwardly to any sort of inheritance tree.

Re: Rep clause problems, was Re: S'Write and How To Count Bytes

[Marin David Condic]

Simon Wright wrote:

> I thought you had predefined message formats, which have to be
> understood by code over which you have little control. So this format
> will specify field locations and (if you're lucky) endianness. What it
> certainly won't contain is a space for an Ada tag.
>

In the case I'm working on now, I do have a predefined message catalog.
Presuming that you do something with representation clauses on tagged
records rather than using a stream, you have some work to do. The tag in
the record, you have to get rid of in an implementation dependent manner.
Fortunately, while there may be hundreds of ways of implementing tagged
records, only one of them doesn't look silly: Put an integer at the front
of the base record type. You have to figure out the number of bits and use
that for your rep clause anyway, so its pretty easy to start your overlay
by stepping over the tag. It would help if Ada provided attributes to help
you out here - either by guaranteeing the size and location of the tag or
by inventing something like: Rec_Type'Starting_Point_Of_All_Non_Tag_Stuff.
The problem is you just can't seem to get control of the representation of
tagged types even if you can get around the tag with minimal fuss.


>
> Seems to me you need packages to handle the wire formats and packages
> to handle your tagged types; and when it comes to send a message you
> might use streams in your tagged type package, but the implementation
> of the 'Output etc will need to use the appropriate wire format
> package. And the input wire format package will create and return some
> object(s) in your tagged world.
>

That's sort of basically where I'm going for this case. I've got the
tagged record where I can use 'Read and 'Write to get it in the format for
the hose or get it back when I need it. Coming in, you have to do your own
dispatching when looking at the raw bytes so that you can create the
record type you need, but there's no way around that. If I don't get
exactly the format I want by the default 'Read and 'Write, for the
elementary types, I can replace them with something that will.

>
> I'm assuming that your tagged types are in your application domain,
> not the comms domain? if the former, I've found that messages rarely
> map at all to application classes; if the latter, the message set
> rarely maps straightforwardly to any sort of inheritance tree.

Not sure what you mean here. Let me see if I get close. All my messages
have a predefined message header that contains things like a sync pattern,
number of bytes, message identifier, yada, yada, yada. Then all the
"application specific" data content follows this message header. The tree
is very flat - although I suppose one day there may be some levels to it.
Mostly, you need to pull the bytes from the wire, figure out which of
maybe fifty or more messages is coming in, pull that message off the wire
and let the application have at it. (Naturally, theres a lot of error
checking, recovery, etc. that goes in all this too, but the process is
basically that.)

What I'd like is not necessarily some deep inheritance tree kind of thing.
I just want to be able to treat messages as what they are - a class. All
messages have some things in common - they all have a header, they all
translate into a stream of raw bytes of some determinable length, they all
transmit and receive up and down the same wire with the same hardware,
etc. It would be nice to support all the sending and receiving and such
from a class-wide set of operations and allow dispatching to handle the
specific cases.

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/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Rep clause problems, was Re: S'Write and How To Count Bytes

[Simon Wright]

Marin David Condic <mcondic.nospam@acm.org> writes:

> Simon Wright wrote:

> > I'm assuming that your tagged types are in your application domain,
> > not the comms domain? if the former, I've found that messages rarely
> > map at all to application classes; if the latter, the message set
> > rarely maps straightforwardly to any sort of inheritance tree.
> 
> Not sure what you mean here. Let me see if I get close. All my messages
> have a predefined message header that contains things like a sync pattern,
> number of bytes, message identifier, yada, yada, yada. Then all the
> "application specific" data content follows this message header. The tree
> is very flat - although I suppose one day there may be some levels to it.

Oh, yes, I see what you mean now. I was thinking of the relationships
between different messages, but you're (for now) more interested in
the face that they all derive from Message. That makes a lot more
sense than the vague picture I'd come up with!