Support for char

[GoogleCodeExporter]

Add support for Java's char-type by mapping it to an unsigned short. 

Java doesn't support unsigned numeric value but char happens to map precisely 
to an unsigned short. It would therefore be convenient to be able to use it as 
a numeric value. 

Original issue reported on code.google.com by c...@degoo.com on 10 Oct 2011 at 9:10

[GoogleCodeExporter]

I suggest that we sole this by mapping char (16 bit unsigned) to unsigned short 
in OpenCL, similar to how we map byte (java) to char in OpenCL. My guess is 
that this would be a fun ;) initial project for someone to take on.  Just 
follow the byte conversion trail through the bytecode analysis and OpenCL 
creation.

Original comment by frost.g...@gmail.com on 11 Oct 2011 at 12:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

With the latest code changes in Trunk (11/07/2011) it appears that all of the 
Char JUnit tests are passing. Has this issue been addressed or do the tests 
need to be fixed and this still needs to be implemented?

Original comment by ryan.lam...@gmail.com on 10 Nov 2011 at 2:11

[GoogleCodeExporter]

So the char tests will be testing whether we correctly detect chars
and fall back to JTP.

For example here is the CharArrayField test (package and imports ommitted)

public class CharArrayField extends Kernel{
   @Override public void run() {
      out[0] = 0;
   }

   char out[] = new char[1];
}

/**{Throws{ClassParseException}Throws}**/

The last line tells us that this should throw a (classparseexception)
if it does *NOT* throw this exception then the junit test will report
a failure.

So, no work has been done on the support of char so far.

Gary

Original comment by frost.g...@gmail.com on 10 Nov 2011 at 2:07

[GoogleCodeExporter]

Interesting, thanks for the explanation...I was trying to trace through the 
JUnit tests to understand how they were implemented. So, in that case, 
Access2DIntArray must still be failing then?

Original comment by ryan.lam...@gmail.com on 10 Nov 2011 at 6:06

[GoogleCodeExporter]

Hmm  not for me.  The only failed tests for me are
  [junit] Test com.amd.aparapi.test.junit.codegen.AssignAndPassAsParameterSimple FAILED
  [junit] Test com.amd.aparapi.test.junit.codegen.ContinueTorture FAILED
  [junit] Test com.amd.aparapi.test.junit.codegen.FirstAssignInExpression FAILED
  [junit] Test com.amd.aparapi.test.junit.codegen.FirstAssignInExpression2 FAILED

Are you using Oracle's javac or eclipse to compile? Not complaining, just 
trying to clarify. :) 

Original comment by frost.g...@gmail.com on 10 Nov 2011 at 7:37

[GoogleCodeExporter]

I apologize for the poor wording of my response.

I meant to say that the Access2DIntArray test appears to be passing, but is 
still configured to throw an expected exception...

public class Access2DIntArray{
   int[][] ints = new int[1024][];

   public void run() {
      int value= ints[0][0];
   }
}
/**{Throws{ClassParseException}Throws}**/

Which means that double arrays are still not supported.

Original comment by ryan.lam...@gmail.com on 21 Nov 2011 at 8:15

[GoogleCodeExporter]

Ryan

Did you intend to make this note against Issue #10.  2D arrays?
Issue #3 is char support?

Assuming that this was to be against #10. :)

I think there is some confusion. There is no support for 2D arrays
added, I have added code to detect 2D array accesses and throw a
ClassParseException which should force a fallback to JTP mode.

I think prior to this a NPE was being thrown very late in the
txformation process when we were creating OpenCL.

The test case says that this Java code should indeed throw a
ClassParseException, which I believe it does.

Hopefully I have not added to the confusion..

Gary

Original comment by frost.g...@gmail.com on 21 Nov 2011 at 9:28

[GoogleCodeExporter]

Please review the attached patch for char support. If there are any additional 
changes needed or I missed a file during patch creation, please let me know. I 
think I've figured out your JUnit testing strategy.

In this patch (brief):
- Support for char and char[]
- Updated JUnit tests
- Finalized fields where appropriate
- Removed/commented out dead code
- Added Mac OS X specific svn:ignore directives

Original comment by ryan.lam...@gmail.com on 23 Nov 2011 at 7:27

Attachments:

• aparapi-03-49.patch

[GoogleCodeExporter]

Thanks for the patch Ryan.  

I will try to apply it today (providing thanksgiving induced tryptophan snooze 
does not overtake me), or possibly tomorrow.  

The junit is a little confusing, glad you unravelled it. 

Did you see any performance issues with short accesses?  I do know that some 
GPU's do not like to access array values <32 bits.  Some refuse completely 
(with OpenCL error at compile time) others are just very slow.  

For byte access support we had to trigger an OpenCL pragma that not all 
runtimes/devices support.  I wonder whether this is the case for short (which I 
assume you mapped java char to). 

Gary

Original comment by frost.g...@gmail.com on 24 Nov 2011 at 6:01

[GoogleCodeExporter]

Gary,

The code was not tested extensively, the coverage only extends as far as the 
existing tests. I did create a number of standard annotation-driven JUnit 
tests, which all passed, but were not included in the patch. The tests were 
conducted in OS X 10.7 and OpenCL 1.1 against the nVidia GPU in my MacBook Pro.

Original comment by ryan.lam...@gmail.com on 24 Nov 2011 at 7:49

[GoogleCodeExporter]

Patch for issue #3 commited.  Thanks to Ryan for the patch and the junit test 
changes.  

Original comment by frost.g...@gmail.com on 28 Nov 2011 at 11:35

• Changed state: Fixed