Jeff,
As I understand it, unsigned integer types have the same
representation as the signed integer types -- the only
difference is in the way the operations on them behave.
Thus, you can use the underlying primitive types in Java
as the representations, but overload the arithmetic and
comparison operations to have the unsigned semantics. You
could use something like this (untested):
@NativeRep("java", "int", "gov.ornl.core.BoxedUnsignedInt",
"gov.ornl.types.Type.UNSIGNED_INT")
public final value UInt implements Integer, Unsigned {
@Native("java", "0x00000000")
public const MIN_VALUE = 0x00000000;
@Native("java", "0xFFFFFFFF")
public const MAX_VALUE = 0xFFFFFFFF;
@Native("java", "(#0)")
public native def $convert(v: Int); // convert from a signed int to an
unsigned int
// There is currently no way to define a conversion from an unsigned
int to a signed int. Nate?
@Native("java", "(#0)+(#1)")
public native def $plus(v: UInt) : UInt; // redundant now, may not be
in the future
@Native("java", "(#0)*(#1)")
public native def $times(v: UInt) : UInt; // redundant now, may not be
in the future
@Native("java", "(#0)<<(#1)")
public native def $left(v: UInt) : UInt; // redundant now, may not be
in the future
@Native("java", "(#0)>>>(#1)")
public native def $right(v: UInt) : UInt; // right shift (a>>b in X10)
@Native("java", "gov.ornl.core.UnsignedOps.div(#0,#1)")
public native def $over(v: UInt) : UInt; // division
@Native("java", "gov.ornl.core.UnsignedOps.rem(#0,#1)")
public native def $percent(v: UInt) : UInt; // remainder
@Native("java", "gov.ornl.core.UnsignedOps.less(#0,#1)")
public native def $lt(v: UInt) : Boolean; // comparison
...
@Native("java", "gov.ornl.core.UnsignedOps.toString(#0)")
public native def toString() : String;
...
}
where gov/ornl/core/UnsignedOps.java contains:
package gov.ornl.core;
public class UnsignedOps {
public static int div(int a, int b) {
// you can probably optimize this by hand, but a good JIT should
anyway
return (int)(((long)a & 0xFFFFFFFFl) / ((long)b & 0xFFFFFFFFl));
}
public static int rem(int a, int b) {
// you can probably optimize this by hand, but a good JIT should
anyway
return (int)(((long)a & 0xFFFFFFFFl) % ((long)b & 0xFFFFFFFFl));
}
public static boolean less(int a, int b) {
// you can probably optimize this by hand, but a good JIT should
anyway
return (b < 0 && (a >= 0 || a < b)) ||
(b >= 0 && a >= 0 && a < b);
}
public static String toString(int a) {
// you can write a better version if you wish
return Long.toString((long)a & 0xFFFFFFFFl);
}
...
}
(I think most of the arithmetic operations, except division,
actually behave the same for signed and unsigned operands).
You'll also have to replicate some of the code from Int.x10.
Writing an unsigned long class would be more of a challenge.
Also, take a look at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4504839
and http://mindprod.com/jgloss/unsigned.html .
I agree that it would be easier with the C++ backend,
because of the existence of primitive unsigned types
(though beware of the representation sizes).
Igor
Jeff Kuehn <ku...@ornl.gov> wrote on 01/09/2009 10:37:43 AM:
> If I'm reading x10.runtime.17/src-x10/x10/lang/Int.x10 correctly, the
> implementation of x10's Int and Long basically leverages the existing
Java
> int and long types. Since Java versions of "unsigned int" and "unsigned
> long" do not exist, this doesn't appear to be as straightforward as my
> initial reading of your email implied, though it may be possible for the
C++
> hosted compiler. Nor are there examples of binary & unary ops or
conversions
> (which were identified as a key issue in the earlier exchange) and would
> need to be implemented. Is this correct?
>
> Regards,
> --Jeff
>
> PS. 10-4 on the performance :-)
>
>
> ========================================================================
> Jeffery A. Kuehn, Senior HPC Evaluation Researcher
> Computer Science and Mathematics Division, Application Performance Tools
> National Center for Computational Sciences, Scientific Computing Group
> Institute for Advanced Architectures and Algorithms
> Extreme Scale System Center
> Oak Ridge National Laboratory
> One Bethel Valley Road MS6164
> Oak Ridge, TN 37831
> P:865.241.6134 F:865.241.4811
> ========================================================================
> "The most exciting phrase to hear in science, the one that heralds new
> discoveries, is not 'Eureka!' (I found it!) but 'That's funny....'"
> --Isaac Asimov
>
>
> Igor Peshansky wrote:
> > Jeff,
> >
> > The same mechanism is currently used to implement the types you
> > call "native" (e.g., Int, Double, etc), so you should have the same
> > performance as those. Take a look at, e.g., the sources for Int
> > (in x10.runtime.17/src-x10/x10/lang/Int.x10).
> >
> > Unfortunately, the @Native mechanism I'm referring you to is not
> > documented, since we only use it for our internal library
> > implementation. There are many gotchas, and I don't want to give
> > you the idea that it's in any way ready for general consumption.
> > But it should certainly suffice to implement unsigned integer
> > types, by copying Int.x10 and making the appropriate
> > modifications.
> >
> > That said, a user-defined type which is not defined using the
> > @Native/@NativeRep mechanism can be expected to have worse
> > performance than an equivalent @NativeRep'ed type.
> >
> > Also note that the current distribution is functionality-oriented,
> > and does not have the best performance. We are addressing this,
> > but for the next couple of releases don't expect lightning speed.
> > See the limitations section of the README.
> > Igor
> >
> > Jeff Kuehn <ku...@ornl.gov> wrote on 01/08/2009 05:42:42 PM:
> >
> >> Does a library implementation or a user defined type have any
explicit
> > or
> >> implicit negative performance implications relative to native types?
> >>
> >> Regards,
> >> --Jeff Kuehn, ORNL
> >>
> >>
> >> Igor Peshansky wrote:
> >>> Hi, Jeff,
> >>>
> >>> There is no built-in support for either of those features.
> >>> However, X10 1.7 has more advanced support for user-defined
> >>> functionality, which allows expressing them as derived
> >>> constructs.
> >>>
> >>> In 1.7, you can define your own unsigned integer type, and
> >>> overload the arithmetic and comparison operators appropriately.
> >>>
> >>> As for 64-bit array indices, the 1.7 language does allow you to
> >>> define a Rail with 64-bit indexing (after all, array indexing in
> >>> 1.7 is just function application, and one can overload that).
> >>>
> >>> I realise that this is a major inconvenience, and we will
> >>> certainly look into providing a more integrated solution (though
> >>> no promises on the timeframe). As stated above, any solution we
> >>> come up with will make these part of the libraries, rather than
> >>> alter the language spec. I'll let Nate expound on the plans for
> >>> adding these features to the standard libraries.
> >>>
> >>> Happy New Year!
> >>> Igor
> >>>
> >>> Jeff Kuehn <ku...@ornl.gov> wrote on 01/08/2009 02:58:04 PM:
> >>>
> >>>> Between December 2007 and July of 2008 we carried on a series of
> >>> exchanges
> >>>> regarding the addition of unsigned types to the X10 language. On
> >>> rereading
> >>>> the exchange, it seemed that we were disposed in favour of adding
> > this
> >>>> feature. However, on reviewing the 1.7 specification, there does
not
> >>> appear
> >>>> to be any reference to unsigned integers, nor does the 1.7.x
version
> > of
> >>> the
> >>>> compiler seem to support them. Will unsigned types be added to the
> >>> language?
> >>>> Also, in the same series of discussions, we noted a need for 64bit
> > array
> >>>> indices to accommodate large Rails. The discussion seemed to
finalize
> >
> >>> with
> >>>> "yes, but we need to think about how to do it right". Will 64 bit
> > array
> >>>> indices be added to the language?
> >>>>
> >>>> Best Regards,
> >>>> --Jeff Kuehn, ORNL
> >>>>
> >>>> -------- Original Message --------
> >>>> Subject: Unsigned Integer Types?
> >>>> Date: Wed, 12 Dec 2007 13:48:47 -0500
> >>>> From: Jeff Kuehn <ku...@ornl.gov>
> >>>> Reply-To: ku...@ornl.gov
> >>>> To: x10-us...@lists.sf.net
> >>>>
> >>>> Has any thought been directed toward the addition of 32 bit and 64
> > bit
> >>>> unsigned integer types? (unsigned int, unsigned long)
> >>>>
> >>>> Regards,
> >>>> --Jeff
--
Igor Peshansky (note the spelling change!)
IBM T.J. Watson Research Center
XJ: No More Pain for XML's Gain (http://www.research.ibm.com/xj/)
X10: Parallel Productivity and Performance (http://x10.sf.net/)
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
X10-users mailing list
X10-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/x10-users
