A question about bytecodes

[Stephen Dawkins]

John Rose wrote:
> (A primitive type I have sometimes felt was missing is T_VECTOR, a 
> 128-bit integer.  Of course, these will soon become 256 bits.  But 
> either of these types could be readily represented as a tuple of T_LONG 
> components.)

This was the other idea I had, give Java the ability to use SIMD 
instructions. After using OpenGL's shader language and throwing around 
vec4f's, going back to plain old scaler fields is quite tedious.

Unfortunetly this change requires a new primitive type AND a whole slew 
of new bytecodes to take advantage of it (add, sub, mul, div, dot 
product, cross product, comparisons for vec4f and vec2d) probably 
blowing the 20 or so remaining opcodes. Plus it means making the JVM 
allocate these fields on a 16-byte alignment.

> 
<snip>
> 
> As I think I said earlier, making a common idiom into an intrinsic 
> increases the chance that the programmer will code the intended 
> operation in a manner that the optimizer will recognize.

...because we're stuck with a limited set of bytecodes that can't 
adequately express what the programmer was intending? It seems silly 
that we're making do with with this limited bytecode language and losing 
  so much information the programmer could provide for us, allowing the 
compiler/optimiser todo a much better job, without having to guess that:

float a[] = new float[4], b[] = new float[4];
float c = a[0]*b[0] + a[1]*b[1] + a[2]*b[2] + a[3]*b[3];

could be compiled down to:

DPPS xmm1, xmm2

on my processor.

> -- John

Regards
Stephen