PROPOSAL: Binary Literals

[Reinier Zwitserloot]

public static byte b(String in) {
     return Byte.parseByte(in, 2);
}


then:


(0b11010100 & 0b01001011) ^ (0b01101010 | 0b10010100)


vs:

import static ByteUtils.b;

(b("11010100") & b("01001011")) ^ (b("01101010") | b("10010100"))



I can live with that.


  --Reinier Zwitserloot



On Apr 3, 2009, at 11:13, Derek Foster wrote:

>
>
> -----Original Message-----
>> From: Mark Thornton <mthornton at optrak.co.uk>
>> Sent: Mar 26, 2009 4:54 AM
>> To: Derek Foster <vapor1 at teleport.com>
>> Cc: coin-dev at openjdk.java.net
>> Subject: Re: PROPOSAL: Binary Literals
>>
>> Derek Foster wrote:
>>> You are not considering the impact of constant folding on compiler  
>>> optimizations.
>>>
>>> Not all constants are created equal. Constants whose values can be  
>>> determined at compile time can be inlined by the compiler, and  
>>> arithmetic expressions involving them can often therefore be  
>>> simplified at compile time. This process is known as "constant  
>>> folding". The resulting code need not reference the original  
>>> variable to get the constant at all -- it can just use the inlined  
>>> result of evaluating the expression. Additional compiler  
>>> optimizations may then be performed on the basis of these folded  
>>> constants. For instance, a compiler might decide to compile this  
>>> code:
>>>
>> Perhaps you missed my suggestion that the range of operations  
>> permitted
>> in constant expressions be extended to include the bit munging
>> operations (and possibly others). We could perhaps have an annotation
>> that was only permitted on static methods in the java.* name space  
>> and
>> which required the compiler to execute the method at compile time  
>> if its
>> arguments were compile time constants. The compiler could  
>> alternatively
>> have a private list of such methods, the annotation conveniently  
>> tells
>> everyone else what is on the list.
>
>
> I did miss that suggestion, actually. Though now that you've  
> mentioned it:
>
> It's not that I would mind that feature in the compiler ("that  
> feature"
> being compile-time evaluation of common library
> methods which are passed parameters known at compile time). However,
> it doesn't sound terribly easy to implement. Especially when you  
> consider
> the implications of having to do error handling on illegal function
> arguments at compile time, rather than at runtime. In fact, it sounds
> a whole lot more intrusive and a lot more work for the compiler team
> than just being able to parse a simple binary number.
>
> Besides that issue, however, and besides the also (substantial!) issue
> of the readability of
>
> (0b11010100 & 0b01001011) ^ (0b01101010 | 0b10010100)
>
> vs.
>
> (Byte.parseByte("0b11010100",2) & Byte.parseByte("0b01001011",2) ^  
> (Byte.parseByte("0b01101010",2) | Byte.parseByte("0b10010100",2))
>
> there is also the fact that some Java platforms simply don't HAVE a  
> Byte
> class. For instance, consider JavaCard:
>
> http://java.sun.com/javacard/
>
> A JavaCard, if you weren't aware, is a literally credit-card-sized  
> computer
> running a very stripped-down JVM that is just capable enough that it
> can do encryption calculations in order to ensure, for instance, that
> the card is connecting to an authorized and properly authenticated  
> bank
> machine. There's no room in a machine that small for the vast majority
> of standard library classes, most of which would be useless anyway in
> a computer of those capabilities. For instance, there is no support
> for java.lang.String, java.lang.Integer, and so forth (since this
> computer has no need to process Strings, and only needs integers
> for the purpose of number-crunching math, not nullness checks).
>
> Programmers for JavaCard could easily use binary numbers in their
> encryption algorithms. That's a use case that is easily handled by
> my proposal. However, importing a library that depends on
> Byte.parseInt(java.lang.String, int) isn't going to be sufficient
> for them, because they have neither Byte nor String.
>
> When I worked on the massively parallel processor chip I described
> earlier, our Java didn't have Byte or String classes either. Even
> if it had had something like String, nobody probably would have
> used it. Text processing is just not the kind of thing you use a
> massively parallel number crunching chip to do. Also, when each
> processor on the chip has around 8Kbytes of ROM to store program code,
> you don't want to be wasting it on library routines, or calls
> to them, that you don't really need.
>
> Derek
>
>
>
>
>
>
>
>
>> Mark Thornton
>>
>
>