why do interpreter intrinsics exist

[snek]

hiya. i was looking at some code and i got side tracked into interpreter intrinsics. We appear to be inventing fake runtime function ids which refer to actual runtime function ids except that they are emitted as dynamic dispatch instead of direct calls to the runtime functions? I don't understand at all why we would want to do this so hopefully someone can expand on this :)

Thanks!

[Caitlin Potter]

Somebody stop me if my reasoning is not completely accurate, but:

1) simplicity -- intrinsics provide a way to add essentially a new opcode to the interpreter, without needing to handle it in bytecode-graph-builder (or nowadays, also not need to handle it in the baseline jit). So this lends itself to a more incremental implementation process.

2) size -- When the goal of the bytecode format is in part memory savings, operations which are less frequent may have been placed in intrinsics rather than risking needing a wider opcode byte. I believe this is no longer an issue, but I remember being told this at some point.

3) performance -- prior to the conservative scanning gc, there would be a significant cost invoking C code across an exit frame, so for things which could happen a lot, why not stay in the interpreter and handle the operation from there?

4) May have been needed to avoid performance regressions when migrating to ignition from the old fullcodegen inline runtime functions.

I'm sure this isn't entirely accurate, but it makes sense to me. Hope someone more knowledgable chimes in.

On Jun 22, 2022, at 3:08 AM, snek <sn...@chromium.org> wrote:



hiya. i was looking at some code and i got side tracked into interpreter intrinsics. We appear to be inventing fake runtime function ids which refer to actual runtime function ids except that they are emitted as dynamic dispatch instead of direct calls to the runtime functions? I don't understand at all why we would want to do this so hopefully someone can expand on this :)

Thanks!

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/d5c57707-67fc-4b89-8977-a71957f7c5ffn%40googlegroups.com.

[Toon Verwaest]

I believe part of it is just left-over from self-hosted JS where we had %_f() syntax. I started looking into removing this but it was a little too messy to be worth it. If someone wants to give it a try again I'm happy to support it :)

On Wed, Jun 22, 2022 at 3:15 PM Caitlin Potter <ca...@igalia.com> wrote:

Somebody stop me if my reasoning is not completely accurate, but:

Sounds close enough, thanks :)

 

1) simplicity -- intrinsics provide a way to add essentially a new opcode to the interpreter, without needing to handle it in bytecode-graph-builder (or nowadays, also not need to handle it in the baseline jit). So this lends itself to a more incremental implementation process.

2) size -- When the goal of the bytecode format is in part memory savings, operations which are less frequent may have been placed in intrinsics rather than risking needing a wider opcode byte. I believe this is no longer an issue, but I remember being told this at some point.

I do believe we could host the number of intrinsics we have directly in the bytecode.

 

3) performance -- prior to the conservative scanning gc, there would be a significant cost invoking C code across an exit frame, so for things which could happen a lot, why not stay in the interpreter and handle the operation from there?

Right, these calls aren't runtime function calls but builtin calls.

 

4) May have been needed to avoid performance regressions when migrating to ignition from the old fullcodegen inline runtime functions.

I'm sure this isn't entirely accurate, but it makes sense to me. Hope someone more knowledgable chimes in.

On Jun 22, 2022, at 3:08 AM, snek <sn...@chromium.org> wrote:



hiya. i was looking at some code and i got side tracked into interpreter intrinsics. We appear to be inventing fake runtime function ids which refer to actual runtime function ids except that they are emitted as dynamic dispatch instead of direct calls to the runtime functions? I don't understand at all why we would want to do this so hopefully someone can expand on this :)

Thanks!

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/d5c57707-67fc-4b89-8977-a71957f7c5ffn%40googlegroups.com.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/E83412FC-53C0-46F5-9784-3F8785A17AEA%40igalia.com.

[snek]

Thanks for the info. Looking at the intrinsics, there are not a lot and it makes sense to me to turn them into interpreter opcodes instead. Alternatively refactoring them them to get rid of their confusion with runtime functions could be an option if the count is expected to grow but looking at the current ones that seems pretty unlikely to me. If no one disagrees I could probably find some time to work on changing them into opcodes and deleting the intrinsic code.

[Leszek Swirski]

I think that sounds perfectly reasonable, as Toon says a lot of it is vestigial.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/0c953ad9-e968-40cf-bde3-692f5096c8fbn%40googlegroups.com.