Re: [sv-ec] Re: [sv-bc] question on str.putc()

From: Neil Korpusik <Neil.Korpusik@Sun.com>
Date: Fri Oct 29 2004 - 13:09:50 PDT

Errata 275 was opened to capture the remaining set of issues that were
raised during the set of emails triggered by Shalom's question about
str.putc(). Errata 197 and 271 are related to this one.

Attached is a copy of the description contained in errata 275.

Neil

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Member of Technical Staff                         Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------

Section 3.7 String data type

There are several issues that were recently raised in a series of emails on the
SV-EC reflector with this section of the LRM. This errata is intended to
capture those issues. I have attempted to gather the discussion for each
issue together. My apologies to anyone that I have misquoted since I did
take the liberty of slightly rewording some of the comments after taking them
out of the original context.

There are a couple of other errata that are related to this one.
   197 - Is a String an array
   271 - Incorrect example of assigning a string to a register in Section 3.7

1. The Leftmost character of a string has index 0 - [Re: Neil]

   This is not mentioned in the LRM even though it appears that this was the
   intent.

   The string data type is based upon the C++ Standard Template Library
   implementation of its string class. In the STL implementation the leftmost
   character has index 0. This is consistent with how C-strings are used.
   
2. putc taking the first character of a string is inconsistent with assignments

   3.7.2 putc() says that

      str.putc(i,s) replaces the i'th character in str with the first
      character in s.

   Does str[j] = x actually take the LAST, not FIRST, character if x is a
   string, as in the following example. [Re: Shalom]

      bit[1:4][7:0] h = "hello"; //assigns to h "ello"

   It appears that the reason that the 'h' is dropped is due to the following
   paragraph in section 3.7 that describes truncation rules when the lengths of
   strings are unequal. [Re: Neil]

      "A string literal can be assigned to a string or an integral type. If
      their size differs the literal is right justified and either truncated
      on the left or zero filled on the left, as necessary."

   This characteristic, that under certain conditions, you take the first
   characters of a string, and in other cases, you take the last characters,
   is confusing and not well explained. I've been unable to figure out the
   rules clearly. [Re: Shalom]

3. Assigning a string variable to a byte select of a string variable

   Questions about the "Note:" in section 3.7.2
   Which of the putc() calls does the note apply to?

      task putc(int i, string s)
      task putc(int i, byte c)

      Note: str.putc(j,x) is semantically equivalent to str[j] = x.

   Then there was a question as to whether the statement within the note
   should be allowed at all.

   Below is feedback from Surrendra on this point.

      string x = "abc";
      str[2] = "abc"; (1)
      str[2] = x; (2) // should this be illegal? [Re: Surrendra]

   str[2] is a character which in SV is a byte.
   Statement (1) is a Verilog statement, so it must follow Verilog semantics.
   Statement (2) should be illegal as an SV string variable cannot be assigned
   directly to a byte, logic, etc. [Re: Surrendra]

   The note that Shalom pointed out is wrong if x is a string wider than
   1 character. [Re: Steven Sharp]

   Is str.putc(j, x) semantically equivalent to str[j] = x?
    
   I think yes, only if x is an integral value.
   Otherwise str.putc(j, x)is semantically equivalent to str[j] = x[0] if x
   is a string. [Re: Dave Rich]

4. The rules of assignment are not explicitly specified in this section

   [Re: Surrendra]

5. Typo in example - [Re: Neil]

   The following example is shown right before table 3-2 in section 3.7

      a[0]="h"; // OK same as a[0]="hi" ) <--- ) should be ;

6. Writing to an index of a string

   The following example is shown right before table 3-2 in section 3.7

      a[0]="h"; // OK same as a[0]="hi";

   This example is showing a string being indexed. Section 3.7, doesn't
   seem to say anything about writing to an index of a string. There is
   only this one example to say it is legal, and there is no description of
   its meaning in the text. [Re: Steven Sharp]

7. Assigning a string literal to a byte select of a string variable

   The following example is shown right before table 3-2 in section 3.7

      a[0]="h"; // OK same as a[0]="hi";

   Why is this being defined inconsistently with other assignments in the
   language? [Re: Steven Sharp]

   The text about reading from an index in a string says that the result is
   a byte. If we assume that it is also a byte when written, then an
   assignment to it should act like any other assignment to an integral
   type. The rightmost bits would be kept.

   This comment saying a[0] = "h" is the same as a[0] = "hi" is simply
   wrong. It should be fixed. [Re: Steven Sharp]

   'a[0] = "hi";' should be the same as 'a[0] = "i";' Since a[0] is an
   integral byte type, and integral type rules apply, therefore the left-most
   8 bits of "hi" are truncated. [Re: Dave Rich]

8. Usage of the word string

   By the way, it is also a Bad Practice to refer to a string variable or
   any other specific type of string as simply "string" with no modifier.
   The unmodified word "string" should be reserved for situations where it
   is equally applicable to all types of strings. [Re: Shalom]
Received on Fri Oct 29 13:09:57 2004

This archive was generated by hypermail 2.1.8 : Fri Oct 29 2004 - 13:10:12 PDT