VSIPL Avatar
  1. OMG Specification

VSIPL — Open Issues

  • Acronym: VSIPL
  • Issues Count: 4
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Sort function

  • Key: VSIPL16-31
  • Legacy Issue Number: 18575
  • Status: open  
  • Source: Anonymous
  • Summary:

    I don't think that Sort is defined the best way in VSIPL.
    Why spec doesn't define create function? Such function will let user to
    allocate additional memory which are required by some sorting methods.
    Why not to define out-of-place sort?
    If I work on 64-bit system, sort array of 32-bit FP values and need index
    vector, I'll get 64-bit indices which are not supposed to be that long.
    This is because last argument of sort function is
    const vsip_vview_vi *index and

    _vi means (unsigned long int) i.e. 64-bit elements.
    In the sort I implemented for AVX I permute data in vector registers and
    apply same permute to the indices which occupy other vector register.
    It's OK if function has to produce 32-bit indices, but it will be wrong
    when I have to shuffle 64-bit values.

    This last comment is applicable to other functions as well - index vector
    on 64-bit systems doesn't have to be 64-bit value because data arrays
    today are not huge yet.

  • Reported: VSIPL 1.4 — Mon, 25 Mar 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Distinction between "Restrictions" and "Errors" is unclear

  • Key: VSIPL16-28
  • Legacy Issue Number: 18381
  • Status: open  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    Throughout the document functions are defined with formal sections for "Restrictions" and "Errors".
    It isn't clear what the purpose of these two items is. In particular, "Errors" should actually spell out what errors (if any) the given function may generate. What it actually does, however, is specify conditions for the function arguments. These really belong into the "Restrictions" section

  • Reported: VSIPL 1.4 — Tue, 22 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Implementation Dependent Input and Output should become optional

  • Key: VSIPL16-29
  • Legacy Issue Number: 18382
  • Status: open  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    VSIPL and VSIPL++ both provide APIs to serialize certain objects. The VSIPL++ API supports serialization of blocks, while the VSIPL API supports serialization of function objects.

    The API for both should be unified and made optional (a "profile"), as it is orthogonal to the rest of the spec.

  • Reported: VSIPL 1.4 — Tue, 22 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Review entire document for typos

  • Key: VSIPL16-30
  • Legacy Issue Number: 18383
  • Status: open  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    While working on the translation to DocBook I noticed lots of small typos ("matrix" instead of "vector", "2d" instead of "1d", references to non-existing functions in "see also" sections, etc.)
    While these may all be obvious, i.e. not require any discussion or even semantic changes to the spec, the document needs a careful review to correct these.

  • Reported: VSIPL 1.4 — Tue, 22 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT