Splitting a statement into multiple lines

Discussion in 'C Programming' started by Robert Miles, Dec 26, 2012.

  1. Robert Miles

    Robert Miles Guest

    This is actually for a homework assignment in CUDA, but I have pinned
    down the problem to a single statement, the only statement in the
    program that is long enough that it needs to be split into multiple
    lines.

    void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
    float* deviceB, float* deviceC,
    int numARows, int numAColumns,
    int numBRows, int numBColumns,
    int numCRows, int numCColumns);

    The part in <<< >>> is CUDA-specific.

    I haven't found any newsgroup for CUDA, but since it is one of the
    languages derived from C, I assume that an answer for C will also
    work in CUDA.

    The statement is a function call, and cannot be split into multiple
    statements.

    What should I do to split the statement? Just adding end-of-lines
    after the commas only produces confusing error messages about an
    incomplete type.

    Removing the void at the beginning only gives a different confusing
    error message.

    In case it matters, I am editing the program under Windows and
    running it on a remote system that I suspect is running Linux.

    I have the K&R2 book, just not time enough to search through all
    of it by the time this is due.

    By the way, are any of you interested in a free online CUDA course?

    Heterogeneous Parallel Programming
    https://www.coursera.org/category/cs-programming

    Already on progress, but another one is planned in 2013.
     
    Robert Miles, Dec 26, 2012
    #1
    1. Advertising

  2. Robert Miles

    Ian Collins Guest

    Robert Miles wrote:
    > This is actually for a homework assignment in CUDA, but I have pinned
    > down the problem to a single statement, the only statement in the
    > program that is long enough that it needs to be split into multiple
    > lines.
    >
    > void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
    > float* deviceB, float* deviceC,
    > int numARows, int numAColumns,
    > int numBRows, int numBColumns,
    > int numCRows, int numCColumns);
    >
    > The part in <<< >>> is CUDA-specific.
    >
    > I haven't found any newsgroup for CUDA, but since it is one of the
    > languages derived from C, I assume that an answer for C will also
    > work in CUDA.
    >
    > The statement is a function call, and cannot be split into multiple
    > statements.
    >
    > What should I do to split the statement? Just adding end-of-lines
    > after the commas only produces confusing error messages about an
    > incomplete type.


    If it were C, you wouldn't be getting error messages, so your problem
    must be CUDA specific.

    --
    Ian Collins
     
    Ian Collins, Dec 26, 2012
    #2
    1. Advertising

  3. Robert Miles

    James Kuyper Guest

    On 12/25/2012 08:21 PM, Robert Miles wrote:
    > This is actually for a homework assignment in CUDA, but I have pinned
    > down the problem to a single statement, the only statement in the
    > program that is long enough that it needs to be split into multiple
    > lines.
    >
    > void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
    > float* deviceB, float* deviceC,
    > int numARows, int numAColumns,
    > int numBRows, int numBColumns,
    > int numCRows, int numCColumns);
    >
    > The part in <<< >>> is CUDA-specific.
    >
    > I haven't found any newsgroup for CUDA, but since it is one of the
    > languages derived from C, I assume that an answer for C will also
    > work in CUDA.
    >
    > The statement is a function call, and cannot be split into multiple
    > statements.
    >
    > What should I do to split the statement? Just adding end-of-lines
    > after the commas only produces confusing error messages about an
    > incomplete type.


    If the relevant rules in CUDA were the same as in C, you could rewrite
    that statement as follows, without any change to its meaning:

    void
    matrixMultiply
    dim3
    DimGrid
    ,
    dim3
    DimBlock
    (
    float
    *
    deviceA
    ,
    float
    *
    deviceB
    ,
    float
    *
    deviceC
    ,
    int
    numARows
    ,
    int
    numAColumns
    ,
    int
    numBRows
    ,
    int
    numBColumns
    ,
    int
    numCRows
    ,
    int
    numCColumns
    )
    ;

    Therefore, if If that doesn't work in CUDA, then CUDA is too different
    from C for you to get useful advice on this issue from someone who knows
    C, but not CUDA.

    > Removing the void at the beginning only gives a different confusing
    > error message.


    That's easier to deal with. In C, the declaration of a function starts
    with either the type of it's return value, or the keyword 'void'
    indicating that it has no return value. Remove 'void' from the code
    above, and it no longer satisfies that rule. CUDA apparently has similar
    rules.

    > In case it matters, I am editing the program under Windows and
    > running it on a remote system that I suspect is running Linux.


    That might matter; Windows and Linux platforms have different
    conventions for terminating lines. If you transferred the program
    without using some method for converting the line endings, it might
    confuse CUDA. Some linux systems have a utility called dos2unix for
    performing such a conversion. ftp has a 'cr' command which toggles
    whether or not it performs the necessary conversion. I've no idea what
    options are available on the Windows side.
    --
    James Kuyper
     
    James Kuyper, Dec 26, 2012
    #3
  4. Robert Miles <> writes:
    > This is actually for a homework assignment in CUDA, but I have pinned
    > down the problem to a single statement, the only statement in the
    > program that is long enough that it needs to be split into multiple
    > lines.
    >
    > void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
    > float* deviceB, float* deviceC,
    > int numARows, int numAColumns,
    > int numBRows, int numBColumns,
    > int numCRows, int numCColumns);
    >
    > The part in <<< >>> is CUDA-specific.
    >
    > I haven't found any newsgroup for CUDA, but since it is one of the
    > languages derived from C, I assume that an answer for C will also
    > work in CUDA.
    >
    > The statement is a function call, and cannot be split into multiple
    > statements.


    If you delete the <<< ... >>> part, what remains is a valid C function
    *declaration*, not a function call (and not a statement).

    A C compiler would not care how the declaration is split into lines, as
    long as it's split between tokens. (A human reader will care about
    readability.)

    > What should I do to split the statement? Just adding end-of-lines
    > after the commas only produces confusing error messages about an
    > incomplete type.
    >
    > Removing the void at the beginning only gives a different confusing
    > error message.
    >
    > In case it matters, I am editing the program under Windows and
    > running it on a remote system that I suspect is running Linux.
    >
    > I have the K&R2 book, just not time enough to search through all
    > of it by the time this is due.


    You won't find the answer to this in K&R2. Your problem is either
    specific to CUDA or, as James Kuyper suggests, a result of the
    difference in the way Windows and Linux represent line endings.

    What happens if you *don't* split the declaration, i.e., leave
    it as one very long line? It would be about 200 characters long,
    well within the minimum that all C compilers are required to accept.
    (I have no idea whether CUDA imposes stricter limits). Splitting it
    into multiple lines is certainly a good idea, but it could be useful
    to see what happens if you don't.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Dec 26, 2012
    #4
  5. Robert Miles

    Glenn Guest

    On 26/12/12 02.21, Robert Miles wrote:
    ....
    > What should I do to split the statement? Just adding end-of-lines
    > after the commas only produces confusing error messages about an
    > incomplete type.
    >
    > Removing the void at the beginning only gives a different confusing
    > error message.
    >
    > In case it matters, I am editing the program under Windows and
    > running it on a remote system that I suspect is running Linux.

    .....

    Hi Robert

    Maybe the problem is different end-of-line representations.

    TextWrangler on Mac OS X can clean up mixed representations between old
    MacOS, Windows/DOS and Linux - by converting three times between all
    three - and then converting to e.g. Linux representations.

    Programmer’s Notepad:
    http://www.pnotepad.org/features/
    Quote: "...
    Support for windows, unix and macintosh line endings
    ...."

    Representations:
    http://en.wikipedia.org/wiki/Newline#Representations

    Conversion utilities:
    http://en.wikipedia.org/wiki/End_of_line#Conversion_utilities

    Unix2dos:
    http://en.wikipedia.org/wiki/Unix2dos

    -

    It is simply incredible that all macros and compilers can not handle
    "wrong" end-of-line representations.

    The symptoms I encountered was also different types of
    inconsistent/"impossible" error messages, that disappeared when the
    "wrong" end-of-line representations was removed.

    I am sure many cross-platform code migraters struggle, when they start it.

    Glenn
     
    Glenn, Dec 26, 2012
    #5
  6. Robert Miles <> writes:

    > This is actually for a homework assignment in CUDA, but I have pinned
    > down the problem to a single statement, the only statement in the
    > program that is long enough that it needs to be split into multiple
    > lines.
    >
    > void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float*
    > deviceA, float* deviceB, float* deviceC,
    > int numARows, int numAColumns,
    > int numBRows, int numBColumns,
    > int numCRows, int numCColumns);
    >
    > The part in <<< >>> is CUDA-specific.
    >
    > I haven't found any newsgroup for CUDA, but since it is one of the
    > languages derived from C, I assume that an answer for C will also
    > work in CUDA.
    >
    > The statement is a function call, and cannot be split into multiple
    > statements.


    Just one point. This is not a CUDA call. A call to CUDA "kernel"
    function looks exactly like a C funtion call but as an "execution
    configuration" (the <<<...>>> thing) inserted before the brackets.
    I.e. (as has been said) you need to drop the "void" for it to be a call.

    > What should I do to split the statement?


    You may be confused by what a statement is. You seem to be talking
    about splitting a statement into multiple lines -- that's not that same
    thing at all; it's still one statement, just written differently.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Dec 27, 2012
    #6
  7. Ben Bacarisse <> writes:
    > Robert Miles <> writes:
    >
    >> This is actually for a homework assignment in CUDA, but I have pinned
    >> down the problem to a single statement, the only statement in the
    >> program that is long enough that it needs to be split into multiple
    >> lines.
    >>
    >> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float*
    >> deviceA, float* deviceB, float* deviceC,
    >> int numARows, int numAColumns,
    >> int numBRows, int numBColumns,
    >> int numCRows, int numCColumns);
    >>
    >> The part in <<< >>> is CUDA-specific.
    >>
    >> I haven't found any newsgroup for CUDA, but since it is one of the
    >> languages derived from C, I assume that an answer for C will also
    >> work in CUDA.
    >>
    >> The statement is a function call, and cannot be split into multiple
    >> statements.

    >
    > Just one point. This is not a CUDA call. A call to CUDA "kernel"
    > function looks exactly like a C funtion call but as an "execution
    > configuration" (the <<<...>>> thing) inserted before the brackets.
    > I.e. (as has been said) you need to drop the "void" for it to be a call.


    Dropping the "void" isn't enough to make it a call; you also have to
    replace the parameter declarations with expressions of appropriate type.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Will write code for food.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Dec 27, 2012
    #7
  8. Robert Miles

    James Kuyper Guest

    On 12/27/2012 11:35 AM, Keith Thompson wrote:
    > Ben Bacarisse <> writes:
    >> Robert Miles <> writes:
    >>
    >>> This is actually for a homework assignment in CUDA, but I have pinned
    >>> down the problem to a single statement, the only statement in the
    >>> program that is long enough that it needs to be split into multiple
    >>> lines.
    >>>
    >>> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float*
    >>> deviceA, float* deviceB, float* deviceC,
    >>> int numARows, int numAColumns,
    >>> int numBRows, int numBColumns,
    >>> int numCRows, int numCColumns);
    >>>
    >>> The part in <<< >>> is CUDA-specific.
    >>>
    >>> I haven't found any newsgroup for CUDA, but since it is one of the
    >>> languages derived from C, I assume that an answer for C will also
    >>> work in CUDA.
    >>>
    >>> The statement is a function call, and cannot be split into multiple
    >>> statements.

    >>
    >> Just one point. This is not a CUDA call. A call to CUDA "kernel"
    >> function looks exactly like a C funtion call but as an "execution
    >> configuration" (the <<<...>>> thing) inserted before the brackets.
    >> I.e. (as has been said) you need to drop the "void" for it to be a call.

    >
    > Dropping the "void" isn't enough to make it a call; you also have to
    > replace the parameter declarations with expressions of appropriate type.


    Given that it needs so many changes to become a function call, it seems
    more likely that it was intended to be a function declaration, and that
    Robert just made a mistake when he referred to it as a function call.
    He also called it a statement, which in C would require that it be a
    function call, not a function declaration; but perhaps CUDA is more like
    C++, which has declaration-statements.
     
    James Kuyper, Dec 27, 2012
    #8
  9. Robert Miles

    James Kuyper Guest

    On 12/26/2012 12:59 AM, Robert Miles wrote:
    > On 12/25/2012 9:15 PM, James Kuyper wrote:
    >> On 12/25/2012 08:21 PM, Robert Miles wrote:
    >>> This is actually for a homework assignment in CUDA, but I have pinned
    >>> down the problem to a single statement, the only statement in the
    >>> program that is long enough that it needs to be split into multiple
    >>> lines.
    >>>
    >>> void matrixMultiply<<<dim3 DimGrid, dim3 DimBlock>>>(float* deviceA,
    >>> float* deviceB, float* deviceC,
    >>> int numARows, int numAColumns,
    >>> int numBRows, int numBColumns,
    >>> int numCRows, int numCColumns);
    >>>
    >>> The part in <<< >>> is CUDA-specific.
    >>>
    >>> I haven't found any newsgroup for CUDA, but since it is one of the
    >>> languages derived from C, I assume that an answer for C will also
    >>> work in CUDA.
    >>>
    >>> The statement is a function call, and cannot be split into multiple
    >>> statements.
    >>>
    >>> What should I do to split the statement? Just adding end-of-lines
    >>> after the commas only produces confusing error messages about an
    >>> incomplete type.

    >>
    >> If the relevant rules in CUDA were the same as in C, you could rewrite
    >> that statement as follows, without any change to its meaning:
    >>
    >> void
    >> matrixMultiply
    >> dim3
    >> DimGrid
    >> ,
    >> dim3
    >> DimBlock
    >> (
    >> float
    >> *
    >> deviceA
    >> ,
    >> float
    >> *
    >> deviceB
    >> ,
    >> float
    >> *
    >> deviceC
    >> ,
    >> int
    >> numARows
    >> ,
    >> int
    >> numAColumns
    >> ,
    >> int
    >> numBRows
    >> ,
    >> int
    >> numBColumns
    >> ,
    >> int
    >> numCRows
    >> ,
    >> int
    >> numCColumns
    >> )
    >> ;
    >>
    >> Therefore, if If that doesn't work in CUDA, then CUDA is too different
    >> from C for you to get useful advice on this issue from someone who knows
    >> C, but not CUDA.

    >
    > You forgot the <<< and >>>, which ARE CUDA-specific.


    No, I didn't forget, you only said that "The part in <<< >>> is
    CUDA-specific." The <<< and >>> tokens are not IN that part, they
    delimit that part. I thought that what you meant was that those
    delimeters were your own notation for our benefit, not that they were
    part of CUDA syntax. What you should have said "The part from <<< to >>>
    is CUDA-specific".

    >>> Removing the void at the beginning only gives a different confusing
    >>> error message.

    >>
    >> That's easier to deal with. In C, the declaration of a function starts
    >> with either the type of it's return value, or the keyword 'void'
    >> indicating that it has no return value. Remove 'void' from the code
    >> above, and it no longer satisfies that rule. CUDA apparently has similar
    >> rules.

    >
    > Looks like you didn't notice that it is supposed to be a function
    > call, not a function definition.


    I noticed that you referred to it as a function call, and as a
    statement, but I also noticed that, as far as C is concerned, it has
    (ignoring the CUDA-specific features), the syntax of a C function
    declaration, which is NOT a statement type. That left me quite uncertain
    as to what it was "supposed" to be, so I just paid attention to what it
    actually was (as far as C is concerned).

    I've learned that it's generally more useful to pay attention to what
    the code says than what newbies say about the code, because they often
    don't know the right words to use when talking about it. For instance,
    you words above suggest a confusion about the difference between a
    function declaration and a function definition.

    The 'void' would be an error in a C function call, while the absence of
    any specification of the return type would require a diagnostic in any
    version of C later than C90 if it were a C function declaration.
    Therefore, if you didn't get an error message about the 'void' keyword
    when it was present, and if removing the 'void' caused a different error
    message, there's a good chance CUDA interprets the syntax in a similar
    fashion.

    > I've now rewritten it as:
    >
    > matrixMultiply <<<DimGrid,DimBlock>>> (deviceA, deviceB, deviceC,
    > numARows, numAColumns,
    > numBRows, numBColumns,
    > numCRows, numCColumns);


    That, on the other hand, does have the syntax of a function call.

    > This at least stops the compile errors, but leaves an execution error
    > later. This may be enough that I can finish debugging it tonight.


    Good luck.
     
    James Kuyper, Dec 31, 2012
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page