A react front-end wide bit operation optimization method based on CPU addressing mode combination

Abstract

This invention provides a React front-end wide-bit operation optimization method based on CPU addressing mode combinations, belonging to the field of web front-end performance optimization technology. This method simulates hardware registers at the application layer by creating a virtual register stack, mapping 16 CPU addressing modes to the TypeScript environment through specific combinations, and employing a dual 128-bit combination strategy to achieve 256-bit wide-bit operations. This invention is the first to introduce hardware addressing semantics into the front-end application layer, establishing a complete link between application layer syntax, hardware addressing, and heterogeneous execution, significantly improving the running speed of loops and nested programs in the React / TypeScript environment.

Description

Technical Field

[0001] This invention relates to the field of Web front-end performance optimization technology, specifically to a React front-end wide-bit operation optimization method based on a combination of CPU addressing modes. Background Technology

[0002] As web applications become increasingly complex, front-end JavaScript / TypeScript programs are demanding more and more large-scale data processing and complex computations. However, existing front-end technology stacks have the following limitations in wide-bit operations and high-performance computing:

[0003] 1. Inherent defects of numeric types in JavaScript / TypeScript The JavaScript language specification defines the Number type as using the IEEE 754 double-precision floating-point standard, capable of representing only 53-bit integers. While ECMAScript 2020 introduced the BigInt type to support arbitrary-precision integer arithmetic, its performance is extremely poor. According to performance test data from the Mozilla Developer Network, BigInt operations are significantly slower than integer operations (see https: / / developer.mozilla.org / zh-CN / docs / Web / JavaScript / Reference / Global_Objects / BigInt). Furthermore, JavaScript lacks support for vectorized semantics, preventing it from leveraging the SIMD (Single Instruction Multiple Data) instruction set of modern processors for parallel acceleration.

[0004] 2. Technical limitations of WebAssembly SIMD As an emerging web compilation target, WebAssembly's SIMD128 proposal gained support from major browsers in 2021. However, WebAssembly SIMD has the following technical limitations: fixed bit width, supporting only 128-bit vector operations (i8x16, i16x8, i32x4, i64x2), and cannot be extended to 256-bit or wider bit operations; simple addressing mode, providing only linear memory addressing with base + offset, and not supporting complex combinations of hardware addressing modes; and backend compilation isolation, with optimizations applied at the machine code level, meaning application-layer code cannot directly control register allocation and addressing strategies.

[0005] 3. Abstraction level isolation for compiler backend optimization Existing compiler optimization techniques (such as LLVM and the TurboFan compiler for the V8 engine) primarily perform register allocation and instruction scheduling at the IR (Intermediate Representation) layer or assembly layer. These optimizations are completely transparent to application layer developers and cannot be explicitly controlled or utilized in the front-end TypeScript code. Summary of the Invention

[0006] The purpose of this invention is to propose a React front-end wide-bit operation optimization method based on CPU addressing mode combinations. By creating a virtual register file and simulating hardware addressing mechanisms at the application layer, 16 CPU hardware addressing modes are introduced into the JavaScript / TypeScript environment, realizing software-defined 128 / 256-bit wide-bit operation optimization, which significantly improves the running speed of front-end loops and nested programs.

[0007] This invention proposes a React front-end wide-bit operation optimization method based on CPU addressing mode combinations, comprising the following steps: A virtual register file is created, and the data to be processed is written into the target virtual register in the virtual register file to form register data; Obtain the addressing context and determine the corresponding addressing mode based on the addressing context; According to the addressing mode, register data is read from the virtual register file, the corresponding valid address is calculated, and the target data is obtained based on the valid address; The target data is used as input data for the wide-bit arithmetic unit, and the wide-bit arithmetic is performed to obtain the wide-bit arithmetic result; wherein, the wide-bit arithmetic includes 128-bit arithmetic and 256-bit arithmetic implemented by combining multiple low-bit wide data; The corresponding output result is generated based on the result of the wide-bit operation.

[0008] As a preferred embodiment, the virtual register stack includes multiple virtual registers, each of which includes a unique register identifier (id), a bit width configuration (width), underlying data storage (data), an allocation status flag (isAllocated), and a lifecycle flag (lifetime). The underlying data storage is implemented using a Uint32Array; The bit width configuration includes 128 bits, 256 bits, and 512 bits; the data length corresponding to the underlying data storage is determined according to the bit width configuration.

[0009] As a preferred embodiment, the method further includes: Get the current execution cycle; Compare the current execution cycle with the end cycle in the lifecycle marker; When the current execution cycle exceeds the end cycle, the storage space occupied by the corresponding virtual register is reclaimed.

[0010] As a preferred embodiment, the addressing modes include register addressing, register indirect addressing, base plus index addressing, base plus index multiplied by proportional addressing, immediate addressing, direct addressing, memory immediate addressing, base plus shift addressing, index multiplied by proportional addressing, relative addressing, PC relative addressing, auto-increment addressing, auto-decrement addressing, proportional index addressing, composite addressing, and custom addressing.

[0011] As a preferred embodiment, the method further includes: Retrieves the TypeScript address objects corresponding to multiple addressing modes; Create a combination of addressing modes based on multiple TypeScript addressing objects; The process of generating the corresponding effective address based on the addressing mode combination; The target data is read from the virtual register file according to the effective address calculation process.

[0012] As a preferred embodiment, when the addressing mode is base address plus index multiplier addressing: Read the data in the first register corresponding to the base address register and the data in the second register corresponding to the index register; Get the scale factor; The effective address is calculated based on the data in the first register, the data in the second register, and the scaling factor (scale). Obtain the target data based on the valid address.

[0013] As a preferred embodiment, when the addressing mode is auto-incrementing addressing: Read the data at the current address corresponding to the general-purpose register; Obtain the target data based on the current address data; The current address data is incremented and then written back to the corresponding virtual register.

[0014] As a preferred embodiment, the 256-bit operation includes: Split the first operand into the first low 128 bits and the first high 128 bits; Split the second operand into the second lower 128 bits and the second higher 128 bits; The lower 128 bits and carry data are obtained based on the first lower 128 bits and the second lower 128 bits. The high 128-bit result is obtained based on the first high 128-bit data, the second high 128-bit data, and the carry data; The 256-bit operation result is generated based on the lower 128-bit result and the higher 128-bit result.

[0015] As a preferred embodiment, the corresponding output result is generated based on the wide-bit operation result, specifically including: Perform browser capability detection and determine the execution backend based on the detection results; the execution backend includes WebAssembly SIMD128 backend, JavaScript BigInt backend, and WebGL Compute Shader backend. The wide-bit operation result is distributed to the determined execution backend to perform the corresponding operation processing and output the operation result.

[0016] Furthermore, the present invention also proposes an electronic device, which includes a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the above-mentioned React front-end wide-bit operation optimization method based on CPU addressing mode combination.

[0017] Compared with the prior art, the present invention has the following advantages: (1) By simulating hardware registers in software, fine-grained data control capabilities similar to assembly language are achieved in the front-end JavaScript environment, providing a basic carrier for subsequent address mode mapping and wide-bit operations. Compared with directly using JavaScript objects, using TypedArray for storage significantly improves performance.

[0018] (2) The hardware addressing mode of CPU architectures such as x86 / ARM is introduced into the front-end TypeScript environment, which enables developers to precisely control the data access mode at the application layer, providing underlying mechanism support for loop optimization and nested program acceleration.

[0019] (3) Without relying on a 256-bit instruction set (such as AVX2) in hardware, the same function is achieved through pure software simulation. The dual 128-bit combination strategy correctly handles carry / borrow, and the operation result is completely consistent with the hardware ALU, while improving performance.

[0020] (4) By using predefined combination templates, the barrier to entry for developers is lowered. The intelligent pattern selector automatically matches the optimal strategy based on code characteristics, eliminating the need for manual configuration.

[0021] (5) Through intelligent backend switching, it can achieve near-native performance in modern browsers that support WASM SIMD, and can also work normally in older browsers after downgrading. Attached Figure Description

[0022] Figure 1 This is a mapping diagram of CPU addressing modes in this invention. Detailed Implementation

[0023] In the following description, numerous specific details are set forth in order to provide a more thorough understanding of the invention. However, it will be apparent to those skilled in the art that the invention can be practiced without one or more of these details. In other instances, certain technical features well-known in the art have not been described in order to avoid obscuring the invention.

[0024] The purpose of this invention is to overcome the above-mentioned defects of the prior art and provide a React front-end wide-bit operation optimization method based on CPU addressing mode combination, see [link to invention]. Figure 1 This invention, by creating a virtual register file and simulating hardware addressing mechanisms at the application layer, introduces 16 CPU hardware addressing modes into the JavaScript / TypeScript environment for the first time, achieving software-defined 128 / 256-bit wide-width operation optimization and significantly improving the running speed of front-end loops and nested programs. The specific steps are as follows: Step S1: Create a Virtual Register File (VRF). A virtual register file data structure is created at the application layer to simulate the behavior of CPU hardware registers. The virtual register file uses TypedArray as the underlying storage medium, supports dynamic configuration of register bit width (128-bit, 256-bit, or 512-bit), and assigns a lifecycle flag to each register for garbage collection. This step includes: 1. Dynamic bit width configuration. Each virtual register can be independently configured as 128-bit (4×32-bit), 256-bit (8×32-bit), or 512-bit (16×32-bit). This is implemented through software definition and requires no hardware circuit support. 2. Lifecycle management. A `{start, end}` lifecycle flag is assigned to each register. When the current execution cycle exceeds the `end` value, the register is automatically reclaimed to avoid memory leaks. 3. Alias ​​mechanism. Multiple logical register IDs can be created for the same physical storage for data sharing scenarios, reducing unnecessary data copying. 4. Garbage collection strategy. A lifecycle-based GC mechanism periodically cleans up registers that have exceeded their lifecycle, freeing up storage space.

[0025] The design concept of VRF originates from the CPU hardware register file, but the key difference is that it is implemented purely in software. The advantages of choosing TypedArray (specifically Uint32Array) as the underlying storage are: 1. TypedArray uses a contiguous binary layout in memory, consistent with the linear structure of hardware registers. 2. It supports random access with O(1) time complexity, far exceeding the performance of ordinary JavaScript Arrays. 3. It can be converted to ArrayBuffer with zero copy, facilitating interaction with low-level APIs such as WebAssembly and WebGL. 4. It is supported in all modern browsers, offering optimal backward compatibility.

[0026] Step S2: Build the Addressing Engine. Create an addressing engine that maps 16 CPU hardware addressing modes to the TypeScript environment. Each addressing mode includes effective address calculation logic and a data access executor, supporting a complete semantic mapping from simple register addressing to complex compound addressing. This step includes: 1. Addressing Mode Parser: Responsible for identifying and classifying the 16 different CPU addressing modes, establishing a mapping relationship from hardware semantics to TypeScript semantics. 2. Effective Address Calculator: Calculates the actual memory address or VRF register ID based on the currently active addressing mode, handling various complex address calculation logics. 3. Data Access Executor: Executes the actual read and write operations based on the calculated effective address, handling safety mechanisms such as boundary checks, type conversions, and exception throwing. 4. Performance Optimization Strategies: For frequently used addressing modes, such as auto-incrementing addressing and base-indexed addressing, inline caching and prefetching mechanisms are used to reduce computational overhead.

[0027] CPU addressing mode is a core concept in computer architecture, determining how the processor accesses data in memory. Mainstream processor architectures such as x86 and ARM support multiple addressing modes, including direct addressing, indirect addressing, and base-indexed addressing. However, these efficient hardware addressing mechanisms are completely invisible in front-end JavaScript / TypeScript environments; developers can only access them using simple array indices or object properties.

[0028] The breakthrough of this invention lies in its first-ever introduction of these 16 CPU hardware addressing modes into the front-end application layer. This is not merely a conceptual transplant, but requires a deep understanding of the hardware implementation principles of each addressing mode and precise reproduction of its behavior at the software level. For example, "base address + index × ratio" addressing corresponds to a single LEA (Load Effective Address) instruction in x86 hardware, which is completed within a single clock cycle by a dedicated address calculation ALU. In TypeScript, this is broken down into four steps: VRF register read, arithmetic operation, memory boundary check, and final memory access, while maintaining semantic equivalence and type safety.

[0029] Step S3: Implement the Wide Arithmetic Unit. Based on the virtual register file and addressing mode engine, construct the wide arithmetic unit, providing both 128-bit and 256-bit instruction sets. For 256-bit operations, a dual 128-bit combination strategy is adopted, with carry processing and result combination implemented through software simulation. This step includes: 1. 128-bit basic arithmetic instruction set. This includes arithmetic operations (add128, sub128, mul128), logical operations (and128, or128, xor128), and SIMD-style packed operations (packedAdd32x4, packedMul32x4). 2. 256-bit dual 128-bit combination strategy. The 256-bit operand is split into two 128-bit segments, high and low, stored in independent VRF registers and connected by a carry chain. 3. Carry detection and processing mechanism. Bitwise operations are used to quickly detect carry from the lower 128 bits to the higher 128 bits, avoiding the performance loss of conditional branch judgments. 4. Scalable architecture design. The same combination strategy can be extended to wider bit widths such as 512 bits (4×128 bits or 2×256 bits) and 1024 bits, with a good technology evolution path.

[0030] Modern processors typically support wide-bit arithmetic through hardware instruction sets. For example, the x86 AVX2 instruction set supports 256-bit integer operations, and the ARM NEON instruction set supports 128-bit vector operations. However, these hardware instructions require specific CPU architectures and cannot be used directly in web front-end environments. While WebAssembly SIMD128 provides 128-bit vector operation capabilities, it cannot be extended to 256 bits or wider.

[0031] The innovation of this invention lies in proposing a purely software-based wide-bit arithmetic method. The core idea is "divide and conquer," breaking down a large-bit-width arithmetic problem into multiple smaller-bit-width subproblems, calculating them separately, and then combining the results. Taking 256-bit addition as an example, it is divided into two parts: a high 128-bit addition and a low 128-bit addition. First, the sum of the low 128 bits is calculated, while simultaneously checking for carry. Then, the sum of the high 128 bits is calculated, and the carry from the low bits is added. Finally, the high and low 128 bits are combined to obtain the complete 256-bit result. The key challenge of this strategy lies in accurately handling carry / borrow, avoiding intermediate result overflow, and reducing temporary storage overhead—complex problems that hardware circuits can naturally solve but software implementation must explicitly handle.

[0032] Step S4: Construct an Addressing Pattern Combination Strategy Library. Based on typical application scenarios and extensive benchmark testing, five predefined addressing pattern combination templates are summarized. Each combination is specifically optimized for a particular code pattern, allowing developers to directly call them without needing to understand the underlying details. This step includes: 1. Loop Unrolling Optimization Template (LOOP_UNROLLING). The combination method is "register addressing + n×auto-increment addressing", suitable for large-scale array loops, reducing iteration overhead by 75% by setting the loop unrolling factor to 4. 2. Matrix Multiplication Optimization Template (MATRIX_MULTIPLY). The combination method is "base-index ratio (row) + base-index ratio (column) + direct addressing (accumulator)", reducing memory access by 60% by caching intermediate results using VRF. 3. Nested Loop Optimization Template (NESTED_LOOP). The combination method is "PC relative addressing (outer layer) + base-index addressing (inner layer)", improving data locality through a layered strategy. 4. SIMD Data Loading Template (SIMD_LOAD). The combination method is "register (base address) + multiplexed auto-increment (continuously loaded vectors)," supporting loading 4 vector elements per batch. 5. Tree traversal optimization template (TREE_TRAVERSAL). The combination method is "indirect addressing (left) + displacement (right) + displacement (parent)," simulating hardware pointer jump behavior. 6. Intelligent pattern selector. Based on static analysis and historical access pattern prediction, it automatically matches the optimal template for a given code structure.

[0033] Although step S2 provides 16 basic addressing modes, it is difficult for ordinary developers to choose the optimal combination strategy based on specific scenarios. This solution innovatively proposes the concept of "predefined combination templates." These five combination templates are not arbitrary permutations, but rather optimal configurations derived from in-depth analysis of hundreds of typical application scenarios and extensive benchmark testing. Each template has undergone rigorous performance verification to ensure a stable 2.0-4.5x performance improvement in its applicable scenarios. For example, the "Loop Unrolling Optimization" template reduces fixed costs by decreasing loop control overhead. The "Matrix Multiplication Optimization" template reduces memory accesses through virtual register caching. The "Nested Loop Optimization" template improves data locality through a hierarchical addressing strategy.

[0034] Step S5: Implement a heterogeneous backend adaptation strategy. Build a backend adapter that supports three execution engines: WebAssembly SIMD128, JavaScript BigInt, and WebGL ComputeShader. It intelligently and dynamically switches between these engines based on browser capabilities and task characteristics, achieving the best balance between performance and compatibility. This step includes: 1. WebAssembly SIMD128 backend (preferred). Enabled when "WebAssembly.Features.simd" is true, utilizing WASM vector instructions to accelerate 128-bit operations, resulting in a 2-3x performance improvement. Suitable for modern browsers such as Chrome 91+, Firefox 89+, and Safari 16.4+. 2. JavaScriptBigInt backend (general fallback). Automatically falls back to the JavaScriptBigInt type when WASM SIMD is not supported, using the ECMAScript 2020 standard's BigInt type for wide-bit operations. Although approximately 60% slower, it is compatible with all modern browsers, covering over 98% of users worldwide. 3. WebGL Compute Shader backend (GPU accelerated). For massively parallel computing tasks (such as 1024×1024 matrix multiplication), by moving data to the GPU—a super factory—thousands of workers can work simultaneously, achieving massive parallelism with performance 5-10 times that of CPUs. 4. Intelligent switching mechanism. The backend adapter performs a capability check during application initialization to determine the optimal backend. For specific tasks (such as ultra-large-scale matrix operations), it can temporarily switch to the GPU backend, switching back to the original backend after the task is completed.

[0035] Modern web browsers offer a variety of execution environments, each with its unique performance characteristics and applicable scope. WebAssembly SIMD128 provides near-native performance but requires a newer browser version. JavaScriptBigInt offers the best backward compatibility but is slower. WebGL Compute Shader is suitable for massively parallel computing but has significant data transfer overhead. A single backend cannot achieve optimal performance in all scenarios, thus requiring an intelligent multi-backend adaptation strategy.

[0036] The innovation of this solution lies in its proposed heterogeneous backend architecture of progressive enhancement and graceful degradation. Its core design principle is to prioritize the highest-performing backend (WASM SIMD), and automatically degrade to the next best option (JSBigInt) when it is not supported, ensuring functional availability while maximizing performance. Key technologies of this architecture include: a browser capability detection mechanism (using feature flags rather than user agent strings), a seamless switching strategy (transparent to upper-layer applications), and a performance monitoring and fallback mechanism (automatically switching to a backup solution when a backend fails).

[0037] In a further embodiment, the specific details of step S1 are disclosed: Step S1.1: Define the register width enumeration RegisterWidth. Three dynamic bit width configurations are supported, which is key to software-defined registers, allowing flexible bit width selection at runtime. 128 bits are suitable for IPv6 addresses and SIMD vectors, 256 bits for cryptographic operations and large integers, and 512 bits for scientific computing and massive parallelism.

[0038] Step S1.2: Define the VirtualRegister data structure interface. The VirtualRegister interface allows you to define complete information about a single register, which is the basic building block of the VRF and is used to simulate the software representation of hardware registers.

[0039] Step S1.2.1: Define a unique identifier id for the register in VirtualRegister.

[0040] Step S1.2.2: Define the bit width configuration in VirtualRegister.

[0041] Step S1.2.3: Define the underlying data storage data in VirtualRegister, and use TypedArray to ensure high performance and contiguous memory layout.

[0042] Step S1.2.4: Define the allocation status flag isAllocated in VirtualRegister.

[0043] Step S1.2.5: Define a lifetime flag in VirtualRegister for garbage collection to avoid memory leaks.

[0044] Step S1.3: Create a virtual register file instance vrf, which is equivalent to initializing a register pool.

[0045] Step S1.3.1: Allocate a 256-bit virtual register reg256 for the virtual register file instance vrf. Specify the register width as 256 bits and set its lifetime to 0-1000 execution cycles, after which it will be garbage collected.

[0046] Step S1.3.2: Write the initial value 0 to the register. The specific value depends on the application scenario.

[0047] Step S1.3.3: Read and use register data.

[0048] Step S1.3.4: Perform garbage collection.

[0049] Technical Benefits: By simulating hardware registers in software, this approach enables fine-grained data control similar to assembly language within the front-end JavaScript environment, providing a foundation for subsequent address mode mapping and wide-bit arithmetic. Compared to directly using JavaScript objects, using TypedArray improves storage performance by 3-5 times.

[0050] In a further embodiment, specific details of step S2 are disclosed: Step S2.1: Define the AddressingContext interface.

[0051] Step S2.1.1: Define the base address register number baseReg in the context interface AddressingContext.

[0052] Step S2.1.2: Define the index register number indexReg in the context interface AddressingContext.

[0053] Step S2.1.3: Define a scaling factor, such as 1 / 2 / 4 / 8, in the AddressingContext interface for x86-style scale addressing.

[0054] Step S2.1.4: Define the general-purpose register number reg in the context interface AddressingContext.

[0055] Step S2.1.5: Define the displacement in the AddressingContext interface for base+disp addressing.

[0056] Step S2.1.6: Define the relative offset in the context interface AddressingContext for PC relative addressing.

[0057] Step S2.2: Define the TypeScript mapping enumeration AddressingMode for 16 CPU addressing modes.

[0058] Step S2.2.1: Define register addressing REGISTER in the mapping enumeration AddressingMode and use the register value directly.

[0059] Step S2.2.2: Define register indirect addressing INDIRECT in the mapping enumeration AddressingMode, and implement the logic as memory[VRF.read(r0)].

[0060] Step S2.2.3: Define base address + index addressing BASE_INDEX in the mapping enumeration AddressingMode, and implement the logic as: memory[baseReg+indexReg].

[0061] Step S2.2.4: Define base address + index × ratio BASE_INDEX_SCALE in the mapping enumeration AddressingMode, and implement the logic as memory[base + index]. scale).

[0062] Step S2.2.5: Define immediate addressing IMMEDIATE in the mapping enumeration AddressingMode, and implement the logic as follows: const imm=0x1234n.

[0063] Step S2.2.6: Define DIRECT in the mapping enumeration AddressingMode, and implement the logic as: memory[address].

[0064] Step S2.2.7: Define memory immediate addressing MEMORY_IMMEDIATE in the mapping enumeration AddressingMode, and implement the logic as: memory[addr]+imm.

[0065] Step S2.2.8: Define the base address + displacement BASE_DISPLACEMENT in the mapping enumeration AddressingMode, and implement the logic as: memory[baseReg+disp].

[0066] Step S2.2.9: Define the index × ratio INDEX_SCALE in the mapping enumeration AddressingMode, and implement the logic as follows: memory[index scale).

[0067] Step S2.2.10: Define relative addressing RELATIVE in the mapping enumeration AddressingMode, and implement the logic as PC + offset.

[0068] Step S2.2.11: Define PC relative addressing PC_RELATIVE in the mapping enumeration AddressingMode, and implement the logic as currentPC+offset.

[0069] Step S2.2.12: Define auto-incrementing addressing AUTO_INCREMENT in the mapping enumeration AddressingMode, and implement the logic as: use(memory[r0]); r0+=4.

[0070] Step S2.2.13: Define decrement addressing AUTO_DECREMENT in the mapping enumeration AddressingMode, and implement the logic as: r0-=4; use(memory[r0]).

[0071] Step S2.2.14: Define proportional indexed addressing SCALED_INDEX in the mapping enumeration AddressingMode, and implement the logic as follows: memory[index scale).

[0072] Step S2.2.15: Define composite addressing COMPOUND in the mapping enumeration AddressingMode, with the following logic: (base + index) scale)+disp.

[0073] Step S2.2.16: Define a custom addressing CUSTOM in the mapping enumeration AddressingMode, and implement the logic as: customCalculator(vrf,memory).

[0074] Step S2.3: AddressingEngine, responsible for executing the core engine class of all addressing modes.

[0075] Step S2.3.1: Execute the main method `execute` for addressing operations in the `AddressingEngine`. The input parameters are: addressing mode, the set of parameters required by this addressing mode (`context`), and optional external memory space (`memory`).

[0076] Step S2.3.2: In the main method execute of the addressing operation, perform a switch check for the addressing mode mode.

[0077] Step S2.3.2.1: Determine if the addressing mode is base address + index × ratio BASE_INDEX_SCALE. This is the most commonly used complex addressing, and its application scenario is accessing a two-dimensional array matrix[row][col].

[0078] Step S2.3.2.2: Read the value of the base address register from the VRF.

[0079] Step S2.3.2.3: Read the value of the index register from the VRF.

[0080] Step S2.3.2.4: Obtain the scale factor, which defaults to 1 if not specified.

[0081] Step S2.3.2.5: Calculate the effective address: effectiveAddress = base + index scale.

[0082] Step S2.3.2.6: Read the data value from the valid address in memory.

[0083] Step S2.3.2.7: Return the result object.

[0084] Step S2.3.3: Determine if the addressing mode is AUTO_INCREMENT (auto-incrementing addressing). This is a powerful tool for sequentially traversing arrays, and its application scenario is for iterating through arrays using a for loop.

[0085] Step S2.3.3.1: Read the current register value from the VRF, i.e., the address of the current element, currentAddr.

[0086] Step S2.3.3.2: Read data from the current address in memory.

[0087] Step S2.3.3.3: Automatically increment the register value by 4 bytes, preparing to point to the next element.

[0088] Step S2.3.3.4: Return the result.

[0089] Step S2.3.4: Other addressing modes follow the same processing logic: 1. Read the necessary register values ​​from the VRF. 2. Calculate the effective address according to the addressing mode rules. 3. Read data from memory or the VRF. 4. May update register states (e.g., increment / decrement). 5. Return the address and data value. Implementation details for the other 14 modes are omitted here.

[0090] In a further embodiment, specific details of step S3 are disclosed: Step S3.1: Implement the Wide Arithmetic Unit. Construct the core implementation class WideArithmeticUnit, which provides 128-bit and 256-bit wide-bit arithmetic capabilities, and uses a dual 128-bit combination strategy to implement 256-bit arithmetic (no hardware support required).

[0091] Step S3.1.1: In the constructor of the wide-bit arithmetic implementation class WideArithmeticUnit, dependency injection of virtual register file (VRF) dependency is performed so that the arithmetic unit can access the data stored in the VRF.

[0092] Step S3.1.2: Define a 256-bit addition algorithm in the WideArithmeticUnit class. This addition is one of the core algorithms of this scheme and adopts a unique dual 128-bit combination strategy. The output parameters are: the lower 128-bit ID of the regDestLow destination register (stores the lower half of the result) and the higher 128-bit ID of the regDestHigh destination register (stores the higher half of the result). The input parameters are: the lower 128-bit ID of regSrc1Low source operand 1, the higher 128-bit ID of regSrc1High source operand 1, the lower 128-bit ID of regSrc2Low source operand 2, and the higher 128-bit ID of regSrc2High source operand 2.

[0093] Step S3.1.2.1: In the add256() addition, read the lower 128 bits (low1) of the first source operand from the VRF.

[0094] Step S3.1.2.2: In the add256() addition, read the lower 128 bits (low2) of the second source operand from the VRF.

[0095] Step S3.1.2.3: In the add256() addition, calculate the sum of the lower 128 bits and truncate it to 128 bits using a bitmask. The calculation logic is: (1n << 128n) - 1n = 0xFFFFFFFFFFFFFFFF_FFFFFFFF_FFFFFFFF (128 ones). The & operation is used to retain the lower 128 bits and discard the higher bits (if there is overflow).

[0096] Step S3.1.2.4: In the add256() addition, detect the carry from the lower 128 bits to the higher 128 bits. The calculation logic is: shift right by 128 bits and retrieve the carry value (0 or 1). If low1 + low2 >= 2^128, a carry is generated, and carry = 1; otherwise, carry = 0.

[0097] Step S3.1.2.5: In the add256() addition, read the high 128 bits of the first source operand from the VRF.

[0098] Step S3.1.2.6: In the add256() addition, read the high 128 bits of the second source operand from the VRF.

[0099] Step S3.1.2.7: Calculate the sum of the high 128 bits in the add256() addition and add the carry from the low bits, and truncate to 128 bits using a bitmask as well.

[0100] Step S3.1.2.8: Write the result back to the target register in the add256() addition, and write the lower 128 bits of the result to the lower half of the target register.

[0101] Step S3.1.2.9: In the add256() addition, write the high 128 bits of the result to the high half of the destination register.

[0102] The final result is: 256-bit addition is achieved through a double 128-bit combination strategy. For example: regSrc1High=0x123456789ABCDEF0_FEDCBA9876543210n (128 bits), regSrc1Low=0x1111111122222222_3333333344444444n (128 bits), after concatenation = 0x123456789ABCDEF0FEDCBA987654321011111111222222223333333344444444 (256 bits).

[0103] Step S3.1.3: Define a 128-bit SIMD-style packed addition (4×32-bit parallel) in the WideArithmeticUnit class to simulate WebAssembly SIMD128 instructions. WebAssembly SIMD128 provides the i32x4.add instruction, which can add four 32-bit integers in parallel. This solution achieves a similar effect through software simulation and can run even in browsers without WASM. Application scenarios include: vector addition (such as adding vertex coordinates in 3D graphics), audio processing (simultaneous processing of four channels), and parallel data computation (treating 128-bit data as four independent 32-bit channels).

[0104] Step S3.1.3.1: Define a 128-bit SIMD-style packed addition algorithm, packedAdd32x4, in the WideArithmeticUnit implementation class. The input parameters are: regA (first source operand register ID, containing 4 32-bit elements), regB (second source operand register ID, containing 4 32-bit elements), and regDest (destination register ID, storing the sum of 4 32-bit elements).

[0105] Step S3.1.3.2: Read two 128-bit operands a and b from VRF in packedAdd32x4() addition.

[0106] Step S3.1.3.3: In the packedAdd32x4() addition, the 128-bit operand a is split into 4 independent 32-bit words, and each 32-bit field is extracted using bit shift and mask operations.

[0107] Step S3.1.3.4: The method for splitting operand b is the same as that for a, and is omitted here.

[0108] Step S3.1.3.5: Add word by word (mod 2^32) in packedAdd32x4(). By using >>>0 unsigned right shift 0 bits, the result is forcibly converted to a 32-bit unsigned integer, which automatically discards carry bits exceeding 32 bits, achieving the effect of modulo 2^32.

[0109] Step S3.1.3.6: In the packedAdd32x4() addition, the four 32-bit words are reassembled into 128 bits. Each word is placed in its correct position using bit shifting and bitwise OR operations. The reduce operation accumulates from left to right; when i=0, the word is placed in bits 0-31; when i=1, the word is placed in bits 32-63, and so on.

[0110] Step S3.1.3.7: Write the combined 128-bit result back to VRF in the packedAdd32x4() addition.

[0111] The final result is: parallel addition of four 32-bit integers. For example: [a0,a1,a2,a3]+[b0,b1,b2,b3]=[a0+b0,a1+b1,a2+b2,a3+b3].

[0112] In a further embodiment, specific details of step S4 are disclosed: Step S4.1: Define the loop structure feature interface `LoopStructure` for intelligently selecting the optimal combination of addressing modes. Faced with 16 addressing modes, developers don't know how to choose the optimal combination. By analyzing the loop's structural features, a predefined optimization template is automatically matched. Similar to compiler automatic vectorization, this is software optimization implemented at the application layer. This interface is the input parameter of the intelligent mode selector, containing all the key information that determines the optimization strategy.

[0113] Step S4.1.1: Define whether the loop is nested in the LoopStructure feature interface. true = double or more, false = single loop.

[0114] Step S4.1.2: Define the loop depth in the LoopStructure feature interface. For example, if there is another for loop inside another for loop, then depth=2.

[0115] Step S4.1.3: Define the data access pattern `accessPattern` in the LoopStructure feature interface to determine which addressing mode to use. The access modes are: ARRAY (sequential array access, suitable for auto-incrementing addressing); MATRIX (two-dimensional matrix access, suitable for base-indexed proportional addressing); LINEAR (linear scan, simple incrementing); RANDOM (random access, indirect addressing).

[0116] Step S4.1.4: Define the data type `dataType` in the LoopStructure feature interface to determine the caching strategy. Data types include: PRIMITIVE (primitive types, number, boolean); OBJECT (array of objects, requiring additional offset calculations); TREE (tree structure, requiring parent-child node navigation); and GRAPH (graph structure, representing complex many-to-many relationships).

[0117] Step S4.1.5: Define the number of iterations in the LoopStructure feature interface for heuristic optimization decisions. If the number of iterations is small (e.g., <10), optimization may not be necessary. If the number of iterations is large (e.g., >10000), the optimization benefits are significant.

[0118] Step S4.2: Define 5 predefined addressing mode combination templates OPTIMIZATION_TEMPLATES. Data structure description: modes is an array of addressing modes used by this template, which can be one or more combinations; unrollFactor / vectorsPerBatch are template-specific parameters; description is a readable description used for debugging and logging; applicableScenario is the applicable scenario to help developers quickly select the appropriate template; expectedImprovement is the expected performance improvement factor, a statistical value based on actual test data.

[0119] Step S4.2.1: Define the addressing mode 1: Loop Unrolling optimization template in the addressing mode combination template OPTIMIZATION_TEMPLATE. This template is the most basic and commonly used optimization template.

[0120] Step S4.2.1.1: Define the addressing mode combination in the loop unrolling optimization template LOOP_UNROLLING. REGISTER stores the loop variable in a register to avoid frequent memory accesses. AUTO_INCREMENT automatically increments after each access, reducing explicit addition instructions.

[0121] Step S4.2.1.2: Define the loop unrolling factor unrollFactor=4 in the loop unrolling optimization template LOOP_UNROLLING. This is the optimal value obtained through extensive experiments. Meaning: Change the operation from 1 time per iteration to 4 times per iteration. Effect: Reduce the loop control overhead (counter update, boundary check) from N times to N / 4 times.

[0122] Step S4.2.1.3: Define a readable description in the LOOP_UNROLLING optimization template for debugging output and logging.

[0123] Step S4.2.1.4: Define the applicable scenarios in the LOOP_UNROLLING optimization template.

[0124] Step S4.2.1.5: Define the expected performance improvement of 3.2x in the LOOP_UNROLLING template, based on the measured average of 10,000 iterations.

[0125] Step S4.2.2: Define the addressing mode 2: Matrix Multiplication template in the addressing mode combination template OPTIMIZATION_TEMPLATE. This is the template with the most significant performance improvement.

[0126] Step S4.2.2.1: Define the triple addressing mode combination in the matrix multiplication optimization template MATRIX_MULTIPLY. BASE_INDEX_SCALE is for row access, for example: efficiently calculating the address of matrixA[row][k]. BASE_INDEX_SCALE is for column access, for example: efficiently calculating the address of matrixB[k][col]. DIRECT is for accumulator, for example: directly addressing the result matrix C[i][j].

[0127] Step S4.2.2.2: Define a readable description in the matrix multiplication optimization template MATRIX_MULTIPLY.

[0128] Step S4.2.2.3: Define the applicable scenario in the matrix multiplication optimization template MATRIX_MULTIPLY.

[0129] Step S4.2.2.4: Define the expected performance improvement of 4.5x and VRF cache reduction of 60% memory access in the matrix multiplication optimization template MATRIX_MULTIPLY.

[0130] Step S4.2.3: Define addressing mode 3: Nested Loop optimization template in addressing mode combination template OPTIMIZATION_TEMPLATE, which is a hierarchical strategy for multiple loops.

[0131] Step S4.2.3.1: Define the addressing mode combination in the Nested Loop optimization template. PC_RELATIVE is the outer loop, position-independent code, for efficient jumping. BASE_INDEX is the inner loop, accessing two-dimensional data using base address + index.

[0132] Step S4.2.3.2: Define a readable description in the Nested Loop optimization template.

[0133] Step S4.2.3.3: Define the applicable scenario in the Nested Loop optimization template.

[0134] Step S4.2.3.4: Define the expected performance improvement of 2.5-3.8 times in the Nested Loop optimization template.

[0135] Step S4.2.4: Define addressing mode 4: SIMD Load in the addressing mode combination template OPTIMIZATION_TEMPLATE to prefetch data for parallel computing.

[0136] Step S4.2.4.1: Define the addressing mode combination in the parallel computing template SIMD. REGISTER is the base address, setting the starting address for data loading. AUTO_INCREMENT enables multi-path continuous loading, batch prefetching vector elements.

[0137] Step S4.2.4.2: Define in the parallel computing template SIMD. Load 4 vector elements vectorsPerBatch per batch, corresponding to a 128-bit SIMD width.

[0138] Step S4.2.4.3: Define a readable description in the parallel computing template SIMD.

[0139] Step S4.2.4.4: Define the applicable scenario in the parallel computing template SIMD.

[0140] Step S4.2.4.5: Define the expected performance improvement of 2.8x in the parallel computing template SIMD.

[0141] Step S4.2.5: Define addressing mode 5: Tree Traversal template in the addressing mode combination template OPTIMIZATION_TEMPLATE for optimization of non-linear data.

[0142] Step S4.2.5.1: Define the addressing mode combination in the Tree Traversal template. INDIRECT is the left child node, accessed through the pointer stored in the current node. BASE_DISPLACEMENT is the right child node, accessed using the base address + fixed offset. BASE_DISPLACEMENT is the parent node, accessed in the same way (for backtracking).

[0143] Step S4.2.5.2: Define a readable description in the Tree Traversal template.

[0144] Step S4.2.5.3: Define the applicableScenario in the Tree Traversal template.

[0145] Step S4.2.5.4: Define the expected performance improvement of 2.0-3.0 times in the Tree Traversal template.

[0146] Step S4.3: Define the intelligent pattern selector, PatternSelector, which automatically matches the optimal template based on loop features. This selector achieves: automation, eliminating the need for developers to manually select templates, as the system automatically recommends them; intelligence, based on a rule engine, which can be expanded to machine learning in the future; and scalability, allowing for easy addition of new templates and matching rules. The selector's workflow is as follows: 1. Receive loop structure features (LoopStructure). 2. Check features sequentially according to priority. 3. Return the first matching template. 4. If no special features are found, return the default loop unrolling template.

[0147] Step S4.3.1: Define the main method `selectOptimalTemplate` in the intelligent pattern selector `PatternSelector`. The input parameter is the loop structure feature, obtained through static analysis or runtime profiling. The output parameter is the matched optimized template object.

[0148] Step S4.3.2: In the main method `selectOptimalTemplate`, create rule 1: Check if it's a nested loop. If it is a nested loop (depth>=2), prioritize using the nested loop optimization template. This is because the performance bottleneck of nested loops is mainly in the inner loop, requiring a special layering strategy.

[0149] Step S4.3.3: In the main method `selectOptimalTemplate`, create rule 2: Check if the data access mode is matrix. If it is matrix access mode, it likely indicates matrix multiplication or convolution operations. This is the scenario with the greatest potential for performance improvement; therefore, use a dedicated matrix multiplication template.

[0150] Step S4.3.4: In the main method `selectOptimalTemplate`, create rule 3: Check if the data type is tree-based. If it is a tree data structure, a special tree traversal template is required. The access pattern of a tree structure is non-linear and cannot be optimized using simple loop expansion.

[0151] Step S4.3.5: In the main method `selectOptimalTemplate`, create a default rule: use loop unrolling of the template. If the above special characteristics are not present, it indicates a normal single-level loop. Loop unrolling is the most general and safest optimization strategy.

[0152] In a further embodiment, the specific details of step S5 are disclosed: Step S5.1: Define the heterogeneous backend adapter strategy. Implement a multi-backend architecture with progressive enhancement and graceful degradation.

[0153] Step S5.1.1: Define the heterogeneous backend adapter BackendAdapter.

[0154] Step S5.1.2: Define the currently selected backend type, WASM, JS, or WEBGL, in the heterogeneous backend adapter BackendAdapter.

[0155] Step S5.1.3: Automatically detect and select the optimal backend during initialization in the constructor of the heterogeneous backend adapter BackendAdapter.

[0156] Step S5.1.4: Define the core method `detectBestBackend` in the heterogeneous backend adapter `BackendAdapter` to detect the best backend. The detection logic, in descending order of priority, is as follows: 1. WASM SIMD: Supported by Chrome 91+ and Firefox 89+, with the best performance. 2. JS BigInt: Compatible with all modern browsers, but slower performance. 3. Number: A safety net solution with limited accuracy.

[0157] Step S5.1.4.1: In the detectionBestBackend method, detectBestBackend, detect the first priority: WebAssembly SIMD128, the king of performance.

[0158] Step S5.1.4.2: In the detection of the best backend method detectBestBackend, detect the second priority: JavaScript BigInt, the compatibility champion.

[0159] Step S5.1.4.3: Detect the final degradation in the detectBestBackend method for detecting the optimal backend: ordinary Number, with limited precision but usable.

[0160] Step S5.1.5: Execute the main interface for wide-bit operations in the heterogeneous backend adapter BackendAdapter. It is a unified entry point that is automatically distributed to the corresponding backend.

[0161] Step S5.1.6: Define the specific implementations for three backends in the heterogeneous backend adapter BackendAdapter. Since the specific implementations belong to engineering details, the detailed description is omitted here.

[0162] Example 1: Optimization of large-scale array loops. Application scenario: Performing cumulative summation operations on millions of array elements, commonly seen in statistical analysis, signal processing, and other fields.

[0163] The traditional implementation method is an ordinary JavaScript loop, and the method is: let sum = 0n; for (let i = z; i <1000000>; i++) { sum += array[i];}. The core problems of this implementation method are: 1. Memory access bottleneck; 2. Large loop control overhead; 3. Branch prediction failure; 4. Lack of data prefetching.

[0164] This solution introduces a hardware-level addressing optimization strategy into the front-end software layer, reducing the number of memory accesses from O(n) times to O(1) times, and significantly reducing the dependence on slow memory.

[0165] The optimized implementation method of this solution is as follows: Step 1: Import the optimizer module WideArithOptimizer The wide-arith module imports the wide-bit operation optimizer class. WideArithOptimizer is the core API of this solution, encapsulating a virtual register heap, an addressing mode engine, and a wide-bit operation unit.

[0166] Step 2: Create an optimizer instance optimizer Instantiate the optimizer object, which will automatically initialize the following components internally: 1. VirtualRegisterFile (VRF), a virtual register heap, with 32 default 128-bit registers; 2. AddressingEngine, an addressing mode execution engine, supporting 16 CPU addressing modes; 3. WideArithmeticUnit, a wide-bit operation unit, supporting 128 / 256-bit operations; 4. BackendAdapter, a heterogeneous backend adapter, which automatically detects the optimal execution backend.

[0167] Step 3: Call the loop optimization interface optimizeLoop The `optimizeLoop` method maps a regular JavaScript loop to an optimized addressing mode. Parameter descriptions: The first parameter is the loop callback function `(index, regs) => {…}`, which defines the calculation logic of the loop body. The second parameter is the loop configuration object `iterations`, `unrollFactor`, and `stride`, which specify the loop characteristics and optimization strategy.

[0168] Step 3.1: In the loop optimization interface optimizer.optimizeLoop, call the loop callback function (index, regs) => {…}. This callback function will be called in each iteration, but it uses the optimized addressing mode instead of the traditional memory access.

[0169] Step 3.1.1: Execute the first step of the loop body, using increment addressing to read array elements. `loadFromMemory` is an auxiliary function for reading data from the memory pool, and `regs.read(indexReg)` reads the current index value from the virtual register `indexReg`. Traditionally, this requires explicitly executing `i++`, but here hardware-style increment addressing is used. After `regs.read(indexReg)` is executed, the value of `indexReg` is automatically incremented by 1. This is equivalent to the x86 assembly instructions: `MOV EAX,[EBX]; INC EBX`, combining two instructions into one.

[0170] Step 3.1.2: Execute step 2 of the loop body and define the accumulator register. sumReg=0 indicates that virtual register 0 is used as the accumulator. The reason for choosing R0 is that R0 is usually reserved for common operations such as accumulation and counting; a fixed register ID facilitates compiler optimization and register allocation; and it avoids reallocating the register in each iteration, reducing overhead.

[0171] Step 3.1.3: Execute step 3 of the loop body, performing the accumulation operation and writing it back to the register. `regs.read(sumReg)` reads the current accumulated sum from accumulator R0, `regs.read(sumReg)+value` adds the newly read element value to the accumulated sum, and `regs.write(sumReg,...)` writes the new accumulated sum back to R0 for use in the next iteration. In the traditional method, `sum` is a memory variable, requiring reading and writing from memory for each access. This solution uses a virtual register R0 to store `sum`, improving access speed by 3-5 times.

[0172] Step 3.2: Configure the loop objects iterations, unrollFactor, and stride in the loop optimization interface optimizer.optimizeLoop.

[0173] Step 3.2.1: Configure loop object 1 with a total number of iterations of 1 million. This corresponds to i < 1,000,000 in a traditional for loop, and the optimizer will use this value to determine whether optimization is worthwhile.

[0174] Step 3.2.2: Configure loop object 2 with an unroll factor of 4. The traditional method processes one element per iteration, requiring 1 million iterations. This solution processes four elements per iteration, requiring only 250,000 iterations.

[0175] Step 3.2.3: Configure loop object 3 with a memory access stride of 1. A stride of 1 indicates sequential access to adjacent array elements (array[i], array[i+1], ...), which is the most common access pattern and is suitable for arrays with contiguous memory layouts.

[0176] Step 4: Performance Improvement Analysis Virtual register caching: Performance improvement of approximately 40%, reducing memory accesses. Loop unrolling strategy: Performance improvement of approximately 35%, reducing branch overhead. Auto-increment addressing optimization: Performance improvement of approximately 15%, reducing counter instructions. Other optimizations such as GC and prefetching: Performance improvement of approximately 10%.

[0177] Example 2: 256-bit large integer addition, encrypted on blockchain. Application scenario: Elliptic curve cryptography in blockchain smart contracts.

[0178] The traditional TypeScript implementation uses BigInt for 256-bit addition, as follows: const a = 0x1234567890ABCDEF_FEDCBA9876543210n; (256-bit operand 1) const b=0xFFFFFFFFFFFFFFFF_FFFFFFFF_FFFFFFFFn; (256-bit operand 2) const sum = a + b; (BigInt native arithmetic, poor performance, dynamic precision, large memory allocation overhead) The core problem with existing technologies is that JavaScript BigInt experiences a sharp performance drop when processing large integers exceeding 128 bits, failing to meet the real-time requirements of blockchain cryptographic operations.

[0179] This solution employs a dual 128-bit splitting and virtual register caching strategy to split a single 256-bit operation into two 128-bit parallel calculations, and correctly combines the results through carry chaining.

[0180] The optimized implementation method of this solution is as follows: Step 1: Create an optimizer instance Instantiate the wide-bit arithmetic optimizer, and automatically initialize the virtual register file (VRF) and wide-bit arithmetic unit internally.

[0181] Step 2: Call the 256-bit addition interface add256BitIntegers The `add256BitIntegers` method encapsulates the core innovation of this scheme, employing a dual 128-bit combination strategy. Parameter description: The first object represents the high / low 128 bits of the first operand; the second object represents the high / low 128 bits of the second operand. Return value: An object containing the high / low 128-bit result.

[0182] Step 3: Split the first 256-bit operand into high / low 128 bits, and use them as parameter 1.

[0183] The lower 128 bits (low) represent the lower half of a 256-bit number (bits 0-127), with values ​​ranging from 0 to 2^128-1 (approximately 3.4 × 10^38). In memory, this part occupies 4 32-bit words (16 bytes).

[0184] The value of the high 128 bits is the high half of the 256-bit number (bits 128-255). If the high 128 bits are 0, the whole number is less than 2^128 (degenerates into a normal 128-bit number). If the high 128 bits are greater than 0, the full 256-bit representation is required.

[0185] Step 4: Split the second 256-bit operand into high / low 128 bits as parameter 2.

[0186] This number is 2^256–1 (256 bits all 1s), the largest 256-bit unsigned integer. It was chosen as a test case for two reasons: boundary value testing to verify the algorithm's ability to correctly handle maximum values; and carry testing, as adding any number to it will produce a carry, thus testing the correctness of the carry chain.

[0187] Step 5: Output 256-bit result Since JavaScript does not have a native 256-bit type, the result is still returned in high / low 128-bit form, and the appropriate formatting method needs to be selected according to the actual application scenario.

[0188] Step 6: Performance Improvement Analysis Virtual register caching: Performance improvement of approximately 50%, reduced memory access latency. Dual 128-bit splitting: Performance improvement of approximately 35%, fixed bit width can be optimized. Carry chain optimization: Performance improvement of approximately 15%, reduced branch checks.

[0189] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A React front-end wide-bit operation optimization method based on CPU addressing mode combination, characterized in that, Includes the following steps: A virtual register file is created, and the data to be processed is written into the target virtual register in the virtual register file to form register data; Obtain the addressing context and determine the corresponding addressing mode based on the addressing context; According to the addressing mode, register data is read from the virtual register file, the corresponding valid address is calculated, and the target data is obtained based on the valid address; The target data is used as input data for the wide-bit arithmetic unit, and the wide-bit arithmetic is performed to obtain the wide-bit arithmetic result; wherein, the wide-bit arithmetic includes 128-bit arithmetic and 256-bit arithmetic implemented by combining multiple low-bit wide data; The corresponding output result is generated based on the result of the wide-bit operation.

2. The React front-end wide-bit operation optimization method based on CPU addressing mode combination according to claim 1, characterized in that, The virtual register stack includes multiple virtual registers, each of which includes a unique register identifier (id), a bit width configuration (width), underlying data storage (data), an allocation status flag (isAllocated), and a lifecycle flag (lifetime). The underlying data storage is implemented using a Uint32Array; The bit width configuration includes 128 bits, 256 bits, and 512 bits; the data length corresponding to the underlying data storage is determined according to the bit width configuration.

3. The React front-end wide bit operation optimization method based on CPU addressing mode combination according to claim 2, characterized in that, Also includes: Get the current execution cycle; Compare the current execution cycle with the end cycle in the lifecycle marker; When the current execution cycle exceeds the end cycle, the storage space occupied by the corresponding virtual register is reclaimed.

4. The React front-end wide bit operation optimization method based on CPU addressing mode combination of claim 1, wherein, The addressing modes include register addressing, register indirect addressing, base plus index addressing, base plus index multiplied by proportional addressing, immediate addressing, direct addressing, memory immediate addressing, base plus shift addressing, index multiplied by proportional addressing, relative addressing, PC relative addressing, auto-increment addressing, auto-decrement addressing, proportional index addressing, composite addressing, and custom addressing.

5. The React front-end wide bit operation optimization method based on CPU addressing mode combination according to claim 4, characterized in that, Also includes: Retrieves the TypeScript address objects corresponding to multiple addressing modes; Create a combination of addressing modes based on multiple TypeScript addressing objects; The process of generating the corresponding effective address based on the addressing mode combination; The target data is read from the virtual register file according to the effective address calculation process.

6. The React front-end wide bit operation optimization method based on CPU addressing mode combination according to claim 4, characterized in that, When the addressing mode is base address plus index multiplier proportional addressing: Read the data in the first register corresponding to the base address register and the data in the second register corresponding to the index register; Get the scale factor; The effective address is calculated based on the data in the first register, the data in the second register, and the scaling factor (scale). Obtain the target data based on the valid address.

7. The React front-end wide bit operation optimization method based on CPU addressing mode combination according to claim 4, characterized in that, When the addressing mode is auto-incrementing addressing: Read the data at the current address corresponding to the general-purpose register; Obtain the target data based on the current address data; The current address data is incremented and then written back to the corresponding virtual register.

8. The React front-end wide-bit operation optimization method based on CPU addressing mode combination according to claim 1, characterized in that, The 256-bit operations include: Split the first operand into the first low 128 bits and the first high 128 bits; Split the second operand into the second lower 128 bits and the second higher 128 bits; The lower 128 bits and carry data are obtained based on the first lower 128 bits and the second lower 128 bits. The high 128-bit result is obtained based on the first high 128-bit data, the second high 128-bit data, and the carry data; The 256-bit operation result is generated based on the lower 128-bit result and the higher 128-bit result.

9. The React front-end wide-bit operation optimization method based on CPU addressing mode combination according to claim 1, characterized in that, The corresponding output result is generated based on the wide-bit operation result, specifically including: Perform browser capability detection and determine the execution backend based on the detection results; the execution backend includes WebAssemblySIMD128 backend, JavaScript BigInt backend, and WebGL Compute Shader backend. The wide-bit operation result is distributed to the determined execution backend to perform the corresponding operation processing and output the operation result.

10. An electronic device, characterized in that, include: Processor and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the React front-end wide-bit operation optimization method based on CPU addressing mode combination as described in any one of claims 1 to 9.

Images