Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-18 18:00:31 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Bytecode/AsmInterpreter/gen_asm_offsets.cpp

415 lines
26 KiB
C++
Raw Permalink Normal View History

LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
/*
* Copyright (c) 2026, the Ladybird developers.
*
* SPDX-License-Identifier: BSD-2-Clause
*/
// Small build-time tool that prints struct field offsets as DSL constants.
// Compiled with the same flags as LibJS so layouts match exactly.
#include <AK/Format.h>
LibJS: Add a charCodeAt builtin bytecode fast path Teach builtin call specialization to recognize non-computed member calls to charCodeAt() and emit a dedicated builtin opcode. Mark String.prototype.charCodeAt with that builtin tag, then add an asm interpreter fast path for primitive-string receivers whose UTF-16 data is already resident. The asm path handles both ASCII-backed and UTF-16-backed resident strings, returns NaN for out-of-bounds Int32 indices, and falls back to the generic builtin call path for everything else. This keeps the optimistic case in asm while preserving the ordinary method call semantics when charCodeAt has been replaced or when string resolution would be required.
2026-04-12 14:06:57 +02:00
#include <AK/StringBase.h>
#include <AK/Utf16StringData.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Bytecode/Builtins.h>
#include <LibJS/Bytecode/Executable.h>
LibJS: Cache stable for-in iteration at bytecode sites Cache the flattened enumerable key snapshot for each `for..in` site and reuse a `PropertyNameIterator` when the receiver shape, dictionary generation, indexed storage kind and length, prototype chain validity, and magical-length state still match. Handle packed indexed receivers as well as plain named-property objects. Teach `ObjectPropertyIteratorNext` in `asmint.asm` to return cached property values directly and to fall back to the slow iterator logic when any guard fails. Treat arrays' hidden non-enumerable `length` property as a visited name for for-in shadowing, and include the receiver's magical-length state in the cache key so arrays and plain objects do not share snapshots. Add `test-js` and `test-js-bytecode` coverage for mixed numeric and named keys, packed receiver transitions, re-entry, iterator reuse, GC retention, array length shadowing, and same-site cache reuse.
2026-04-10 00:56:49 +02:00
#include <LibJS/Bytecode/PropertyNameIterator.h>
LibJS: Split packed and holey asm indexed fast paths Use dedicated Packed branches in GetByValue and PutByValue so in-bounds indexed accesses can skip hole checks and slot reloads. Keep Holey writes on the guarded arm, and keep append writes on the C++ slow path so PutByValue still respects non-extensible indexed objects and arrays with a non-writable length. Add a bytecode regression that exercises both append failure cases through the real js binary path.
2026-03-17 10:06:33 -05:00
#include <LibJS/Bytecode/PutKind.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Runtime/ArrayBuffer.h>
#include <LibJS/Runtime/DeclarativeEnvironment.h>
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
#include <LibJS/Runtime/ECMAScriptFunctionObject.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Runtime/ExecutionContext.h>
#include <LibJS/Runtime/FunctionObject.h>
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
#include <LibJS/Runtime/GlobalEnvironment.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Runtime/IndexedProperties.h>
LibJS: Call RawNativeFunction directly from asm Call The asm interpreter already inlines ECMAScript calls, but builtin calls still went through the generic C++ Call slow path even when the callee was a plain native function pointer. That added an avoidable boundary around hot builtin calls and kept asm from taking full advantage of the new RawNativeFunction representation. Teach the asm Call handler to recognize RawNativeFunction, allocate the callee frame on the interpreter stack, copy the call-site arguments, and jump straight to the stored C++ entry point. NativeJavaScriptBackedFunction and other non-raw callees keep falling through to the existing C++ slow path unchanged.
2026-04-14 21:07:19 +02:00
#include <LibJS/Runtime/NativeFunction.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Runtime/Object.h>
LibJS: Add a charCodeAt builtin bytecode fast path Teach builtin call specialization to recognize non-computed member calls to charCodeAt() and emit a dedicated builtin opcode. Mark String.prototype.charCodeAt with that builtin tag, then add an asm interpreter fast path for primitive-string receivers whose UTF-16 data is already resident. The asm path handles both ASCII-backed and UTF-16-backed resident strings, returns NaN for out-of-bounds Int32 indices, and falls back to the generic builtin call path for everything else. This keeps the optimistic case in asm while preserving the ordinary method call semantics when charCodeAt has been replaced or when string resolution would be required.
2026-04-12 14:06:57 +02:00
#include <LibJS/Runtime/PrimitiveString.h>
LibJS: Remove derivable fields from ExecutionContext Remove four fields that are trivially derivable from other fields already present in the ExecutionContext: - global_object (from realm) - global_declarative_environment (from realm) - identifier_table (from executable) - property_key_table (from executable) This shrinks ExecutionContext from 192 to 160 bytes (-17%). The asmint's GetGlobal/SetGlobal handlers now load through the realm pointer, taking advantage of the cached declarative environment pointer added in the previous commit.
2026-03-08 11:34:32 +01:00
#include <LibJS/Runtime/Realm.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Runtime/Shape.h>
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
#include <LibJS/Runtime/SharedFunctionInstanceData.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#include <LibJS/Runtime/TypedArray.h>
LibJS: Move bytecode interpreter state to VM The bytecode interpreter only needed the running execution context, but still threaded a separate Interpreter object through both the C++ and asm entry points. Move that state and the bytecode execution helpers onto VM instead, and teach the asm generator and slow paths to use VM directly.
2026-04-13 11:54:04 +02:00
#include <LibJS/Runtime/VM.h>
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
#define EMIT_OFFSET(name, type, member) \
outln("const " #name " = {}", offsetof(type, member))
#define EMIT_SIZEOF(name, type) \
outln("const " #name " = {}", sizeof(type))
int main()
{
using namespace JS;
using namespace JS::Bytecode;
LibJS: Add a charCodeAt builtin bytecode fast path Teach builtin call specialization to recognize non-computed member calls to charCodeAt() and emit a dedicated builtin opcode. Mark String.prototype.charCodeAt with that builtin tag, then add an asm interpreter fast path for primitive-string receivers whose UTF-16 data is already resident. The asm path handles both ASCII-backed and UTF-16-backed resident strings, returns NaN for out-of-bounds Int32 indices, and falls back to the generic builtin call path for everything else. This keeps the optimistic case in asm while preserving the ordinary method call semantics when charCodeAt has been replaced or when string resolution would be required.
2026-04-12 14:06:57 +02:00
struct PrimitiveStringLayoutAccessor : PrimitiveString {
using PrimitiveString::DeferredKind;
using PrimitiveString::m_deferred_kind;
using PrimitiveString::m_utf16_string;
};
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
outln("# Generated by gen_asm_offsets -- DO NOT EDIT\n");
// Object layout
outln("# Object layout");
EMIT_OFFSET(OBJECT_SHAPE, Object, m_shape);
LibJS: Replace Vector<Value> with Value* for named property storage Replace the 24-byte Vector<Value> m_storage with an 8-byte raw Value* m_named_properties pointer, backed by a malloc'd allocation with an inline capacity header. Memory layout of the allocation: [u32 capacity] [u32 padding] [Value 0] [Value 1] ... m_named_properties points to Value 0. This shrinks JS::Object from 64 to 48 bytes (on non-Windows platforms) and removes one level of indirection for property access in the asm interpreter, since the data pointer is now stored directly on the object rather than inside a Vector's internal metadata. Growth policy: max(4, max(needed, old_capacity * 2)).
2026-03-17 00:50:31 -05:00
EMIT_OFFSET(OBJECT_NAMED_PROPERTIES, Object, m_named_properties);
LibJS: Replace IndexedProperties with inline Packed/Holey/Dictionary Replace the OwnPtr<IndexedPropertyStorage> indirection with inline indexed element storage directly on Object. This eliminates virtual dispatch and reduces indirection for indexed property access. The new system uses three storage kinds tracked by IndexedStorageKind: - Packed: Dense array, no holes. Elements stored in a malloced Value* array with capacity header (same layout as named properties). - Holey: Dense array with possible holes marked by empty sentinel. Same physical layout as Packed. - Dictionary: Sparse storage using GenericIndexedPropertyStorage, type-punned into the m_indexed_elements pointer. Transitions: None->Packed->Holey->Dictionary (mostly monotonic). Dictionary mode triggers on non-default attributes or sparse arrays. Object keeps the same 48-byte size since m_indexed_elements (8 bytes) replaces IndexedProperties (8 bytes), and the storage kind + array size fit in existing padding alongside m_flags. The asm interpreter benefits from one fewer indirection: it now reads the element pointer and array size directly from Object fields instead of chasing through OwnPtr -> IndexedPropertyStorage -> Vector. Removes: IndexedProperties, SimpleIndexedPropertyStorage, IndexedPropertyStorage, IndexedPropertyIterator. Keeps: GenericIndexedPropertyStorage (for Dictionary mode).
2026-03-17 00:54:54 -05:00
EMIT_OFFSET(OBJECT_INDEXED_ELEMENTS, Object, m_indexed_elements);
EMIT_OFFSET(OBJECT_INDEXED_STORAGE_KIND, Object, m_indexed_storage_kind);
EMIT_OFFSET(OBJECT_INDEXED_ARRAY_LIKE_SIZE, Object, m_indexed_array_like_size);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_SIZEOF(OBJECT_SIZE, Object);
// Object flags byte
outln("\n# Object flags");
EMIT_OFFSET(OBJECT_FLAGS, Object, m_flags);
outln("const OBJECT_FLAG_HAS_MAGICAL_LENGTH = {}", Object::Flag::HasMagicalLengthProperty);
outln("const OBJECT_FLAG_MAY_INTERFERE = {}", Object::Flag::MayInterfereWithIndexedPropertyAccess);
outln("const OBJECT_FLAG_IS_TYPED_ARRAY = {}", Object::Flag::IsTypedArray);
outln("const OBJECT_FLAG_IS_FUNCTION = {}", Object::Flag::IsFunction);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
outln("const OBJECT_FLAG_IS_ECMASCRIPT_FUNCTION_OBJECT = {}", Object::Flag::IsECMAScriptFunctionObject);
LibJS: Call RawNativeFunction directly from asm Call The asm interpreter already inlines ECMAScript calls, but builtin calls still went through the generic C++ Call slow path even when the callee was a plain native function pointer. That added an avoidable boundary around hot builtin calls and kept asm from taking full advantage of the new RawNativeFunction representation. Teach the asm Call handler to recognize RawNativeFunction, allocate the callee frame on the interpreter stack, copy the call-site arguments, and jump straight to the stored C++ entry point. NativeJavaScriptBackedFunction and other non-raw callees keep falling through to the existing C++ slow path unchanged.
2026-04-14 21:07:19 +02:00
outln("const OBJECT_FLAG_IS_RAW_NATIVE_FUNCTION = {}", Object::Flag::IsRawNativeFunction);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
// Shape layout
outln("\n# Shape layout");
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(SHAPE_REALM, Shape, m_realm);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_OFFSET(SHAPE_PROTOTYPE, Shape, m_prototype);
EMIT_OFFSET(SHAPE_DICTIONARY_GENERATION, Shape, m_dictionary_generation);
EMIT_SIZEOF(SHAPE_SIZE, Shape);
// PropertyLookupCache layout
outln("\n# PropertyLookupCache layout");
EMIT_OFFSET(PROPERTY_LOOKUP_CACHE_ENTRIES, PropertyLookupCache, entries);
EMIT_SIZEOF(PROPERTY_LOOKUP_CACHE_SIZE, PropertyLookupCache);
// PropertyLookupCache::Entry layout
outln("\n# PropertyLookupCache::Entry layout");
EMIT_OFFSET(PROPERTY_LOOKUP_CACHE_ENTRY_PROPERTY_OFFSET, PropertyLookupCache::Entry, property_offset);
EMIT_OFFSET(PROPERTY_LOOKUP_CACHE_ENTRY_DICTIONARY_GENERATION, PropertyLookupCache::Entry, shape_dictionary_generation);
EMIT_OFFSET(PROPERTY_LOOKUP_CACHE_ENTRY_FROM_SHAPE, PropertyLookupCache::Entry, from_shape);
EMIT_OFFSET(PROPERTY_LOOKUP_CACHE_ENTRY_SHAPE, PropertyLookupCache::Entry, shape);
EMIT_OFFSET(PROPERTY_LOOKUP_CACHE_ENTRY_PROTOTYPE, PropertyLookupCache::Entry, prototype);
EMIT_OFFSET(PROPERTY_LOOKUP_CACHE_ENTRY_PROTOTYPE_CHAIN_VALIDITY, PropertyLookupCache::Entry, prototype_chain_validity);
EMIT_SIZEOF(PROPERTY_LOOKUP_CACHE_ENTRY_SIZE, PropertyLookupCache::Entry);
// Composite offsets for entry[0] within a PropertyLookupCache
outln("\n# Entry[0] offsets within PropertyLookupCache");
auto plc_entries = offsetof(PropertyLookupCache, entries);
outln("const PROPERTY_LOOKUP_CACHE_ENTRY0_PROPERTY_OFFSET = {}", plc_entries + offsetof(PropertyLookupCache::Entry, property_offset));
outln("const PROPERTY_LOOKUP_CACHE_ENTRY0_DICTIONARY_GENERATION = {}", plc_entries + offsetof(PropertyLookupCache::Entry, shape_dictionary_generation));
outln("const PROPERTY_LOOKUP_CACHE_ENTRY0_SHAPE = {}", plc_entries + offsetof(PropertyLookupCache::Entry, shape));
outln("const PROPERTY_LOOKUP_CACHE_ENTRY0_PROTOTYPE = {}", plc_entries + offsetof(PropertyLookupCache::Entry, prototype));
outln("const PROPERTY_LOOKUP_CACHE_ENTRY0_PROTOTYPE_CHAIN_VALIDITY = {}", plc_entries + offsetof(PropertyLookupCache::Entry, prototype_chain_validity));
LibJS: Cache stable for-in iteration at bytecode sites Cache the flattened enumerable key snapshot for each `for..in` site and reuse a `PropertyNameIterator` when the receiver shape, dictionary generation, indexed storage kind and length, prototype chain validity, and magical-length state still match. Handle packed indexed receivers as well as plain named-property objects. Teach `ObjectPropertyIteratorNext` in `asmint.asm` to return cached property values directly and to fall back to the slow iterator logic when any guard fails. Treat arrays' hidden non-enumerable `length` property as a visited name for for-in shadowing, and include the receiver's magical-length state in the cache key so arrays and plain objects do not share snapshots. Add `test-js` and `test-js-bytecode` coverage for mixed numeric and named keys, packed receiver transitions, re-entry, iterator reuse, GC retention, array length shadowing, and same-site cache reuse.
2026-04-10 00:56:49 +02:00
// ObjectPropertyIteratorCacheData layout
outln("\n# ObjectPropertyIteratorCacheData layout");
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_PROPERTIES, ObjectPropertyIteratorCacheData, m_properties);
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_PROPERTY_VALUES, ObjectPropertyIteratorCacheData, m_property_values);
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_SHAPE, ObjectPropertyIteratorCacheData, m_shape);
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_PROTOTYPE_CHAIN_VALIDITY, ObjectPropertyIteratorCacheData, m_prototype_chain_validity);
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_INDEXED_PROPERTY_COUNT, ObjectPropertyIteratorCacheData, m_indexed_property_count);
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_SHAPE_DICTIONARY_GENERATION, ObjectPropertyIteratorCacheData, m_shape_dictionary_generation);
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_FAST_PATH, ObjectPropertyIteratorCacheData, m_fast_path);
// ObjectPropertyIteratorCache layout
outln("\n# ObjectPropertyIteratorCache layout");
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_DATA_PTR, ObjectPropertyIteratorCache, data);
EMIT_OFFSET(OBJECT_PROPERTY_ITERATOR_CACHE_REUSABLE_PROPERTY_NAME_ITERATOR, ObjectPropertyIteratorCache, reusable_property_name_iterator);
// PropertyNameIterator layout
outln("\n# PropertyNameIterator layout");
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_OBJECT, PropertyNameIterator, m_object);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_PROPERTY_CACHE, PropertyNameIterator, m_property_cache);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_SHAPE, PropertyNameIterator, m_shape);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_PROTOTYPE_CHAIN_VALIDITY, PropertyNameIterator, m_prototype_chain_validity);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_ITERATOR_CACHE_SLOT, PropertyNameIterator, m_iterator_cache_slot);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_INDEXED_PROPERTY_COUNT, PropertyNameIterator, m_indexed_property_count);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_NEXT_INDEXED_PROPERTY, PropertyNameIterator, m_next_indexed_property);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_NEXT_PROPERTY, PropertyNameIterator, m_next_property);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_SHAPE_IS_DICTIONARY, PropertyNameIterator, m_shape_is_dictionary);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_SHAPE_DICTIONARY_GENERATION, PropertyNameIterator, m_shape_dictionary_generation);
EMIT_OFFSET(PROPERTY_NAME_ITERATOR_FAST_PATH, PropertyNameIterator, m_fast_path);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
// Executable layout
outln("\n# Executable layout");
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTABLE_CONSTANTS, Executable, constants);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_OFFSET(EXECUTABLE_PROPERTY_LOOKUP_CACHES, Executable, property_lookup_caches);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTABLE_REGISTERS_AND_LOCALS_COUNT, Executable, registers_and_locals_count);
LibJS: Use precomputed asm Call frame counts Executable already caches the combined registers, locals, and constants count that the asm Call fast path needs for inline frame allocation. Use that precomputed total instead of rebuilding it from the registers count and constants vector size in the hot path.
2026-04-14 09:54:02 +02:00
EMIT_OFFSET(EXECUTABLE_REGISTERS_AND_LOCALS_AND_CONSTANTS_COUNT, Executable, registers_and_locals_and_constants_count);
LibJS: Cache Executable constants for asm Call Mirror Executable's constants size and data pointer in adjacent fields so the asm Call fast path can pair-load them together. The underlying Vector layout keeps size and data apart, so a small cached raw span lets the hot constant-copy loop fetch both pieces of metadata at once.
2026-04-14 10:16:33 +02:00
EMIT_OFFSET(EXECUTABLE_ASM_CONSTANTS_SIZE, Executable, asm_constants_size);
EMIT_OFFSET(EXECUTABLE_ASM_CONSTANTS_DATA, Executable, asm_constants_data);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
// ExecutionContext layout
outln("\n# ExecutionContext layout");
LibJS: Inline asm interpreter JS Call fast path Handle inline-eligible JS-to-JS Call directly in asmint.asm instead of routing the whole operation through AsmInterpreter.cpp. The asm handler now validates the callee, binds `this` for the non-allocating cases, reserves the callee InterpreterStack frame, populates the ExecutionContext header and Value tail, and enters the callee bytecode at pc 0. Keep the cases that need NewFunctionEnvironment() or sloppy `this` boxing on a narrow helper that still builds an inline frame. This preserves the existing inline-call semantics for promise-job ordering, receiver binding, and sloppy global-this handling while keeping the common path in assembly. Add regression coverage for closure-capturing callees, sloppy primitive receivers, and sloppy undefined receivers.
2026-04-13 21:35:17 +02:00
VERIFY(alignof(ExecutionContext) == sizeof(Value));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_OFFSET(EXECUTION_CONTEXT_EXECUTABLE, ExecutionContext, executable);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_FUNCTION, ExecutionContext, function);
LibJS: Remove derivable fields from ExecutionContext Remove four fields that are trivially derivable from other fields already present in the ExecutionContext: - global_object (from realm) - global_declarative_environment (from realm) - identifier_table (from executable) - property_key_table (from executable) This shrinks ExecutionContext from 192 to 160 bytes (-17%). The asmint's GetGlobal/SetGlobal handlers now load through the realm pointer, taking advantage of the cached declarative environment pointer added in the previous commit.
2026-03-08 11:34:32 +01:00
EMIT_OFFSET(EXECUTION_CONTEXT_REALM, ExecutionContext, realm);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_SCRIPT_OR_MODULE, ExecutionContext, script_or_module);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_OFFSET(EXECUTION_CONTEXT_LEXICAL_ENVIRONMENT, ExecutionContext, lexical_environment);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_VARIABLE_ENVIRONMENT, ExecutionContext, variable_environment);
EMIT_OFFSET(EXECUTION_CONTEXT_PRIVATE_ENVIRONMENT, ExecutionContext, private_environment);
LibJS: Inline asm interpreter JS Call fast path Handle inline-eligible JS-to-JS Call directly in asmint.asm instead of routing the whole operation through AsmInterpreter.cpp. The asm handler now validates the callee, binds `this` for the non-allocating cases, reserves the callee InterpreterStack frame, populates the ExecutionContext header and Value tail, and enters the callee bytecode at pc 0. Keep the cases that need NewFunctionEnvironment() or sloppy `this` boxing on a narrow helper that still builds an inline frame. This preserves the existing inline-call semantics for promise-job ordering, receiver binding, and sloppy global-this handling while keeping the common path in assembly. Add regression coverage for closure-capturing callees, sloppy primitive receivers, and sloppy undefined receivers.
2026-04-13 21:35:17 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_SKIP_WHEN_DETERMINING_INCUMBENT_COUNTER, ExecutionContext, skip_when_determining_incumbent_counter);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_YIELD_CONTINUATION, ExecutionContext, yield_continuation);
EMIT_OFFSET(EXECUTION_CONTEXT_YIELD_IS_AWAIT, ExecutionContext, yield_is_await);
EMIT_OFFSET(EXECUTION_CONTEXT_CALLER_IS_CONSTRUCT, ExecutionContext, caller_is_construct);
EMIT_OFFSET(EXECUTION_CONTEXT_THIS_VALUE, ExecutionContext, this_value);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_OFFSET(EXECUTION_CONTEXT_CALLER_FRAME, ExecutionContext, caller_frame);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_PASSED_ARGUMENT_COUNT, ExecutionContext, passed_argument_count);
LibJS: Handle AsmInt returns without C++ helpers Handle Return and End entirely in AsmInt when leaving an inline frame. The handlers now restore the caller, update the interpreter stack bookkeeping directly, and bump the execution generation without bouncing through AsmInterpreter.cpp. Add WeakRef tests that exercise both inline Return and inline End so this path stays covered.
2026-04-13 16:54:18 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_CALLER_RETURN_PC, ExecutionContext, caller_return_pc);
EMIT_OFFSET(EXECUTION_CONTEXT_CALLER_DST_RAW, ExecutionContext, caller_dst_raw);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_OFFSET(EXECUTION_CONTEXT_PROGRAM_COUNTER, ExecutionContext, program_counter);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(EXECUTION_CONTEXT_REGISTERS_AND_CONSTANTS_AND_LOCALS_AND_ARGUMENTS_COUNT, ExecutionContext, registers_and_constants_and_locals_and_arguments_count);
EMIT_OFFSET(EXECUTION_CONTEXT_ARGUMENT_COUNT, ExecutionContext, argument_count);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_SIZEOF(SIZEOF_EXECUTION_CONTEXT, ExecutionContext);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
outln("const ALIGNOF_EXECUTION_CONTEXT = {}", alignof(ExecutionContext));
outln("const EXECUTION_CONTEXT_NO_YIELD_CONTINUATION = {}", ExecutionContext::no_yield_continuation);
outln("const SIZEOF_SCRIPT_OR_MODULE = {}", sizeof(ScriptOrModule));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
LibJS: Handle AsmInt returns without C++ helpers Handle Return and End entirely in AsmInt when leaving an inline frame. The handlers now restore the caller, update the interpreter stack bookkeeping directly, and bump the execution generation without bouncing through AsmInterpreter.cpp. Add WeakRef tests that exercise both inline Return and inline End so this path stays covered.
2026-04-13 16:54:18 +02:00
// InterpreterStack layout
outln("\n# InterpreterStack layout");
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(INTERPRETER_STACK_LIMIT, InterpreterStack, m_limit);
LibJS: Handle AsmInt returns without C++ helpers Handle Return and End entirely in AsmInt when leaving an inline frame. The handlers now restore the caller, update the interpreter stack bookkeeping directly, and bump the execution generation without bouncing through AsmInterpreter.cpp. Add WeakRef tests that exercise both inline Return and inline End so this path stays covered.
2026-04-13 16:54:18 +02:00
EMIT_OFFSET(INTERPRETER_STACK_TOP, InterpreterStack, m_top);
LibJS: Remove derivable fields from ExecutionContext Remove four fields that are trivially derivable from other fields already present in the ExecutionContext: - global_object (from realm) - global_declarative_environment (from realm) - identifier_table (from executable) - property_key_table (from executable) This shrinks ExecutionContext from 192 to 160 bytes (-17%). The asmint's GetGlobal/SetGlobal handlers now load through the realm pointer, taking advantage of the cached declarative environment pointer added in the previous commit.
2026-03-08 11:34:32 +01:00
// Realm layout
outln("\n# Realm layout");
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(REALM_GLOBAL_ENVIRONMENT, Realm, m_global_environment);
LibJS: Remove derivable fields from ExecutionContext Remove four fields that are trivially derivable from other fields already present in the ExecutionContext: - global_object (from realm) - global_declarative_environment (from realm) - identifier_table (from executable) - property_key_table (from executable) This shrinks ExecutionContext from 192 to 160 bytes (-17%). The asmint's GetGlobal/SetGlobal handlers now load through the realm pointer, taking advantage of the cached declarative environment pointer added in the previous commit.
2026-03-08 11:34:32 +01:00
EMIT_OFFSET(REALM_GLOBAL_OBJECT, Realm, m_global_object);
EMIT_OFFSET(REALM_GLOBAL_DECLARATIVE_ENVIRONMENT, Realm, m_global_declarative_environment);
LibJS: Move bytecode interpreter state to VM The bytecode interpreter only needed the running execution context, but still threaded a separate Interpreter object through both the C++ and asm entry points. Move that state and the bytecode execution helpers onto VM instead, and teach the asm generator and slow paths to use VM directly.
2026-04-13 11:54:04 +02:00
// VM layout
outln("\n# VM layout");
EMIT_OFFSET(VM_RUNNING_EXECUTION_CONTEXT, VM, m_running_execution_context);
LibJS: Handle AsmInt returns without C++ helpers Handle Return and End entirely in AsmInt when leaving an inline frame. The handlers now restore the caller, update the interpreter stack bookkeeping directly, and bump the execution generation without bouncing through AsmInterpreter.cpp. Add WeakRef tests that exercise both inline Return and inline End so this path stays covered.
2026-04-13 16:54:18 +02:00
EMIT_OFFSET(VM_INTERPRETER_STACK, VM, m_interpreter_stack);
LibJS: Call RawNativeFunction directly from asm Call The asm interpreter already inlines ECMAScript calls, but builtin calls still went through the generic C++ Call slow path even when the callee was a plain native function pointer. That added an avoidable boundary around hot builtin calls and kept asm from taking full advantage of the new RawNativeFunction representation. Teach the asm Call handler to recognize RawNativeFunction, allocate the callee frame on the interpreter stack, copy the call-site arguments, and jump straight to the stored C++ entry point. NativeJavaScriptBackedFunction and other non-raw callees keep falling through to the existing C++ slow path unchanged.
2026-04-14 21:07:19 +02:00
EMIT_OFFSET(VM_STACK_INFO, VM, m_stack_info);
LibJS: Handle AsmInt returns without C++ helpers Handle Return and End entirely in AsmInt when leaving an inline frame. The handlers now restore the caller, update the interpreter stack bookkeeping directly, and bump the execution generation without bouncing through AsmInterpreter.cpp. Add WeakRef tests that exercise both inline Return and inline End so this path stays covered.
2026-04-13 16:54:18 +02:00
EMIT_OFFSET(VM_EXECUTION_GENERATION, VM, m_execution_generation);
outln("const VM_INTERPRETER_STACK_TOP = {}", offsetof(VM, m_interpreter_stack) + offsetof(InterpreterStack, m_top));
LibJS: Call RawNativeFunction directly from asm Call The asm interpreter already inlines ECMAScript calls, but builtin calls still went through the generic C++ Call slow path even when the callee was a plain native function pointer. That added an avoidable boundary around hot builtin calls and kept asm from taking full advantage of the new RawNativeFunction representation. Teach the asm Call handler to recognize RawNativeFunction, allocate the callee frame on the interpreter stack, copy the call-site arguments, and jump straight to the stored C++ entry point. NativeJavaScriptBackedFunction and other non-raw callees keep falling through to the existing C++ slow path unchanged.
2026-04-14 21:07:19 +02:00
#if defined(HAS_ADDRESS_SANITIZER)
outln("const VM_STACK_SPACE_LIMIT = {}", 96 * KiB);
#else
outln("const VM_STACK_SPACE_LIMIT = {}", 32 * KiB);
#endif
// StackInfo layout
outln("\n# StackInfo layout");
EMIT_OFFSET(STACK_INFO_BASE, StackInfo, m_base);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
LibJS: Replace IndexedProperties with inline Packed/Holey/Dictionary Replace the OwnPtr<IndexedPropertyStorage> indirection with inline indexed element storage directly on Object. This eliminates virtual dispatch and reduces indirection for indexed property access. The new system uses three storage kinds tracked by IndexedStorageKind: - Packed: Dense array, no holes. Elements stored in a malloced Value* array with capacity header (same layout as named properties). - Holey: Dense array with possible holes marked by empty sentinel. Same physical layout as Packed. - Dictionary: Sparse storage using GenericIndexedPropertyStorage, type-punned into the m_indexed_elements pointer. Transitions: None->Packed->Holey->Dictionary (mostly monotonic). Dictionary mode triggers on non-default attributes or sparse arrays. Object keeps the same 48-byte size since m_indexed_elements (8 bytes) replaces IndexedProperties (8 bytes), and the storage kind + array size fit in existing padding alongside m_flags. The asm interpreter benefits from one fewer indirection: it now reads the element pointer and array size directly from Object fields instead of chasing through OwnPtr -> IndexedPropertyStorage -> Vector. Removes: IndexedProperties, SimpleIndexedPropertyStorage, IndexedPropertyStorage, IndexedPropertyIterator. Keeps: GenericIndexedPropertyStorage (for Dictionary mode).
2026-03-17 00:54:54 -05:00
// IndexedStorageKind enum values
outln("\n# IndexedStorageKind enum values");
outln("const INDEXED_STORAGE_KIND_NONE = {}", static_cast<u8>(IndexedStorageKind::None));
outln("const INDEXED_STORAGE_KIND_PACKED = {}", static_cast<u8>(IndexedStorageKind::Packed));
outln("const INDEXED_STORAGE_KIND_HOLEY = {}", static_cast<u8>(IndexedStorageKind::Holey));
outln("const INDEXED_STORAGE_KIND_DICTIONARY = {}", static_cast<u8>(IndexedStorageKind::Dictionary));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
LibJS: Cache stable for-in iteration at bytecode sites Cache the flattened enumerable key snapshot for each `for..in` site and reuse a `PropertyNameIterator` when the receiver shape, dictionary generation, indexed storage kind and length, prototype chain validity, and magical-length state still match. Handle packed indexed receivers as well as plain named-property objects. Teach `ObjectPropertyIteratorNext` in `asmint.asm` to return cached property values directly and to fall back to the slow iterator logic when any guard fails. Treat arrays' hidden non-enumerable `length` property as a visited name for for-in shadowing, and include the receiver's magical-length state in the cache key so arrays and plain objects do not share snapshots. Add `test-js` and `test-js-bytecode` coverage for mixed numeric and named keys, packed receiver transitions, re-entry, iterator reuse, GC retention, array length shadowing, and same-site cache reuse.
2026-04-10 00:56:49 +02:00
// ObjectPropertyIteratorFastPath enum values
outln("\n# ObjectPropertyIteratorFastPath enum values");
outln("const OBJECT_PROPERTY_ITERATOR_FAST_PATH_NONE = {}", static_cast<u8>(ObjectPropertyIteratorFastPath::None));
outln("const OBJECT_PROPERTY_ITERATOR_FAST_PATH_PLAIN_NAMED = {}", static_cast<u8>(ObjectPropertyIteratorFastPath::PlainNamed));
outln("const OBJECT_PROPERTY_ITERATOR_FAST_PATH_PACKED_INDEXED = {}", static_cast<u8>(ObjectPropertyIteratorFastPath::PackedIndexed));
LibJS: Replace IndexedProperties with inline Packed/Holey/Dictionary Replace the OwnPtr<IndexedPropertyStorage> indirection with inline indexed element storage directly on Object. This eliminates virtual dispatch and reduces indirection for indexed property access. The new system uses three storage kinds tracked by IndexedStorageKind: - Packed: Dense array, no holes. Elements stored in a malloced Value* array with capacity header (same layout as named properties). - Holey: Dense array with possible holes marked by empty sentinel. Same physical layout as Packed. - Dictionary: Sparse storage using GenericIndexedPropertyStorage, type-punned into the m_indexed_elements pointer. Transitions: None->Packed->Holey->Dictionary (mostly monotonic). Dictionary mode triggers on non-default attributes or sparse arrays. Object keeps the same 48-byte size since m_indexed_elements (8 bytes) replaces IndexedProperties (8 bytes), and the storage kind + array size fit in existing padding alongside m_flags. The asm interpreter benefits from one fewer indirection: it now reads the element pointer and array size directly from Object fields instead of chasing through OwnPtr -> IndexedPropertyStorage -> Vector. Removes: IndexedProperties, SimpleIndexedPropertyStorage, IndexedPropertyStorage, IndexedPropertyIterator. Keeps: GenericIndexedPropertyStorage (for Dictionary mode).
2026-03-17 00:54:54 -05:00
// Vector<Value> layout (used for bytecode)
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
outln("\n# Vector<Value> layout");
{
Vector<Value> v;
auto base = reinterpret_cast<uintptr_t>(&v);
auto vec_data = reinterpret_cast<uintptr_t>(&v.m_metadata.outline_buffer) - base;
auto vec_size = reinterpret_cast<uintptr_t>(&v.m_size) - base;
outln("const VECTOR_DATA = {}", vec_data);
outln("const VECTOR_SIZE = {}", vec_size);
// Composite offset for Executable.bytecode data pointer
outln("const EXECUTABLE_BYTECODE_DATA = {}", offsetof(Executable, bytecode) + vec_data);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
outln("const EXECUTABLE_CONSTANTS_DATA = {}", offsetof(Executable, constants) + vec_data);
outln("const EXECUTABLE_CONSTANTS_SIZE = {}", offsetof(Executable, constants) + vec_size);
LibJS: Cache stable for-in iteration at bytecode sites Cache the flattened enumerable key snapshot for each `for..in` site and reuse a `PropertyNameIterator` when the receiver shape, dictionary generation, indexed storage kind and length, prototype chain validity, and magical-length state still match. Handle packed indexed receivers as well as plain named-property objects. Teach `ObjectPropertyIteratorNext` in `asmint.asm` to return cached property values directly and to fall back to the slow iterator logic when any guard fails. Treat arrays' hidden non-enumerable `length` property as a visited name for for-in shadowing, and include the receiver's magical-length state in the cache key so arrays and plain objects do not share snapshots. Add `test-js` and `test-js-bytecode` coverage for mixed numeric and named keys, packed receiver transitions, re-entry, iterator reuse, GC retention, array length shadowing, and same-site cache reuse.
2026-04-10 00:56:49 +02:00
outln("const OBJECT_PROPERTY_ITERATOR_CACHE_DATA_PROPERTY_VALUES_DATA = {}", offsetof(ObjectPropertyIteratorCacheData, m_property_values) + vec_data);
outln("const OBJECT_PROPERTY_ITERATOR_CACHE_DATA_PROPERTY_VALUES_SIZE = {}", offsetof(ObjectPropertyIteratorCacheData, m_property_values) + vec_size);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
}
LibJS: Replace IndexedProperties with inline Packed/Holey/Dictionary Replace the OwnPtr<IndexedPropertyStorage> indirection with inline indexed element storage directly on Object. This eliminates virtual dispatch and reduces indirection for indexed property access. The new system uses three storage kinds tracked by IndexedStorageKind: - Packed: Dense array, no holes. Elements stored in a malloced Value* array with capacity header (same layout as named properties). - Holey: Dense array with possible holes marked by empty sentinel. Same physical layout as Packed. - Dictionary: Sparse storage using GenericIndexedPropertyStorage, type-punned into the m_indexed_elements pointer. Transitions: None->Packed->Holey->Dictionary (mostly monotonic). Dictionary mode triggers on non-default attributes or sparse arrays. Object keeps the same 48-byte size since m_indexed_elements (8 bytes) replaces IndexedProperties (8 bytes), and the storage kind + array size fit in existing padding alongside m_flags. The asm interpreter benefits from one fewer indirection: it now reads the element pointer and array size directly from Object fields instead of chasing through OwnPtr -> IndexedPropertyStorage -> Vector. Removes: IndexedProperties, SimpleIndexedPropertyStorage, IndexedPropertyStorage, IndexedPropertyIterator. Keeps: GenericIndexedPropertyStorage (for Dictionary mode).
2026-03-17 00:54:54 -05:00
// PutKind enum
outln("\n# PutKind enum");
outln("const PUT_KIND_NORMAL = {}", static_cast<u8>(JS::Bytecode::PutKind::Normal));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
// PrototypeChainValidity layout
outln("\n# PrototypeChainValidity layout");
EMIT_OFFSET(PROTOTYPE_CHAIN_VALIDITY_VALID, PrototypeChainValidity, m_valid);
// DeclarativeEnvironment layout
outln("\n# DeclarativeEnvironment layout");
EMIT_OFFSET(DECLARATIVE_ENVIRONMENT_SERIAL, DeclarativeEnvironment, m_environment_serial_number);
// GlobalVariableCache layout
outln("\n# GlobalVariableCache layout");
EMIT_OFFSET(GLOBAL_VARIABLE_CACHE_ENVIRONMENT_SERIAL, GlobalVariableCache, environment_serial_number);
EMIT_OFFSET(GLOBAL_VARIABLE_CACHE_ENVIRONMENT_BINDING_INDEX, GlobalVariableCache, environment_binding_index);
EMIT_OFFSET(GLOBAL_VARIABLE_CACHE_HAS_ENVIRONMENT_BINDING, GlobalVariableCache, has_environment_binding_index);
AsmInt: Inline environment binding path for GetGlobal/SetGlobal Instead of calling into C++ helpers for global let/const variable access, inline the binding lookup directly in the asm handlers. This avoids the overhead of a C++ call for the common case. Module environments still use the C++ helper since they require additional lookups that aren't worth inlining.
2026-03-07 23:51:11 +01:00
EMIT_OFFSET(GLOBAL_VARIABLE_CACHE_IN_MODULE_ENVIRONMENT, GlobalVariableCache, in_module_environment);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
EMIT_SIZEOF(GLOBAL_VARIABLE_CACHE_SIZE, GlobalVariableCache);
// Builtin enum values
outln("\n# Builtin enum values");
outln("const BUILTIN_MATH_ABS = {}", static_cast<u8>(Bytecode::Builtin::MathAbs));
outln("const BUILTIN_MATH_FLOOR = {}", static_cast<u8>(Bytecode::Builtin::MathFloor));
outln("const BUILTIN_MATH_CEIL = {}", static_cast<u8>(Bytecode::Builtin::MathCeil));
outln("const BUILTIN_MATH_ROUND = {}", static_cast<u8>(Bytecode::Builtin::MathRound));
outln("const BUILTIN_MATH_SQRT = {}", static_cast<u8>(Bytecode::Builtin::MathSqrt));
outln("const BUILTIN_MATH_EXP = {}", static_cast<u8>(Bytecode::Builtin::MathExp));
LibJS: Add a String.fromCharCode builtin opcode Specialize only the fixed unary case in the bytecode generator and let all other argument counts keep using the generic Call instruction. This keeps the builtin bytecode simple while still covering the common fast path. The asm interpreter handles int32 inputs directly, applies the ToUint16 mask in-place, and reuses the VM's cached ASCII single-character strings when the result is 7-bit representable. Non-ASCII single code unit results stay on the dedicated builtin path via a small helper, and the dedicated slow path still handles the generic cases.
2026-04-12 16:12:40 +02:00
outln("const BUILTIN_STRING_FROM_CHAR_CODE = {}", static_cast<u8>(Bytecode::Builtin::StringFromCharCode));
LibJS: Add a charCodeAt builtin bytecode fast path Teach builtin call specialization to recognize non-computed member calls to charCodeAt() and emit a dedicated builtin opcode. Mark String.prototype.charCodeAt with that builtin tag, then add an asm interpreter fast path for primitive-string receivers whose UTF-16 data is already resident. The asm path handles both ASCII-backed and UTF-16-backed resident strings, returns NaN for out-of-bounds Int32 indices, and falls back to the generic builtin call path for everything else. This keeps the optimistic case in asm while preserving the ordinary method call semantics when charCodeAt has been replaced or when string resolution would be required.
2026-04-12 14:06:57 +02:00
outln("const BUILTIN_STRING_PROTOTYPE_CHAR_CODE_AT = {}", static_cast<u8>(Bytecode::Builtin::StringPrototypeCharCodeAt));
LibJS: Add a charAt builtin bytecode fast path Tag String.prototype.charAt as a builtin and emit a dedicated bytecode instruction for non-computed calls. The asm interpreter can then stay on the fast path when the receiver is a primitive string with resident UTF-16 data and the selected code unit is ASCII. In that case we can return the VM's cached empty or single-character ASCII string directly.
2026-04-12 14:11:55 +02:00
outln("const BUILTIN_STRING_PROTOTYPE_CHAR_AT = {}", static_cast<u8>(Bytecode::Builtin::StringPrototypeCharAt));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
// FunctionObject layout
outln("\n# FunctionObject layout");
EMIT_OFFSET(FUNCTION_OBJECT_BUILTIN, FunctionObject, m_builtin);
{
// Optional<Builtin> has a value byte and a has_value byte.
auto base = offsetof(FunctionObject, m_builtin);
// Optional<Builtin> stores value at offset 0, has_value bool at offset 1.
// Verify this assumption at compile time:
Optional<Bytecode::Builtin> opt_test { Bytecode::Builtin::MathFloor };
auto const* raw = reinterpret_cast<u8 const*>(&opt_test);
VERIFY(raw[0] == static_cast<u8>(Bytecode::Builtin::MathFloor));
VERIFY(raw[1] == 1); // has_value
outln("const FUNCTION_OBJECT_BUILTIN_VALUE = {}", base);
outln("const FUNCTION_OBJECT_BUILTIN_HAS_VALUE = {}", base + 1);
}
LibJS: Call RawNativeFunction directly from asm Call The asm interpreter already inlines ECMAScript calls, but builtin calls still went through the generic C++ Call slow path even when the callee was a plain native function pointer. That added an avoidable boundary around hot builtin calls and kept asm from taking full advantage of the new RawNativeFunction representation. Teach the asm Call handler to recognize RawNativeFunction, allocate the callee frame on the interpreter stack, copy the call-site arguments, and jump straight to the stored C++ entry point. NativeJavaScriptBackedFunction and other non-raw callees keep falling through to the existing C++ slow path unchanged.
2026-04-14 21:07:19 +02:00
// RawNativeFunction layout
outln("\n# RawNativeFunction layout");
EMIT_OFFSET(RAW_NATIVE_FUNCTION_NATIVE_FUNCTION, RawNativeFunction, m_native_function);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
// ECMAScriptFunctionObject layout
outln("\n# ECMAScriptFunctionObject layout");
EMIT_OFFSET(ECMASCRIPT_FUNCTION_OBJECT_SHARED_DATA, ECMAScriptFunctionObject, m_shared_data);
EMIT_OFFSET(ECMASCRIPT_FUNCTION_OBJECT_ENVIRONMENT, ECMAScriptFunctionObject, m_environment);
EMIT_OFFSET(ECMASCRIPT_FUNCTION_OBJECT_PRIVATE_ENVIRONMENT, ECMAScriptFunctionObject, m_private_environment);
EMIT_OFFSET(ECMASCRIPT_FUNCTION_OBJECT_SCRIPT_OR_MODULE, ECMAScriptFunctionObject, m_script_or_module);
// SharedFunctionInstanceData layout
outln("\n# SharedFunctionInstanceData layout");
EMIT_OFFSET(SHARED_FUNCTION_INSTANCE_DATA_EXECUTABLE, SharedFunctionInstanceData, m_executable);
LibJS: Pack asm Call shared-data metadata Pack the asm Call fast path metadata next to the executable pointer so the interpreter can fetch both values with one paired load. This removes several dependent shared-data loads from the hot path. Keep the executable pointer and packed metadata in separate registers through this binding so the fast path can still use the paired-load layout after any non-strict this adjustment. Lower the packed metadata flag checks correctly on x86_64 as well. Those bits now live above bit 31, so the generator uses bt for single- bit high masks and covers that path with a unit test. Add a runtime test that exercises both object and global this binding through the asm Call fast path.
2026-04-14 09:56:33 +02:00
EMIT_OFFSET(SHARED_FUNCTION_INSTANCE_DATA_ASM_CALL_METADATA, SharedFunctionInstanceData, m_asm_call_metadata);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
EMIT_OFFSET(SHARED_FUNCTION_INSTANCE_DATA_FORMAL_PARAMETER_COUNT, SharedFunctionInstanceData, m_formal_parameter_count);
EMIT_OFFSET(SHARED_FUNCTION_INSTANCE_DATA_STRICT, SharedFunctionInstanceData, m_strict);
EMIT_OFFSET(SHARED_FUNCTION_INSTANCE_DATA_FUNCTION_ENVIRONMENT_NEEDED, SharedFunctionInstanceData, m_function_environment_needed);
EMIT_OFFSET(SHARED_FUNCTION_INSTANCE_DATA_USES_THIS, SharedFunctionInstanceData, m_uses_this);
EMIT_OFFSET(SHARED_FUNCTION_INSTANCE_DATA_CAN_INLINE_CALL, SharedFunctionInstanceData, m_can_inline_call);
LibJS: Pack asm Call shared-data metadata Pack the asm Call fast path metadata next to the executable pointer so the interpreter can fetch both values with one paired load. This removes several dependent shared-data loads from the hot path. Keep the executable pointer and packed metadata in separate registers through this binding so the fast path can still use the paired-load layout after any non-strict this adjustment. Lower the packed metadata flag checks correctly on x86_64 as well. Those bits now live above bit 31, so the generator uses bt for single- bit high masks and covers that path with a unit test. Add a runtime test that exercises both object and global this binding through the asm Call fast path.
2026-04-14 09:56:33 +02:00
outln("const SHARED_FUNCTION_INSTANCE_DATA_ASM_CALL_METADATA_CAN_INLINE_CALL = {}", SharedFunctionInstanceData::asm_call_metadata_can_inline_call);
outln("const SHARED_FUNCTION_INSTANCE_DATA_ASM_CALL_METADATA_FUNCTION_ENVIRONMENT_NEEDED = {}", SharedFunctionInstanceData::asm_call_metadata_function_environment_needed);
outln("const SHARED_FUNCTION_INSTANCE_DATA_ASM_CALL_METADATA_USES_THIS = {}", SharedFunctionInstanceData::asm_call_metadata_uses_this);
outln("const SHARED_FUNCTION_INSTANCE_DATA_ASM_CALL_METADATA_STRICT = {}", SharedFunctionInstanceData::asm_call_metadata_strict);
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
// GlobalEnvironment layout
outln("\n# GlobalEnvironment layout");
EMIT_OFFSET(GLOBAL_ENVIRONMENT_GLOBAL_THIS_VALUE, GlobalEnvironment, m_global_this_value);
LibJS: Add a charCodeAt builtin bytecode fast path Teach builtin call specialization to recognize non-computed member calls to charCodeAt() and emit a dedicated builtin opcode. Mark String.prototype.charCodeAt with that builtin tag, then add an asm interpreter fast path for primitive-string receivers whose UTF-16 data is already resident. The asm path handles both ASCII-backed and UTF-16-backed resident strings, returns NaN for out-of-bounds Int32 indices, and falls back to the generic builtin call path for everything else. This keeps the optimistic case in asm while preserving the ordinary method call semantics when charCodeAt has been replaced or when string resolution would be required.
2026-04-12 14:06:57 +02:00
// PrimitiveString layout
outln("\n# PrimitiveString layout");
EMIT_OFFSET(PRIMITIVE_STRING_DEFERRED_KIND, PrimitiveStringLayoutAccessor, m_deferred_kind);
EMIT_OFFSET(PRIMITIVE_STRING_UTF16_STRING, PrimitiveStringLayoutAccessor, m_utf16_string);
outln("const PRIMITIVE_STRING_DEFERRED_KIND_NONE = {}", static_cast<u8>(PrimitiveStringLayoutAccessor::DeferredKind::None));
// Utf16String / ShortString layout
outln("\n# Utf16String layout");
outln("const UTF16_SHORT_STRING_FLAG = {}", AK::Detail::StringBase::SHORT_STRING_FLAG);
outln("const UTF16_SHORT_STRING_BYTE_COUNT_SHIFT_COUNT = {}", AK::Detail::StringBase::SHORT_STRING_BYTE_COUNT_SHIFT_COUNT);
EMIT_OFFSET(UTF16_SHORT_STRING_BYTE_COUNT_AND_FLAG, AK::Detail::ShortString, byte_count_and_short_string_flag);
EMIT_OFFSET(UTF16_SHORT_STRING_STORAGE, AK::Detail::ShortString, storage);
outln("const PRIMITIVE_STRING_UTF16_SHORT_STRING_BYTE_COUNT_AND_FLAG = {}", offsetof(PrimitiveStringLayoutAccessor, m_utf16_string) + offsetof(AK::Detail::ShortString, byte_count_and_short_string_flag));
outln("const PRIMITIVE_STRING_UTF16_SHORT_STRING_STORAGE = {}", offsetof(PrimitiveStringLayoutAccessor, m_utf16_string) + offsetof(AK::Detail::ShortString, storage));
// Utf16StringData layout
outln("\n# Utf16StringData layout");
EMIT_OFFSET(UTF16_STRING_DATA_LENGTH_IN_CODE_UNITS, AK::Detail::Utf16StringData, m_length_in_code_units);
outln("const UTF16_STRING_DATA_STRING_STORAGE = {}", AK::Detail::Utf16StringData::offset_of_string_storage());
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
// Environment layout
outln("\n# Environment layout");
EMIT_OFFSET(ENVIRONMENT_SCREWED_BY_EVAL, Environment, m_permanently_screwed_by_eval);
EMIT_OFFSET(ENVIRONMENT_OUTER, Environment, m_outer_environment);
// DeclarativeEnvironment / Binding layout
outln("\n# DeclarativeEnvironment / Binding layout");
EMIT_OFFSET(DECLARATIVE_ENVIRONMENT_BINDINGS, DeclarativeEnvironment, m_bindings);
outln("const BINDING_VALUE = {}", offsetof(DeclarativeEnvironment::Binding, value));
outln("const BINDING_STRICT = {}", offsetof(DeclarativeEnvironment::Binding, strict));
outln("const BINDING_MUTABLE = {}", offsetof(DeclarativeEnvironment::Binding, mutable_));
outln("const BINDING_INITIALIZED = {}", offsetof(DeclarativeEnvironment::Binding, initialized));
outln("const SIZEOF_BINDING = {}", sizeof(DeclarativeEnvironment::Binding));
// Vector<Binding> layout: m_size(0), m_capacity(8), m_metadata.outline_buffer(16)
outln("const BINDINGS_DATA_PTR = {}", offsetof(DeclarativeEnvironment, m_bindings) + sizeof(size_t) * 2);
// EnvironmentCoordinate layout
outln("\n# EnvironmentCoordinate layout");
outln("const ENVIRONMENT_COORDINATE_HOPS = {}", offsetof(EnvironmentCoordinate, hops));
outln("const ENVIRONMENT_COORDINATE_INDEX = {}", offsetof(EnvironmentCoordinate, index));
outln("const ENVIRONMENT_COORDINATE_INVALID = 0x{:X}", EnvironmentCoordinate::invalid_marker);
// TypedArrayBase layout
outln("\n# TypedArrayBase layout");
EMIT_OFFSET(TYPED_ARRAY_ELEMENT_SIZE, TypedArrayBase, m_element_size);
EMIT_OFFSET(TYPED_ARRAY_ARRAY_LENGTH, TypedArrayBase, m_array_length);
EMIT_OFFSET(TYPED_ARRAY_BYTE_OFFSET, TypedArrayBase, m_byte_offset);
EMIT_OFFSET(TYPED_ARRAY_KIND, TypedArrayBase, m_kind);
LibJS: Cache typed array data pointers for indexed access Cache raw data pointers on fixed-length typed array views so asm GetByValue and PutByValue can use them directly for indexed element access. Replace the asm typed-array hot-path ArrayBuffer/DataBlock/ByteBuffer walk with one cached_data_ptr load. Remove six unconditional loads, four branches, and the byte_offset add before the element access, trading them for one cached_data_ptr null check. Keep direct C++ typed-array access on IsValidIntegerIndex-based checks, invalidate cached pointers eagerly when a backing ArrayBuffer is detached, and add regression coverage for shrink, regrow, and detach on number and BigInt typed arrays.
2026-03-18 09:27:37 -05:00
EMIT_OFFSET(TYPED_ARRAY_CACHED_DATA_PTR, TypedArrayBase, m_data);
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
// ByteLength (Variant<Auto, Detached, u32>) layout
outln("\n# ByteLength layout");
{
// For Variant<Auto, Detached, u32>: u32 index 2 means it holds a u32
outln("const BYTE_LENGTH_U32_INDEX = 2");
EMIT_SIZEOF(BYTE_LENGTH_SIZE, ByteLength);
// Composite: array_length value (u32) and index byte within TypedArrayBase
auto ta_al = offsetof(TypedArrayBase, m_array_length);
// Variant<Auto, Detached, u32> stores m_data[4] then m_index (u8)
outln("const TYPED_ARRAY_ARRAY_LENGTH_VALUE = {}", ta_al); // u32 data at start
outln("const TYPED_ARRAY_ARRAY_LENGTH_INDEX = {}", ta_al + 4); // index byte after 4 bytes of data
}
// TypedArrayBase::Kind enum values
outln("\n# TypedArrayBase::Kind values");
outln("const TYPED_ARRAY_KIND_UINT8 = {}", static_cast<u8>(TypedArrayBase::Kind::Uint8Array));
outln("const TYPED_ARRAY_KIND_UINT8_CLAMPED = {}", static_cast<u8>(TypedArrayBase::Kind::Uint8ClampedArray));
outln("const TYPED_ARRAY_KIND_UINT16 = {}", static_cast<u8>(TypedArrayBase::Kind::Uint16Array));
outln("const TYPED_ARRAY_KIND_UINT32 = {}", static_cast<u8>(TypedArrayBase::Kind::Uint32Array));
outln("const TYPED_ARRAY_KIND_INT8 = {}", static_cast<u8>(TypedArrayBase::Kind::Int8Array));
outln("const TYPED_ARRAY_KIND_INT16 = {}", static_cast<u8>(TypedArrayBase::Kind::Int16Array));
outln("const TYPED_ARRAY_KIND_INT32 = {}", static_cast<u8>(TypedArrayBase::Kind::Int32Array));
outln("const TYPED_ARRAY_KIND_FLOAT32 = {}", static_cast<u8>(TypedArrayBase::Kind::Float32Array));
outln("const TYPED_ARRAY_KIND_FLOAT64 = {}", static_cast<u8>(TypedArrayBase::Kind::Float64Array));
// Value tags
outln("\n# Value tags");
outln("const OBJECT_TAG = 0x{:X}", static_cast<u64>(OBJECT_TAG));
outln("const STRING_TAG = 0x{:X}", static_cast<u64>(STRING_TAG));
outln("const SYMBOL_TAG = 0x{:X}", static_cast<u64>(SYMBOL_TAG));
outln("const BIGINT_TAG = 0x{:X}", static_cast<u64>(BIGINT_TAG));
outln("const ACCESSOR_TAG = 0x{:X}", static_cast<u64>(ACCESSOR_TAG));
outln("const INT32_TAG = 0x{:X}", static_cast<u64>(INT32_TAG));
outln("const BOOLEAN_TAG = 0x{:X}", static_cast<u64>(BOOLEAN_TAG));
outln("const UNDEFINED_TAG = 0x{:X}", static_cast<u64>(UNDEFINED_TAG));
outln("const NULL_TAG = 0x{:X}", static_cast<u64>(NULL_TAG));
// Shifted value constants
outln("\n# Shifted value constants");
LibJS: Expose asmint Call offset metadata Emit the ExecutionContext, function-object, executable, and realm offsets that the asm Call path needs to inspect and initialize directly when building inline frames.
2026-04-13 20:55:12 +02:00
outln("const OBJECT_TAG_SHIFTED = 0x{:X}", static_cast<u64>(OBJECT_TAG << GC::TAG_SHIFT));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
outln("const EMPTY_VALUE = 0x{:X}", static_cast<u64>(EMPTY_TAG << GC::TAG_SHIFT));
outln("const INT32_TAG_SHIFTED = 0x{:X}", static_cast<u64>(INT32_TAG << GC::TAG_SHIFT));
outln("const BOOLEAN_TRUE = 0x{:X}", static_cast<u64>((BOOLEAN_TAG << GC::TAG_SHIFT) | 1));
outln("const BOOLEAN_FALSE = 0x{:X}", static_cast<u64>(BOOLEAN_TAG << GC::TAG_SHIFT));
outln("const UNDEFINED_SHIFTED = 0x{:X}", static_cast<u64>(UNDEFINED_TAG << GC::TAG_SHIFT));
outln("const EMPTY_TAG_SHIFTED = 0x{:X}", static_cast<u64>(EMPTY_TAG << GC::TAG_SHIFT));
AsmInt: Use tag extraction for double checks instead of 64-bit mask Replace the check_is_double pattern that loaded the full 64-bit CANON_NAN_BITS constant (10-byte movabs on x86_64) and masked the entire value, with a cheaper approach: extract the upper 16-bit tag and check if (tag & NAN_BASE_TAG) == NAN_BASE_TAG. This saves instructions at every double-check site. Additionally, add a check_tag_is_double macro for call sites where the tag has already been extracted into a register, avoiding redundant extract_tag operations. This is used in 11 call sites across coerce_to_doubles, strict_equality_core, numeric_compare, Div, UnaryPlus, UnaryMinus, and ToInt32.
2026-03-07 12:55:11 +01:00
outln("const NAN_BASE_TAG = 0x{:X}", static_cast<u64>(GC::BASE_TAG));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
outln("const CANON_NAN_BITS = 0x{:X}", static_cast<u64>(GC::CANON_NAN_BITS));
outln("const DOUBLE_ONE = 0x{:X}", bit_cast<u64>(1.0));
outln("const NEGATIVE_ZERO = 0x{:X}", static_cast<u64>(NEGATIVE_ZERO_BITS));
outln("const CELL_TAG_SHIFTED = 0x{:X}", static_cast<u64>(GC::SHIFTED_IS_CELL_PATTERN));
LibJS: Pair-store the asm Call frame setup Teach the asm Call fast path to use paired stores for the fixed ExecutionContext header writes and for the caller linkage fields. This also initializes the five reserved Value slots directly instead of looping over them as part of the general register clear path. That keeps the hot frame setup work closer to the actual data layout: reserved registers are seeded with a couple of fixed stores, while the remaining register and local slots are cleared in wider chunks. On x86_64, keep the new explicit-offset formatting on store_pair* and load_pair* without changing ordinary [base, index, scale] operands into base-plus-index-plus-offset addresses. Add unit tests covering both the paired zero-offset form and the preserved scaled-index lowering.
2026-04-14 02:51:56 +02:00
outln("const ACCUMULATOR_REG_OFFSET = {}", static_cast<size_t>(Register::accumulator().index()) * sizeof(Value));
outln("const EXCEPTION_REG_OFFSET = {}", static_cast<size_t>(Register::exception().index()) * sizeof(Value));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
outln("const THIS_VALUE_REG_OFFSET = {}", static_cast<size_t>(Register::this_value().index()) * sizeof(Value));
LibJS: Pair-store the asm Call frame setup Teach the asm Call fast path to use paired stores for the fixed ExecutionContext header writes and for the caller linkage fields. This also initializes the five reserved Value slots directly instead of looping over them as part of the general register clear path. That keeps the hot frame setup work closer to the actual data layout: reserved registers are seeded with a couple of fixed stores, while the remaining register and local slots are cleared in wider chunks. On x86_64, keep the new explicit-offset formatting on store_pair* and load_pair* without changing ordinary [base, index, scale] operands into base-plus-index-plus-offset addresses. Add unit tests covering both the paired zero-offset form and the preserved scaled-index lowering.
2026-04-14 02:51:56 +02:00
outln("const RETURN_VALUE_REG_OFFSET = {}", static_cast<size_t>(Register::return_value().index()) * sizeof(Value));
outln("const SAVED_LEXICAL_ENVIRONMENT_REG_OFFSET = {}", static_cast<size_t>(Register::saved_lexical_environment().index()) * sizeof(Value));
outln("const RESERVED_REGISTERS_SIZE = {}", static_cast<size_t>(Register::reserved_register_count) * sizeof(Value));
LibJS: Add AsmInterpreter, a low-level assembly bytecode interpreter Add a new interpreter that executes bytecode via generated assembly, written in a custom DSL (asmint.asm) that AsmIntGen compiles to native x86_64 or aarch64 code. The interpreter keeps the bytecode program counter and register file pointer in machine registers for fast access, dispatching opcodes through a jump table. Hot paths (arithmetic, comparisons, property access on simple objects) are handled entirely in assembly, with cold/complex operations calling into C++ helper functions defined in AsmInterpreter.cpp. A small build-time tool (gen_asm_offsets) uses offsetof() to emit struct field offsets as constants consumed by the DSL, ensuring the assembly stays in sync with C++ struct layouts. The interpreter is enabled by default on platforms that support it. The C++ interpreter can be selected via LIBJS_USE_CPP_INTERPRETER=1. Currently supported platforms: - Linux/x86_64 - Linux/aarch64 - macOS/x86_64 - macOS/aarch64
2026-03-06 22:07:49 +01:00
return 0;
}
Reference in a new issue Copy permalink