RE: [sv-cc] Item 205 proposal: errors and changes

Jim,

First, thanks for the detailed reading and sharp eye. Here are
responses.

>The new section E.6.8 contains the partial sentence "If a vendor's
implementation uses a different
>representational scheme, the data can be marshaled...." If I
understood this correctly on my second
>reading, the proposal is talking only about allowing a different
representational scheme for packed arrays,
>but still requiring that the internal representation of elements of
unpacked arrays have a fixed and
>predetermined size and alignment. If this is so, then the partial
sentence might better say "If a vendor's
>implementation uses a different representational scheme for packed
arrays, the data can be marshaled...."
>Did I interpret this sentence correctly?

Yes, the remark was only about representing packed arrays. I will make
your suggested text change to make the things clearer.

(For future clarity, I meant 'internal organization' to refer to how
individual bits are used, as opposed to 'external' characteristics, like
size and alignment properties. Internal organization would involve
whether corresponding c and d values for a given logic 'bit' are stored
within the same byte, in corresponding bytes or corresponding 4-byte
chunks). Your suggestion is valid regardless.

>In the revised E.1 (paragraph 5), do you want "require that the
SystemVerilog implemenation format and
> canonical format be the same size for packed types" to be rather
"require that the SystemVerilog
> implementation format and canonical format have the same size and
alignment"?

Yes, the suggestion is better worded; I'll make that change, too.

>In that same paragraph, "predicatable" => "predictable".
Whoops. Will fix this.

>In E.9.4. Example 3 ... (after C code), the NOTEs should be changed to
have numbers. At least as of 1993,
>IEEE required this for multiple notes in a section. If we accept this
change, then the comment in the
>SystemVerilog code in the preceding section can change to "...indicated
by Note 2 following the code".

OK: found an example in 28.3.1; will number both Notes and change the
remark as suggested.

>Also in the "(after C code)" section, I didn't know what
"6*8svLogicActual32" is supposed to mean.

It means I made two crazy-looking cut-and-paste errors when transfering
text to the template. I'll fix the
text to correctly show the two macro uses with size arguments, i.e.,
        svBitActual32 b [64] [SV_PACKED_DATA_NELEMS(6*8)];
        svLogicActual32 my_tab [SV_PACKED_DATA_NELEMS(64)];

>Finally, in F.1, you refer to "These macros". In the first place, I
think you mean "These typedefs" rather
>than "These macros". But secondly, in the context "These" could refer
either to the preceding typedefs or
>to the following typedefs. Careful formatting (if we pass it
successfully to the editor) would help, but
>it would be better to say "The typedefs svBitActual32 and
svLogicActual32...."

OK; I've changed the text to follow this suggestion (and changed E.9.1.3
to follow it as well).

Thanks for the detailed reading, especially with such a quick
turn-around.

Ralph
Received on Tue Oct 26 13:47:43 2004