Higher Order Byte-Code Instructions - comp.lang.java.machine

Message from discussion Higher Order Byte-Code Instructions

Christopher Diggins

View profile

More options Apr 11 2007, 11:56 am

Newsgroups: comp.lang.java.machine

From: "Christopher Diggins" <cdigg...@gmail.com>

Date: 11 Apr 2007 08:56:44 -0700

Local: Wed, Apr 11 2007 11:56 am

Subject: Re: Higher Order Byte-Code Instructions

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

On Apr 11, 2:09 am, "Chris Uppal" <chris.up...@metagnostic.REMOVE-

THIS.org> wrote:
> Christopher Diggins wrote:
> > > It may well be that there are ways of extending the analysis the JVM
> > > must do to allow higher-order bytecodes in the context of a state of
> > > the art JITer, but I don't see any reason to expect that to be simple
> > > at all -- nor any reason to expect it even to fit into the current
> > > framework at all (it would be like adding eval(char *) to an optimising
> > > C compiler -- how can the compiler optimise code that is unknown until
> > > runtime ?)

> > This is an incorrect comparison. I am not proposing the execution of
> > untyped strings, or untyped sequence but rather the execution of type
> > functions generated through typed higher order instructions.

> You keep talking about the type system, but (while I understand that it is
> important to be able to do this checking, and I agree that it is significant
> that you /can/ do the checking), I don't see the relevance here. The issue is
> the implementation technology used in generating native code, not the
> technology used in static verification of bytecode.

What I meant was that the type system prevents you from using "eval"
on anything but a function value. A function value is guaranteed to be
a piece of well-typed code, by the type system.

> Following the terms of my analogy, consider the following code:

> sum = 0;
> for (int i = 0; i < array.length; i++)
> {
> for (int j = i; j < array.length; j++)
> {
> eval("sum += array[i] * array[j]");
> }
> }
> return sum;

> the problem is not that the input to eval() might specify unsafe operations, or
> operations which wouldn't make sense, but that the compiler has no idea which,
> if any, of the variables are used in the loop; what kinds of
> loop-transformation operations are valid; or even whether there are any loops
> at all there. It can't compile code it hasn't seen.

Because you can't evaluate strings in my proposal, you can only
evaluate dynamically created functions, which are neccessarily
constructed by quoting functions (e.g. pushing functions onto the
stack) that the compiler has already seen. So your example becomes

sum = 0;
for (int i = 0; i < array.length; i++)
{
for (int j = i; j < array.length; j++)
{
eval(closure{sum += array[i] * array[j]});
}
}
return sum;

There are plenty of well-known optimizations that can be done to the
above code using functional optimization techniques, including pre-
evaluation.

The next logical step after introducing higher order opcodes is the
introduction of array/list processing primitives based. Iterating over
an array for an example could also be done using higher order
functions like "map" or "fold", which can be easily parallelized by a
compiler.

Christopher Diggins
http://www.cdiggins.com

Reply to author Forward