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 <[email protected]> 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 <[email protected]> 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
> [email protected]
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-dev/d5c57707-67fc-4b89-8977-a71957f7c5ffn%40googlegroups.com
> <https://groups.google.com/d/msgid/v8-dev/d5c57707-67fc-4b89-8977-a71957f7c5ffn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> --
> v8-dev mailing list
> [email protected]
> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-dev/E83412FC-53C0-46F5-9784-3F8785A17AEA%40igalia.com
> <https://groups.google.com/d/msgid/v8-dev/E83412FC-53C0-46F5-9784-3F8785A17AEA%40igalia.com?utm_medium=email&utm_source=footer>
> .
>

-- 
-- 
v8-dev mailing list
[email protected]
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-dev/CANS-YRqfto3_i5t3MigwDOQNEK1%3D1Bn7J0y2QWKvg1ERzNvTOg%40mail.gmail.com.

Reply via email to