Skip to content

Conversation

@andreaTP
Copy link
Collaborator

This is one possible setup to start implementing SIMD with the Vector API.
There are a few tricks to make it working (project setup, a sprinkle of reflection etc.) I'm happy to turn this around when a different approach is proposed 🙂

@andreaTP andreaTP requested review from electrum and evacchi October 24, 2024 18:25
@electrum
Copy link
Collaborator

This looks cool! I hope to have time to review this weekend.

}
}

private static void V128_NOT(MStack stack, Instance instance, Machine.Operands operands) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for visibility to reviewers, this is:

  • the demonstration that everything fits together
  • how I'm envisioning the opcodes to be implemented

the other opcodes are just implementing fallbacks.

private static Map<OpCode, Machine.OpImpl> additionalOpcodes;

static {
// TODO: discuss - either we use reflection or we need to restructure the project modules
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An alternative approach would be to fully duplicate the runtime-tests module, the downside is that needs a bit of fiddling with profiles in Maven.

@andreaTP
Copy link
Collaborator Author

self-reminder: follow up task to remove this: https://github.com/dylibso/chicory/blob/main/wasm/src/test/resources/wasm/simd_load.0.wasm

</plugins>
</build>

<profiles>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this work in the IDE?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll double-check while rebasing 👍


long[] call(int funcId, long[] args) throws ChicoryException;

Map<OpCode, OpImpl> additionalOpCodes();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these changes are specific to the interpreter and don't make sense for AOT.

What if we take a different approach and have a protected method in InterpreterMachine that eval() calls in the default case for the opcode switch? Then you can have SimdMachine which subclasses InterpreterMachine and we won't need to change this interface.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these changes are specific to the interpreter and don't make sense for AOT.

I haven't thought much about the compatibility with AOT indeed, I think I imagined invoking those as callHost or similar.

But I like the suggestion regarding eval, I'd go for it!

@evacchi
Copy link
Collaborator

evacchi commented Nov 7, 2024

superseded by #652

@evacchi evacchi closed this Nov 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants