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.
On Friday, June 24, 2022 at 7:23:09 AM UTC-7 Toon Verwaest wrote: > 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/0c953ad9-e968-40cf-bde3-692f5096c8fbn%40googlegroups.com.
