Simplifying WyIL Bytecode #502

DavePearce · 2015-07-08T05:12:15Z

The WyIL bytecode could be significantly simplified by turning a large number of operations into builtin function calls. For example, removing the add bytecode and just having a function call to the builtin + operator.

The advantage of this is that it would make the bytecode language itself much more uniform and remove lots of the strange distinctions between unary, binary and nary relations. Furthermore, type information is included which will simplify type checking, etc.

The text was updated successfully, but these errors were encountered:

DavePearce · 2016-01-04T23:56:35Z

Related to #474 and #473

DavePearce · 2016-03-27T03:51:37Z

The Plan

Replace Not, BinaryOperator, UnaryOperator, LengthOf, Invert, Dereference, and possibly also IndexOf with a single Operator class. (DONE)
Replace NewArray, NewRecord, NewObject with a single New bytecode. Not sure how this would work for references, but perhaps we can figure it all out based on type. (DONE)
Eliminate Operator altogether in favour of Invoke with internal name space?
Split If bytecode into a single bytecode which takes a boolean operand. This can then be merged with the switch bytecode.(DONE)
Turn if and ifis into switch and match.

At this point, we want to start turning the bytecode into a structured form:

Make If bytecode take two optional blocks. The challenge here is how to handle short circuiting.
Eliminate goto bytecode and replace with break instead.
Replace Return bytecode with a break bytecode instead. Return values are then specified as assignments.

Also, allowing bytecode operands to be constants will enable further simplifications:

FieldLoad is no longer distinguishable from IndexOf
Const is just an Assign with a constant operand.

Other refactorings:

Make CodeGenerator, Interpreter and Wyil2JavaBuilder treat operators uniformly (IN PROGRESS).
Put preconditions for bytecodes into the schema, rather than having them hard-coded into VcGenerator.
Refactor Wyil2JavaBuilder to pass around Context variable rather than the current collection of parameters.
Add Not bytecode. At the moment, this is encoded using conditional branches which is rather ugly. (DONE)

The Codes.Void bytecode makes heaps of sense but is completely unused at this stage. For simplicity it's gone for now. The Codes.NULL_REG and related constants are no longer required and have been removed.

These bytecodes have been folded into the <code>Operator</code> class.

This bytecode was not currently used, so has been removed. However, I will expect it to make a come back later on.

Have pulled out the "operators" from the interpreter and split them into an array of InternalFunction instances. The idea behind this is to reduce the amount of code in the Interpreter class.

This refactors the interpreter and the JVM code generator to split out the code responsible for simple bytecodes. This exploits the uniformity that is beginning to be seen in the WyIL bytecode format.

This refactors the JVM code generator to split out the code responsible for simple bytecodes. This exploits the uniformity that is beginning to be seen in the WyIL bytecode format.

This remoces the bytecode Codes.NewRecord and turns it into an "Operator". This means it can be manipulated in a more uniform fashion.

These bytecodes have been merged into Codes.Operator.

Renamed Code to Bytecode, and Code.AbstractBranchingCode to Bytecode.Branching and Code.AbstractCompoundCode to Bytecode.Compound. This naming is better for sure, though there's more to go.

This is something of an experiment. Basically, I'm wondering how far I can push the refactoring done so far. In particular, can we make the Abstract Syntax Tree more uniform in the same way that we have done for WyIL bytecodes? I'd guess the answer is yes, but it probably needs a fair bit of work. I have succeeding in doing one example only so far, and it wasn't easy.

Having everything centered around the Bytecode class is not ideal, but I think it's more consistent and looks better. Realistically, we need a better language to get a better effect :)

This refactors Bytecode.If to accept only one argument rather than two and a comparator. Instead the comparator is implemented as a Bytecode.Operator.

This refactors Bytecode.If to accept only one argument rather than two and a comparator. Instead the comparator is implemented as a Bytecode.Operator. Perhaps surprisingly, this does offer some useful simplifications.

The Codes.Void bytecode makes heaps of sense but is completely unused at this stage. For simplicity it's gone for now. The Codes.NULL_REG and related constants are no longer required and have been removed.

These bytecodes have been folded into the <code>Operator</code> class.

This bytecode was not currently used, so has been removed. However, I will expect it to make a come back later on.

Have pulled out the "operators" from the interpreter and split them into an array of InternalFunction instances. The idea behind this is to reduce the amount of code in the Interpreter class.

This refactors the JVM code generator to split out the code responsible for simple bytecodes. This exploits the uniformity that is beginning to be seen in the WyIL bytecode format.

This remoces the bytecode Codes.NewRecord and turns it into an "Operator". This means it can be manipulated in a more uniform fashion.

These bytecodes have been merged into Codes.Operator.

Renamed Code to Bytecode, and Code.AbstractBranchingCode to Bytecode.Branching and Code.AbstractCompoundCode to Bytecode.Compound. This naming is better for sure, though there's more to go.

This is something of an experiment. Basically, I'm wondering how far I can push the refactoring done so far. In particular, can we make the Abstract Syntax Tree more uniform in the same way that we have done for WyIL bytecodes? I'd guess the answer is yes, but it probably needs a fair bit of work. I have succeeding in doing one example only so far, and it wasn't easy.

Having everything centered around the Bytecode class is not ideal, but I think it's more consistent and looks better. Realistically, we need a better language to get a better effect :)

This refactors Bytecode.If to accept only one argument rather than two and a comparator. Instead the comparator is implemented as a Bytecode.Operator. Perhaps surprisingly, this does offer some useful simplifications.

This removes the so-called bytecode constructors, which were static methods that actually instantiated Bytecode objects. Whilst these were actually quite nice in some ways, they were just accounting for yet more code. Removing makes little or no difference.

This adds an explicit Operator kind for logical not expressions. This can simplify code generation in some situations.

DavePearce · 2016-04-18T08:30:13Z

Done and merged into develop

DavePearce added WYIL Refactoring labels Jul 8, 2015

DavePearce modified the milestones: ChangeList Pre v0.4.0, ChangeList Post v0.4.0 Jul 8, 2015

This was referenced Jan 11, 2016

VariableDeclarations for Types / Constants #562

Closed

Redesigning WyIL Bytecode #563

Closed

DavePearce mentioned this issue Jan 26, 2016

Uniform WyIL Bytecode Representation #574

Closed

DavePearce added a commit that referenced this issue Mar 28, 2016

Removed LengthOf, IndexOf, ArrayGen bytecodes #502

37118c3

These bytecodes have been folded into the <code>Operator</code> class.

DavePearce added a commit that referenced this issue Mar 29, 2016

Remove move bytecode #502

b4a4b02

This bytecode was not currently used, so has been removed. However, I will expect it to make a come back later on.

DavePearce added a commit that referenced this issue Mar 29, 2016

Refactored Interpreter #502

0dd6af7

Have pulled out the "operators" from the interpreter and split them into an array of InternalFunction instances. The idea behind this is to reduce the amount of code in the Interpreter class.

DavePearce added a commit that referenced this issue Mar 29, 2016

Refactor Jvm backend #502

ca6c278

This refactors the JVM code generator to split out the code responsible for simple bytecodes. This exploits the uniformity that is beginning to be seen in the WyIL bytecode format.

DavePearce added a commit that referenced this issue Mar 29, 2016

Remove Codes.NewRecord #502

a03135c

This remoces the bytecode Codes.NewRecord and turns it into an "Operator". This means it can be manipulated in a more uniform fashion.

DavePearce added a commit that referenced this issue Mar 29, 2016

Remove Codes.Nop, Assign and NewObject #502

44bc022

These bytecodes have been merged into Codes.Operator.

DavePearce added a commit that referenced this issue Mar 29, 2016

Refactor wyil.lang.Code #502

17e343e

Renamed Code to Bytecode, and Code.AbstractBranchingCode to Bytecode.Branching and Code.AbstractCompoundCode to Bytecode.Compound. This naming is better for sure, though there's more to go.

DavePearce added a commit that referenced this issue Mar 30, 2016

Merged Codes into Bytecode #502

2b84ffb

Having everything centered around the Bytecode class is not ideal, but I think it's more consistent and looks better. Realistically, we need a better language to get a better effect :)

DavePearce added a commit that referenced this issue Mar 30, 2016

Refactor Bytecode.If #502

bebfd56

This refactors Bytecode.If to accept only one argument rather than two and a comparator. Instead the comparator is implemented as a Bytecode.Operator.

DavePearce added a commit that referenced this issue Mar 31, 2016

Removed LengthOf, IndexOf, ArrayGen bytecodes #502

5a66fc6

These bytecodes have been folded into the <code>Operator</code> class.

DavePearce added a commit that referenced this issue Mar 31, 2016

Remove move bytecode #502

605cc6a

This bytecode was not currently used, so has been removed. However, I will expect it to make a come back later on.

DavePearce added a commit that referenced this issue Mar 31, 2016

Refactored Interpreter #502

9b1e4c4

Have pulled out the "operators" from the interpreter and split them into an array of InternalFunction instances. The idea behind this is to reduce the amount of code in the Interpreter class.

DavePearce added a commit that referenced this issue Mar 31, 2016

Refactor Jvm backend #502

96f3959

This refactors the JVM code generator to split out the code responsible for simple bytecodes. This exploits the uniformity that is beginning to be seen in the WyIL bytecode format.

DavePearce added a commit that referenced this issue Mar 31, 2016

Remove Codes.NewRecord #502

c502e43

This remoces the bytecode Codes.NewRecord and turns it into an "Operator". This means it can be manipulated in a more uniform fashion.

DavePearce added a commit that referenced this issue Mar 31, 2016

Remove Codes.Nop, Assign and NewObject #502

ea8cbd1

These bytecodes have been merged into Codes.Operator.

DavePearce added a commit that referenced this issue Mar 31, 2016

Refactor wyil.lang.Code #502

2a5110c

Renamed Code to Bytecode, and Code.AbstractBranchingCode to Bytecode.Branching and Code.AbstractCompoundCode to Bytecode.Compound. This naming is better for sure, though there's more to go.

DavePearce added a commit that referenced this issue Mar 31, 2016

Merged Codes into Bytecode #502

976bdd5

Having everything centered around the Bytecode class is not ideal, but I think it's more consistent and looks better. Realistically, we need a better language to get a better effect :)

DavePearce added a commit that referenced this issue Apr 16, 2016

Add explicit Not operator #502

9b9190d

This adds an explicit Operator kind for logical not expressions. This can simplify code generation in some situations.

DavePearce mentioned this issue Apr 18, 2016

Convert Bytecode into Structured Form #620

Closed

DavePearce closed this as completed Apr 18, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplifying WyIL Bytecode #502

Simplifying WyIL Bytecode #502

DavePearce commented Jul 8, 2015

DavePearce commented Jan 4, 2016

DavePearce commented Mar 27, 2016 •

edited

DavePearce commented Apr 18, 2016

Simplifying WyIL Bytecode #502

Simplifying WyIL Bytecode #502

Comments

DavePearce commented Jul 8, 2015

DavePearce commented Jan 4, 2016

DavePearce commented Mar 27, 2016 • edited

The Plan

DavePearce commented Apr 18, 2016

DavePearce commented Mar 27, 2016 •

edited