Bug 229112 - Add OpenCL C language support
Summary: Add OpenCL C language support
Status: CONFIRMED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (old) (show other bugs)
Version: unspecified
Platform: Arch Linux Unspecified
: VLO wishlist
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL: https://phabricator.kde.org/D4930
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-02 11:37 UTC by Matthias Fuchs
Modified: 2017-03-04 01:26 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Fuchs 2010-03-02 11:37:44 UTC
Version:            (using KDE 4.4.0)
Installed from:    Archlinux Packages

Please add OpenCL language support do KDevelop.

OpenCL allows one to create programs that can run on CPUs, GPUs and Cell processors. For that one creates Kernels (cl extension) written in OpenCL C.

OpenCL C is based on C99, with some restrictions and some additions.
Comment 1 Andreas Pakulat 2010-03-02 11:49:14 UTC
Can you please provide more information (or a link) about the actual restrictions of the language compared to C?

Apart from that, I don't quite understand why there would be special support needed if we support C99 already. KDevelop is not meant to catch all possible
mistakes you can make, the compiler is the ultimate source of wether you've
written your code correctly.
Comment 2 Aleix Pol 2010-03-02 12:03:59 UTC
We don't fully support C99 afaik.

Other than that, I'm not sure we could like to support anything further than the C standards. Having it in an external plugin would be nice, but for that we should export the AST in the c++ plugin i guess...

what kind of particularities does opencl have?
Comment 3 Matthias Fuchs 2010-03-03 14:46:21 UTC
Some restricitons of OpenCL are no static variables, no function pointers etc.

Some additions are Vectors with different length, like uint4, float8 ... these automatically support SSE2 and newer, addition of half (floating point with 16 bit), image2d_t for handling images etc.

Also memory is defined a little different, depending what is allowed to access it and where it is located on the device, so there are prefixes to variables like "__global", "__constant", "__local" and "__private".
Further a kernel (function run paralell on the device --> CPU, GPU or Cell CPU) is a void C-Function that has a "__kernel" put in front.

Here is a quick overview: http://www.khronos.org/files/opencl-quick-reference-card.pdf
And here the specification: http://www.khronos.org/registry/cl/specs/opencl-1.0.48.pdf (quite long!)


I know you have a lot on your todo list already, so it would be imo a great start if cl files were associated to c by default instead of common lisp, or if there was a check done to decide which of both to choose.
Another thing that would make the current c implementation work better with OpenCL was if it simply ignored "__local", "__global", "__kernel" etc. while parsing.

Btw. this is all about the kernel, not about the code that calls the kernels, as that can be written in a number of languages like C++ and is supported already by KDevelop like any other libaries are.

Tell me if you want more information.
Comment 4 Andreas Pakulat 2010-03-03 14:55:50 UTC
(In reply to comment #3)
> I know you have a lot on your todo list already, so it would be imo a great
> start if cl files were associated to c by default instead of common lisp, or if

You'll have to take this up with freedesktop.org (specifically the shared-mime project), as they define which suffix to associate with which mimetype and when to read from the file to decide. The mimetype is used then by kdevelop to decide which language support should handle the file.

> Another thing that would make the current c implementation work better with
> OpenCL was if it simply ignored "__local", "__global", "__kernel" etc. while
> parsing.

Can you elaborate what the problem is with parsing these? I'm guessing you're annoyed by the underlines?
Comment 5 Matthias Fuchs 2010-03-05 21:16:38 UTC
Ok, thx for the info.

The problem with the underlines is that nothing in the function signature gets highlighted then, neither the function name.
Comment 6 Kevin Funk 2017-03-04 01:26:22 UTC
Patch here: https://phabricator.kde.org/D4930