Subject: Re: Packed struct/union amendments proposal
From: Steven Sharp (sharp@cadence.com)
Date: Thu Jul 25 2002 - 18:10:12 PDT
>The LRM only says the first member is the most significant, it does not
>say that all members pack most significant bit first.
It isn't clear what "most significant bit first" means. None of the bits
are specified to be "first" in a physical sense, just first in significance.
So you apparently mean that it does not say that all members pack with the
most significant bit (of the member) as the most significant bit (of the
member's field in the struct).
That is true. It is also true that when an architectural manual specifies
the relative significance of bytes in a word, it does not bother to specify
that the bits within a byte keep the same significance relative to each other,
independent of whether they are accessed as a byte or a word. Some things
are just assumed.
>If everyone agrees that is what it means I'm happy enough.
Excellent. Then everything should be fine the way it is. Unless someone
else disagrees with my interpretation?
You could try to provide wording that you think is clearer, but personally
I think it is clear enough already. More explanation might just confuse
the issue.
>> Note that none of this specifies the storage order in the actual host
>> memory.
>
>True, that is a seperate issue - but not unrelated.
It is certainly related from the point of view of the implementor, but
should be irrelevant from the point of view of the user.
>My understanding from the meeting was that it was somewhat host dependent.
The discussion got a little confused between the overlaying of the bits
of the members of the union, and the actual physical storage layout. I was
losing track myself. The first is host-independent and fully specified.
The second can be host-dependent and is not specified.
Regarding conversions when unioning 2-state and 4-state types:
>If the user is to accept responsibility then it should be disallowed and
>they should do it explicitly so that they know about it.
I assume that you mean to disallow unioning 2-state and 4-state types,
and that the user should explicitly cast from one type to the other when
necessary. That is an option that has some merit.
>The internal coding of "4-state" logic doesn't necessarily use 4 states,
>in some cases you want to propagate the fact that something is "unknown"
>or "undriven" seperately - particularly with mixed signal - so commiting
>to a particular mapping is a bad idea.
Verilog 4-state types allow exactly 4 states for each bit. The most
compact encoding of that requires 2 bits for each bit. Efficient logic
evaluation and common sense dictate that one of the bits match the
boolean value for the two boolean states. Similar reasons dictate that
the other bit indicate whether it is in a boolean state. That leaves 4
reasonable encodings. One of those encodings is used to represent 4-state
values in the IEEE PLI standard. That makes it the preferred one. So the
mapping is already pretty much committed by the existing standard. If we
recognize that fact, we can make the 2/4-state conversions more efficient.
If someone wants to use a different encoding in some other context, it is
easy enough to convert as needed.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Thu Jul 25 2002 - 18:16:52 PDT