PROPOSAL: Binary Literals

[Derek Foster]

-----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
>