Cross-platform hardware register access method and system

Abstract

The application discloses a cross-platform hardware register access method and system, relates to the technical field of computer systems, and discloses a cross-platform hardware register access method and system, which receives user input access request data, performs analysis processing, conflict prediction calculation, platform adaptation conversion, instruction execution, state verification repair and other operations, realizes an efficient cross-platform register access mechanism, has the ability of realizing cross-platform compatibility, effectively managing concurrent access conflicts and automatically detecting and repairing state abnormalities, and thus improves system reliability and development efficiency.

Description

Technical Field

[0001] This application relates to the field of computer system technology, and in particular to cross-platform hardware register access methods and systems. Background Technology

[0002] Hardware registers serve as the core channel for interaction between the CPU and peripheral devices in a computer system, and their direct access is indispensable in hardware development, system debugging, and performance tuning. While existing tools, such as the devmem program on the Linux platform, can perform basic register read / write operations, they are limited by differences in operating system kernel interfaces and cannot run in heterogeneous environments such as Windows and macOS. This forces developers to repeatedly develop dedicated tools for different platforms, increasing maintenance costs. A more significant problem is that current technology only supports isolated, single-access operations and lacks a collaborative management mechanism for multi-threaded concurrent scenarios. When multiple processes or threads simultaneously request the same hardware register, the lack of dynamic conflict prediction and scheduling capabilities easily leads to timing conflicts, causing register state anomalies, data overwriting, or system-level failures. Such problems are particularly prevalent in high-concurrency scenarios such as embedded system integration testing, chip functional verification, and complex device driver development. This not only prolongs the debugging cycle but can also lead to hardware malfunctions due to inconsistent states, seriously threatening system reliability and development progress. Furthermore, existing solutions lack a state change pattern analysis module, failing to automatically detect and repair abnormal states after access, further amplifying system risks due to the cumulative effect of errors.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a cross-platform hardware register access method and system, which aims to improve system reliability and development efficiency.

[0005] To achieve the above objectives, this application proposes a cross-platform hardware register access method, the method comprising: Receive user-input access request data and obtain the original access request data; The original access request data is parsed to obtain parsed access feature data. Based on the parsed access feature data and the current access task status, conflict prediction calculation is performed to obtain conflict avoidance scheduling data. Based on the conflict avoidance scheduling data, the parsed access feature data is subjected to platform adaptation conversion processing, and platform-specific hardware operation instruction data is obtained based on the dynamically detected operating system platform features. Execute the platform-specific hardware operation instructions to obtain the initial access result data; The initial access result data is subjected to state consistency verification processing, and state repair processing is performed based on the register state change pattern to obtain the final access result data after verification and repair. The final access result data after verification and repair is returned to the user.

[0006] In one embodiment, the step of parsing the original access request data to obtain parsed access feature data, and then performing conflict prediction calculations based on the parsed access feature data and the current access task status to obtain conflict avoidance scheduling data includes: The original access request data is parsed to extract target register address feature data, access timing feature data, and access priority feature data to obtain the parsed access feature data. Obtain the current access task status, which includes the set of access tasks currently being executed, the execution progress of the access tasks, and the estimated completion time; Based on the target register address feature data and access timing feature data, matching access pattern data is retrieved from the historical access record database to obtain access pattern matching result data. Based on the current access task status and the access pattern matching result data, the conflict probability prediction calculation is performed using the target register address feature data and access timing feature data to obtain conflict probability prediction data. Based on the conflict probability prediction data and the access priority feature data, scheduling planning is performed to obtain the conflict avoidance scheduling data.

[0007] In one embodiment, the step of performing conflict probability prediction calculation based on the current access task state and the access pattern matching result data, using the target register address feature data and access timing feature data, to obtain conflict probability prediction data includes: Analyze the execution progress of the access task in the current access task status, and calculate the predicted remaining execution time of the access task; Historical conflict occurrence pattern data is extracted from the access pattern matching result data. The historical conflict occurrence pattern data includes conflict type distribution data, conflict time distribution data, and conflict resolution strategy data. Using a pre-trained conflict prediction model, based on the remaining execution time prediction data of the access task, the historical conflict occurrence pattern data extracted from the access pattern matching result data, the target register address feature data, and the access timing feature data, the probability value of access conflict is calculated to obtain the conflict probability prediction data.

[0008] In one embodiment, the method further includes: Historical conflict occurrence records are obtained from the historical access record database. Based on the historical conflict occurrence records, conflict time distribution training data is extracted to establish time-dimensional conflict probability distribution function data. Based on the historical conflict occurrence record data, conflict type distribution training data is extracted to establish conflict correlation matrix data for different types of access operations; Training data on the remaining execution time of historical access tasks are obtained from the historical access record database. The time-dimensional conflict probability distribution function data and the conflict correlation matrix data are fused and calculated to obtain dynamic conflict probability prediction function data. Based on the dynamic conflict probability prediction function data and the preset model training dataset, the pre-trained conflict prediction model is trained and generated.

[0009] In one embodiment, the step of performing platform adaptation conversion processing on the parsed access feature data based on the conflict avoidance scheduling data, and obtaining platform-specific hardware operation instruction data based on dynamically detected operating system platform features, includes: Based on the access timing arrangement data in the conflict avoidance scheduling data, determine the access instruction execution time window data; Dynamically detect the operating system platform characteristics of the current operating environment, including system call interface characteristics, memory management characteristics, and hardware access mechanism characteristics; Based on the characteristics of the operating system platform, an adaptation strategy is selected, which includes instruction conversion rules, permission management rules, and error handling rules. Within the access instruction execution time window, the parsed access feature data is converted in real time according to the adaptation strategy to obtain platform-specific hardware operation instruction data.

[0010] In one embodiment, the steps of performing state consistency verification processing on the initial access result data, and performing state repair processing based on the register state change pattern to obtain the verified and repaired final access result data include: The initial access result data is obtained, and the access operation execution status feature data and access result value feature data are analyzed. The register state change pattern of the target register is obtained from the register state monitoring module. The register state change pattern includes normal state change pattern, abnormal state change pattern and state recovery pattern. The access result value feature data is matched and analyzed with the register state change pattern to obtain state anomaly feature data. Based on the aforementioned abnormal state feature data and the preset set of state repair strategies, state repair operation instruction data is generated. Execute the state repair operation instruction data to repair the abnormal state and obtain the repaired access result data; Based on the access operation execution status feature data, the consistency of the status of the repaired access result data is verified to obtain the final access result data after verification and repair.

[0011] In one embodiment, the step of generating state repair operation instruction data based on the state anomaly feature data and a preset set of state repair strategies includes: Analyze the abnormal status feature data to obtain abnormality type data and abnormality severity data; Based on the anomaly type data, a matching repair strategy template data is retrieved from the preset state repair strategy set. The repair strategy template data includes repair operation sequence data, repair operation parameter data, and repair verification rule data. Based on the anomaly type data and anomaly severity data, the parameters of the repair strategy template data are adjusted to obtain the adjusted repair strategy data. The adjusted repair strategy data is converted into executable state repair operation instruction data.

[0012] In one embodiment, the step of adjusting the parameters of the repair strategy template data based on the anomaly type data and anomaly severity data to obtain adjusted repair strategy data includes: Based on the anomaly type data, determine the target register set data and repair operation type data for the repair operation; Based on the severity data of the anomaly, the execution priority data and time window data of the repair operation are determined; Based on the target register set data and repair operation type data, repair operation sequence data is extracted from the repair strategy template data; Based on the execution priority data and the time window data of the repair operation, the repair operation sequence data is subjected to timing adjustment processing to obtain the timing-adjusted repair operation sequence data. Based on the severity data of the anomaly, set the parameter adjustment range data and verification threshold data for the repair operation; By integrating the time-adjusted repair operation sequence data, parameter adjustment range data, and verification threshold data, the adjusted repair strategy data is obtained.

[0013] In one embodiment, before the step of executing platform-specific hardware operation instruction data to obtain initial access result data, the method further includes: Integrated security verification processing is performed on the platform-specific hardware operation instruction data to obtain security verification result data; the integrated security verification processing includes permission verification processing, conflict security verification processing, and state security verification processing; Based on the security verification result data, when the security verification is successful, the platform-specific hardware operation instruction data is executed to obtain the initial access result data; when the security verification fails, security blocking response data is generated and the final access result data after the verification is repaired is returned to the user.

[0014] Furthermore, to achieve the above objectives, this application also proposes a cross-platform hardware register access system, which includes: a memory, a processor, and a cross-platform hardware register access program stored in the memory and executable on the processor, wherein the cross-platform hardware register access program is configured to implement the steps of the cross-platform hardware register access method.

[0015] The cross-platform hardware register access method and system proposed in this application achieves an efficient cross-platform register access mechanism by receiving user-input access request data and performing operations such as parsing, conflict prediction calculation, platform adaptation conversion, instruction execution, and status verification and repair. It has the ability to achieve cross-platform compatibility, effectively manage concurrent access conflicts, and automatically detect and repair status anomalies, thereby improving system reliability and development efficiency. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating an embodiment of the cross-platform hardware register access method of this application; Figure 2 This is a schematic diagram of a cross-platform hardware register access system according to an embodiment of this application.

[0019] Explanation of icon numbers: 10. Memory; 20. Processor.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of this application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be understood that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] In existing technologies, hardware register access tools suffer from severe platform dependency, making them unusable across different operating systems. Furthermore, these tools only support simple single read / write operations, failing to effectively resolve access conflicts when multiple threads concurrently access the same hardware register. This can easily lead to inconsistent register states, data read / write errors, and even system crashes, severely impacting development efficiency and system stability.

[0024] Based on this, embodiments of this application provide a cross-platform hardware register access method, referring to... Figure 1 The cross-platform hardware register access method includes steps S100 to S600, wherein: Step S100: Receive the access request data input by the user to obtain the original access request data; Step S200: The original access request data is parsed to obtain parsed access feature data. Based on the parsed access feature data and the current access task status, conflict prediction calculation is performed to obtain conflict avoidance scheduling data. Step S300: Based on the conflict avoidance scheduling data, perform platform adaptation conversion processing on the parsed access feature data, and obtain platform-specific hardware operation instruction data based on dynamically detected operating system platform features. Step S400: Execute the platform-specific hardware operation instruction data to obtain the initial access result data; Step S500: Perform state consistency verification processing on the initial access result data, and perform state repair processing based on the register state change pattern to obtain the final access result data after verification and repair. Step S600: Return the final access result data after verification and repair to the user.

[0025] In this embodiment, the raw access request data refers to the raw instructions or parameter set submitted by the user through an application or command-line interface for accessing a specific hardware register. This data typically includes basic information such as the target register address, read / write type, and value to be written. The parsed access feature data refers to the structured and standardized access-related information extracted after preliminary processing of the raw access request data. This data may include the target register identifier, access operation type, data length, access priority, etc., facilitating subsequent conflict prediction and platform adaptation. The current access task status refers to the real-time information set of all hardware register access tasks that are currently executing or awaiting execution at a given moment. This status may include the identifier of each task, the target register, the execution progress, the estimated completion time, and dependencies with other tasks, used to assess potential access conflicts. Conflict avoidance scheduling data refers to the access task execution plan or adjustment strategy generated to avoid or mitigate conflicts after predicting potential access conflicts. This data may include access task priority adjustments, timing arrangements, resource allocation suggestions, etc., guiding subsequent platform adaptation and conversion.

[0026] In this embodiment, operating system platform characteristics refer to the attributes and interface information unique to the operating system of the current operating environment. These characteristics may include system call interfaces, memory management mechanisms, hardware access permission models, interrupt handling methods, etc., and form the basis for platform adaptation and conversion. Platform-specific hardware operation instruction data refers to the low-level instruction sequence that, after platform adaptation and conversion, can be directly recognized and executed by the current operating system and hardware. This data is generated for a specific hardware architecture and operating system API and is used for actual register read / write operations. Initial access result data refers to the raw response or return value directly obtained from the hardware register after executing the platform-specific hardware operation instruction. This data may contain success or failure flags, read register values, etc., but has not yet undergone consistency verification and repair. Register state change patterns refer to the preset patterns or rules that the values ​​or states of the target hardware registers should follow under normal operation, specific event triggering, or abnormal conditions. These patterns may include register bit field definitions, read / write attributes, linkage effects, and expected state transitions under different operations, used to verify the correctness of the access results. Verifying the final access result data involves verifying the consistency of the initial access result data and performing corresponding repairs when anomalies are detected. This results in a final, reliable access result that has been confirmed by the system and meets the expected state, and can be directly returned to the user.

[0027] In this embodiment, the cross-platform hardware register access method first receives user-input access request data to obtain raw access request data. This raw access request data can be obtained through various means, such as directly inputting register addresses and values ​​via command-line parameters, receiving user-input access information via a graphical user interface, or obtaining batch access requests by reading preset configuration files or script files. Secondly, the raw access request data is parsed to obtain parsed access feature data. Based on this parsed access feature data and the current access task status, conflict prediction calculations are performed to obtain conflict avoidance scheduling data. Specifically, the raw access request data can be parsed to extract key information such as register addresses, operation types, and data values. During the conflict prediction phase, the system can maintain a list of registers currently being accessed. When a new access request's target register already exists in this list, a potential conflict is preliminarily identified. When a conflict is predicted, the new access request can be simply placed in a first-in-first-out queue, waiting for the current task to complete before processing, thereby generating conflict avoidance scheduling data.

[0028] In this embodiment, the parsed access feature data is then adapted and converted to a platform-specific configuration based on the conflict avoidance scheduling data. This is achieved by dynamically detecting the operating system platform characteristics to obtain platform-specific hardware operation instruction data. During the platform adaptation and conversion process, the system can pre-configure multiple hardware access function libraries for different operating systems. For example, for Linux systems, access functions based on ` / dev / mem` or `mmap` can be provided; for Windows systems, access functions based on `CreateFile` and `DeviceIoControl` can be provided. The system dynamically detects the current operating system type at runtime and selects the corresponding function library, converting the general access feature data into platform-specific low-level hardware operation instructions. Subsequently, the platform-specific hardware operation instruction data is executed to obtain the initial access result data. This execution process typically involves calling low-level APIs or driver interfaces provided by the operating system. For example, in a Linux environment, `ioctl` can be called or read / write operations can be performed directly through memory pointers; in a Windows environment, the `DeviceIoControl` function can be called to send a request to the device driver. After execution, the hardware device will return the corresponding response data, which is the initial access result data.

[0029] Furthermore, the initial access result data undergoes state consistency verification. Based on the register state change patterns, state repair processing is performed to obtain the verified and repaired final access result data. During state consistency verification, the initial access result data can be compared with a preset expected value, or for write operations, a readback is performed immediately after the write operation and compared with the written value. If an inconsistency is found, state repair processing is performed. State repair may include simply retrying the access operation or resetting the register to its default state. After verification and possible repairs, the obtained data is the verified and repaired final access result data.

[0030] In this embodiment, the final access result data after verification and repair is returned to the user. This return can be done by directly outputting the result to a command-line terminal, displaying it in a graphical user interface, writing the result to a log file, or sending it to the requester over a network.

[0031] In this embodiment, the cross-platform hardware register access method effectively solves the conflict problem that may occur when multiple tasks concurrently access the same hardware register by intelligently parsing and conflict prediction scheduling of the original access request, thus avoiding inconsistencies in register states and data errors. Simultaneously, through dynamic platform adaptation and conversion, the hardware operation instructions can adapt to different operating system environments, overcoming the platform dependence of traditional tools. Furthermore, state consistency verification and repair of the access results further improve the reliability of the access and the stability of the system, making it particularly suitable for complex embedded system development, chip verification, and device driver debugging scenarios.

[0032] In one feasible implementation, the step of parsing the original access request data to obtain parsed access feature data, and performing conflict prediction calculation based on the parsed access feature data and the current access task status to obtain conflict avoidance scheduling data includes: parsing the original access request data to extract target register address feature data, access timing feature data, and access priority feature data to obtain the parsed access feature data; obtaining the current access task status, which includes the set of access tasks being executed, the access task execution progress, and the estimated completion time; retrieving matching access pattern data from a historical access record database based on the target register address feature data and the access timing feature data to obtain access pattern matching result data; performing conflict probability prediction calculation using the target register address feature data and the access timing feature data based on the current access task status and the access pattern matching result data to obtain conflict probability prediction data; and performing scheduling planning based on the conflict probability prediction data and the access priority feature data to obtain the conflict avoidance scheduling data.

[0033] In this embodiment, when parsing the original access request data, the system deeply analyzes the semantics and structure of the user request, accurately identifying and extracting target register address feature data, access timing feature data, and access priority feature data. The target register address feature data clarifies the specific hardware register the user wishes to operate on, which can be its physical address, logical name, or internal device offset. The access timing feature data captures the time dependency of the operation, such as the order of read / write operations, interval time, timeout limits, or specific clock synchronization requirements. The access priority feature data quantifies the importance of the current request, such as high priority, real-time requirements, or background tasks, which is crucial for subsequent resource contention resolution. These refined feature data collectively constitute the parsed access feature data, providing accurate foundational information for subsequent conflict prediction and scheduling.

[0034] In this embodiment, to gain a comprehensive understanding of the system's current operational status, the system acquires the current access task status. This status information includes the set of currently executing access tasks, i.e., a list of all active, incomplete hardware access requests; the access task execution progress, indicating the percentage or stage of completion for each active task; and the estimated completion time, predicted by analyzing historical data and the complexity of the current tasks to indicate when each active task will finish. This real-time status data provides dynamic contextual information for conflict prediction.

[0035] Based on this, the system retrieves matching access pattern data from the historical access record database using the target register address feature data and access timing feature data. The historical access record database stores detailed logs of all past hardware access requests, including their target register, timing, execution result, and whether conflicts occurred. By comparing the address and timing features of the current request with historical data, the system can identify access patterns similar to the current request and obtain the behavioral characteristics of these patterns during past executions, thereby obtaining access pattern matching result data.

[0036] Furthermore, the system performs conflict probability prediction calculations based on the current access task status and the access pattern matching result data, combined with the target register address feature data and access timing feature data. This calculation process comprehensively considers which tasks are currently running in the system, their progress, their expected completion time, and whether historical access patterns similar to the current request have caused conflicts. By employing a pre-trained conflict prediction model (as described in subsequent claims), the system can quantify the likelihood of a conflict occurring under the current conditions, thereby obtaining conflict probability prediction data.

[0037] In this embodiment, the system finally performs scheduling planning based on the conflict probability prediction data and the access priority feature data. If the conflict probability is high, the scheduling module will decide how to adjust based on the access priority feature data. High-priority tasks may be allowed to execute immediately even with a certain risk of conflict, while low-priority tasks may be delayed, reordered, or assigned to different time windows to avoid competition with high-priority or high-conflict-risk tasks. Through this intelligent scheduling planning, the system can generate the conflict avoidance scheduling data, which includes the best time, order, or any necessary adjustment instructions for executing the current access request.

[0038] In this embodiment, after receiving the original access request data input by the user, the system no longer simply performs parsing and conflict prediction. Instead, it first performs refined parsing of the original access request data, extracting target register address feature data, access timing feature data, and access priority feature data. This allows for a more accurate understanding of the user's access intent and potential constraints. Simultaneously, by obtaining the detailed status of the current access task and combining it with matching pattern data from historical access records, the system can comprehensively consider the real-time operating environment and past experience to make more accurate probability predictions of potential access conflicts. Based on this refined feature extraction and context-aware conflict prediction, the system can combine access priority feature data to perform intelligent scheduling planning and generate conflict-avoidance scheduling data. This effectively avoids problems such as hardware resource contention, data inconsistency, or access failures caused by blind execution or coarse scheduling, improving the success rate, efficiency, and stability of hardware register access. Especially in scenarios with multi-task concurrent access or strict timing requirements, it ensures the reliable execution of critical operations.

[0039] In one feasible implementation, the step of performing conflict probability prediction calculation based on the current access task state and the access pattern matching result data, using the target register address feature data and access timing feature data, to obtain conflict probability prediction data includes: analyzing the access task execution progress in the current access task state and calculating the remaining execution time prediction data of the access task; extracting historical conflict occurrence pattern data from the access pattern matching result data, the historical conflict occurrence pattern data including conflict type distribution data, conflict time distribution data, and conflict resolution strategy data; and using a pre-trained conflict prediction model, calculating the probability value of access conflict based on the remaining execution time prediction data of the access task, the historical conflict occurrence pattern data extracted from the access pattern matching result data, the target register address feature data, and the access timing feature data, to obtain the conflict probability prediction data.

[0040] In this embodiment, when calculating the remaining execution time prediction data for access tasks, the execution progress of the access tasks in the current access task state can be analyzed in real time or periodically. For example, the system can monitor the number of instructions completed, the CPU cycles consumed, the amount of data processed, or the specific milestones reached for each executing access task. Based on these progress indicators, combined with the historical execution data of the task or a preset task model, statistical methods (such as linear regression, exponential smoothing, Kalman filtering, etc.) or machine learning algorithms are used to predict the time required to complete the remaining part of the task, thereby obtaining the remaining execution time prediction data for the access tasks. This data provides crucial time dimension information for subsequent conflict prediction.

[0041] In this embodiment, when extracting historical conflict occurrence pattern data, the system delves into historical records similar to the current access pattern from the access pattern matching result data. These historical records not only contain past conflict events but also detail the characteristics of the conflicts. Conflict type distribution data can be statistics on the frequency or probability distribution of different conflict types (e.g., read-write conflicts, write-write conflicts, deadlocks, livelocks, resource contention, etc.) in historical events. Conflict time distribution data describes the patterns of conflict occurrence during the task execution lifecycle (e.g., how long after task start, a specific stage) or within a specific time period. Conflict resolution strategy data records effective resolution measures taken for different conflict types or scenarios, such as retry mechanisms, delayed execution, task priority adjustment, and resource release order. This pattern data provides valuable empirical knowledge for the conflict prediction model.

[0042] In this embodiment, a pre-trained conflict prediction model is used to calculate the probability value of access conflicts. This model is an intelligent algorithm trained on a large amount of historical data, capable of identifying complex patterns and correlations leading to conflicts. During prediction, the model receives multiple input features: first, the predicted remaining execution time of the access task obtained above, which reflects the dynamic time characteristics of the task; second, historical conflict occurrence pattern data extracted from the access pattern matching result data, which provides lessons learned from past conflicts; and third, target register address feature data and access timing feature data parsed from the original access request data, which describe the static attributes of this access. The pre-trained conflict prediction model comprehensively analyzes these multi-dimensional features and, through its internally learned complex functional relationships, outputs a probability value between 0 and 1, i.e., the probability value of access conflict, thereby obtaining the conflict probability prediction data.

[0043] In this embodiment, through the above technical solution, this application can more precisely analyze the dynamic execution progress of the current access task, thereby obtaining more accurate prediction data of the remaining execution time of the access task. This enables the system to more accurately determine the potential overlap in time between different tasks. Simultaneously, by extracting conflict type distribution data, conflict time distribution data, and conflict resolution strategy data from historical access patterns, the system can learn and identify deep-seated patterns and rules leading to conflicts, thereby avoiding the recurrence of known conflict scenarios. Based on this, by utilizing a pre-trained conflict prediction model, which comprehensively considers dynamic task progress information, rich historical conflict experience, and static access feature data, a more accurate and reliable access conflict probability value can be calculated. This multi-dimensional and intelligent prediction mechanism improves the accuracy and robustness of conflict prediction, providing a solid data foundation for subsequent conflict avoidance scheduling, thereby effectively reducing the risk of conflicts during cross-platform hardware register access and improving system stability and execution efficiency.

[0044] In one feasible implementation, the method further includes: obtaining historical conflict occurrence record data from a historical access record database; extracting conflict time distribution training data based on the historical conflict occurrence record data to establish time-dimensional conflict probability distribution function data; extracting conflict type distribution training data based on the historical conflict occurrence record data to establish conflict correlation matrix data for different types of access operations; obtaining historical access task remaining execution time training data from the historical access record database; fusing the time-dimensional conflict probability distribution function data with the conflict correlation matrix data to obtain dynamic conflict probability prediction function data; and training and generating the pre-trained conflict prediction model based on the dynamic conflict probability prediction function data and a preset model training dataset.

[0045] In this embodiment, to accurately capture the temporal distribution pattern of conflicts, the system retrieves detailed records of all occurring hardware register access conflicts from the historical access record database. These records typically include the timestamp of the conflict, the registers involved, and the access type. Based on this historical conflict occurrence record data, the time sequence of conflict occurrences can be extracted, and then the frequency and pattern of conflict occurrences in different time periods (e.g., different times of day, different dates of week) can be statistically analyzed. By statistically modeling these time series data, such as using kernel density estimation, Poisson process models, or time series analysis methods, a time-dimensional conflict probability distribution function can be established. This function can quantify the probability of a conflict occurring at a specific time point or within a time window, providing prior information in the time dimension for subsequent conflict prediction.

[0046] In this embodiment, hardware register access operations may include various types such as read, write, and modify. Different types of operations may have different probabilities and degrees of impact when executed concurrently. Therefore, the system identifies and extracts conflict events involving different access operation types from historical conflict occurrence records, forming conflict type distribution training data. For example, the frequency of various conflicts such as "read-write," "write-write," and "read-write" can be statistically analyzed. Based on this, a conflict correlation matrix can be established, where the rows and columns represent different access operation types, and the elements in the matrix represent the probability or correlation strength of conflict between the corresponding two operation types during concurrency. For example, matrix elements can be normalized frequency values ​​or correlation weights learned through a machine learning model. This matrix can reveal the inherent conflict patterns between different access operation types, providing a basis for more refined conflict prediction.

[0047] In this embodiment, to enable the conflict prediction model to consider the dynamics of task execution, the system retrieves training data on the remaining execution time of historical access tasks from a historical access record database. This data records the estimated completion time remaining at different execution stages for each past access task, as well as the actual completion time. By collecting a large amount of such data, the model can be trained to understand the potential relationship between task execution time and conflict occurrence. For example, long-running tasks are more likely to compete for resources with other tasks, or access to certain critical registers may be more frequent near the end of a task, thus increasing the risk of conflict. This data is a key input for training the model to predict the impact of task execution time on conflict probability.

[0048] In this embodiment, to construct a comprehensive and dynamic conflict prediction capability, it is necessary to integrate conflict patterns over time with conflict correlations between operation types. The fusion calculation can employ various methods. For example, the time-dimensional conflict probability distribution function data can be used as the base probability, and then the base probability can be corrected or weighted using conflict correlation matrix data based on the type of the current access task. Specifically, a fusion algorithm can be designed that, given the current time point and the combination of access operation types to be predicted, comprehensively considers historical time distribution and operation type correlations to output a more accurate dynamic conflict probability prediction function. This function can provide the probability of conflict occurrence in real time based on the current context (time, operation type).

[0049] In this embodiment, after obtaining the dynamic conflict probability prediction function data and other pre-set model training datasets (e.g., containing target register address feature data, access timing feature data, remaining execution time of access tasks, etc.), a pre-trained conflict prediction model can be generated. This model can be a machine learning model, such as a Support Vector Machine (SVM), decision tree, random forest, or neural network (e.g., LSTM or Transformer). The training process involves using historical data as input and adjusting model parameters through optimization algorithms, enabling the model to learn the mapping relationship between input features and conflict probability. The dynamic conflict probability prediction function data can serve as an important feature input to the model, or as a constraint or regularization term during model training to ensure that the model fully utilizes these dynamic patterns during prediction. After training, the model becomes a pre-trained conflict prediction model capable of predicting conflict probabilities based on real-time input features.

[0050] In this embodiment, through the above technical solution, this application can systematically extract and utilize the temporal patterns of conflict occurrences and the correlations between different access operation types from historical access records to construct time-dimensional conflict probability distribution function data and conflict correlation matrix data. Simultaneously, by combining training data of the remaining execution time of historical access tasks, these multi-dimensional information are fused and calculated to form dynamic conflict probability prediction function data. Based on this dynamic function and a pre-set model training dataset, a more accurate and robust pre-trained conflict prediction model can be trained. Compared to models that rely solely on general features for prediction, this solution, by deeply mining the temporal and type correlations in historical data, enables the conflict prediction model to more accurately capture the dynamic characteristics and complex patterns of hardware register access conflicts. This improves the accuracy of conflict probability prediction, thereby making subsequent conflict avoidance scheduling more efficient and accurate, effectively reducing the conflict occurrence rate in actual access, and improving the stability and performance of cross-platform hardware register access.

[0051] In one feasible implementation, the step of performing platform adaptation conversion processing on the parsed access feature data based on the conflict avoidance scheduling data, and obtaining platform-specific hardware operation instruction data based on dynamically detected operating system platform characteristics, includes: determining access instruction execution time window data based on access timing arrangement data in the conflict avoidance scheduling data; dynamically detecting the operating system platform characteristics of the current operating environment, the operating system platform characteristics including system call interface characteristics, memory management characteristics, and hardware access mechanism characteristics; selecting an adaptation strategy based on the operating system platform characteristics, the adaptation strategy including instruction conversion rules, permission management rules, and error handling rules; and performing real-time conversion processing on the parsed access feature data according to the adaptation strategy within the access instruction execution time window data to obtain platform-specific hardware operation instruction data.

[0052] In this embodiment, when determining the execution time window data for access instructions, the system utilizes conflict avoidance scheduling data generated in the preceding steps. This scheduling data includes predictions and avoidance schemes for potential access conflicts, explicitly indicating the optimal execution sequence for each hardware access operation. Based on these timing arrangements, for example by analyzing idle time periods, low-load time periods, or waiting cycles of specific tasks marked in the scheduling data, the system defines one or more "access instruction execution time windows." These time windows can be preset fixed durations or dynamically adjusted based on factors such as the type of register access (e.g., read or write operation), data size, and expected response time, to ensure that hardware access operations can be performed within predetermined, conflict-free time periods, thereby effectively avoiding resource contention with other concurrent tasks or hardware operations.

[0053] In this embodiment, when dynamically detecting the operating system platform characteristics of the current operating environment, the system actively identifies and acquires various key characteristics of the current operating system environment. These operating system platform characteristics include system call interface characteristics, memory management characteristics, and hardware access mechanism characteristics. For example, regarding system call interface characteristics, the system can identify specific system call conventions and parameter structures by querying the application programming interface (API) version, system library function list, or kernel module information provided by the operating system, thus distinguishing between Linux, Windows, or real-time operating systems (RTOS). Regarding memory management characteristics, the system can read information such as the virtual memory layout, page table structure, memory protection mechanisms, and direct memory access (DMA) support provided by the operating system to understand whether memory-mapped I / O (MMIO) is supported and the granularity of memory access permissions. Regarding hardware access mechanism characteristics, the system can identify whether access is direct I / O, access via a driver, or access via a hardware abstraction layer (HAL) by querying the device driver interface, bus type (such as PCIe, USB, SPI, I2C), and interrupt controller configuration provided by the operating system. This dynamic detection can perform a comprehensive initialization at program startup, or it can perform periodic or event-triggered updates at runtime based on changes in the system environment (e.g., hot-swappable devices or driver updates) to ensure accurate adaptation.

[0054] In this embodiment, when selecting an adaptation strategy based on operating system platform characteristics, the system selects the most suitable adaptation scheme from a preset strategy library based on dynamically detected platform characteristics. The adaptation strategy includes instruction translation rules, permission management rules, and error handling rules. Instruction translation rules define how to convert general access characteristic data (such as target register address, read / write type, and data value) into platform-specific assembly instructions, system call parameters, or driver interface calls. For example, in a Linux environment, it may be necessary to map the register address to ` / dev / mem` or access it through a specific device driver interface; while in a Windows environment, it may be necessary to open the device handle via `CreateFile` and then send control codes via `DeviceIoControl`. Permission management rules specify the permission levels required to perform hardware operations and the methods for obtaining these permissions. For example, in some operating systems, direct access to hardware registers may require kernel-mode permissions or specific user group permissions; the strategy defines how to request these permissions or how to handle insufficient permissions. Error handling rules define the types of errors that may occur during hardware operation (such as access timeout, permission denial, and hardware failure) and their corresponding handling methods (such as retry mechanisms, error code returns, logging, exception capture, and recovery). These rules can be stored in configuration files, databases, or code modules and can be dynamically loaded or selected based on detected platform characteristics.

[0055] In this embodiment, within the access instruction execution time window, the parsed access feature data is converted in real-time according to the adaptation strategy to obtain platform-specific hardware operation instruction data. The system then activates and applies the selected adaptation strategy within the previously determined access instruction execution time window. It takes the parsed access feature data (e.g., target register address feature data, access timing feature data, and access priority feature data) as input and, according to the instruction conversion rules defined in the adaptation strategy, converts it in real-time into platform-specific hardware operation instruction data that the operating system and hardware can understand and execute. This conversion process is real-time, meaning it processes requests based on the current access request and platform state, rather than pre-generating all possible instructions. For example, if the access feature data indicates writing specific data to a register, the adaptation strategy will generate the corresponding `outb` / `outw` / `outl` instructions (or their equivalent system calls / driver interfaces) based on whether the current operating system is Linux or Windows, along with the correct register address and data value, ensuring the instruction is executed within the correct time window.

[0056] In this embodiment, through the above technical solution, this application can accurately determine the execution time window data of access instructions based on conflict avoidance scheduling data, effectively avoiding timing conflicts between different hardware access tasks. Simultaneously, by dynamically detecting operating system platform characteristics and selecting and applying customized adaptation strategies accordingly, including instruction conversion rules, permission management rules, and error handling rules, it ensures that in a variable and complex cross-platform environment, the parsed access characteristic data can be accurately and securely converted into platform-specific hardware operation instruction data in real time. This not only improves the success rate and efficiency of hardware operation instruction execution but also enhances system stability and compatibility, effectively solving access failures or system anomalies caused by platform differences and timing competition, thereby achieving efficient and reliable cross-platform hardware register access.

[0057] In one feasible implementation, the steps of performing state consistency verification processing on the initial access result data, and performing state repair processing based on the register state change pattern to obtain the verified and repaired final access result data include: acquiring the initial access result data, analyzing to obtain access operation execution state feature data and access result value feature data; acquiring the register state change pattern of the target register from the register state monitoring module, wherein the register state change pattern includes normal state change mode, abnormal state change mode, and state recovery mode; performing matching analysis processing between the access result value feature data and the register state change pattern to obtain state abnormality feature data; generating state repair operation instruction data based on the state abnormality feature data and a preset state repair strategy set; executing the state repair operation instruction data to repair the abnormal state and obtain the repaired access result data; and verifying the state consistency of the repaired access result data based on the access operation execution state feature data to obtain the verified and repaired final access result data.

[0058] In this embodiment, the system first acquires the initial access result data, which is the raw feedback obtained directly from the hardware or operating system level after executing platform-specific hardware operation instructions. Subsequently, the initial access result data is analyzed in depth to extract two key pieces of information: access operation execution status feature data and access result value feature data. The access operation execution status feature data indicates whether the hardware access operation was successfully completed, whether there are error codes, operation time, and other execution-level information. The access result value feature data is specific to different access types; for example, for a read operation, it represents the specific value read from the register; for a write operation, it may represent a write success flag or a verification value read back after writing. Specifically, this data can be obtained by parsing system call return values ​​provided by the operating system, hardware interrupt information, or by directly reading specific status registers.

[0059] In this embodiment, to accurately determine the validity of the initial access result, this application obtains the register state change pattern of the target register from the register state monitoring module. This register state monitoring module is a component specifically designed to track and record the expected behavior of a specific hardware register. The register state change pattern is a predefined or learned behavioral pattern of the target register under different operations, detailing the register's expected performance under various conditions. Specifically, it includes a normal state change pattern, which defines how the register value or state should change under expected operations; an abnormal state change pattern, which describes the state the register may exhibit under erroneous or unexpected conditions; and a state recovery pattern, which defines the path or operation sequence for recovering from a specific abnormal state to a normal state. This module can be a software component that maintains a database or model containing register addresses, expected value ranges, read / write characteristics, and how their values ​​should change after specific operations (such as reset, read, and write).

[0060] In this embodiment, the acquired access result value feature data is matched and analyzed with the register state change patterns obtained from the register state monitoring module. This step aims to identify any inconsistencies or anomalies by comparing the actual access results with the expected register behavior. For example, if a register reads back a value that does not match the written value after a specific value is written, or if an unexpected change in value is detected in a read-only register, it will be marked as an anomaly. The matching analysis can employ a rule engine, state machine comparison, or anomaly detection algorithms based on machine learning. Through this matching analysis, the system can obtain state anomaly feature data, which describes the detected anomalies and may include the anomaly type (such as value mismatch, timeout, permission error), the specific time point of the anomaly, and the register addresses involved.

[0061] In this embodiment, once a state anomaly is detected and state anomaly characteristic data is obtained, the system will generate state repair operation instruction data based on these anomaly characteristics and a preset set of state repair strategies. The state repair strategy set is a predefined library of repair solutions for different anomaly types and severity levels. Generating state repair operation instruction data involves transforming abstract repair strategies into specific, executable hardware operation instructions, such as rewriting, resetting, or performing a series of diagnostic operations. For example, if a register value write failure is detected, the repair strategy might be to retry writing the value; if a register is detected to be in an unknown state, the repair strategy might be to perform a soft reset operation. This process may involve lookup tables, decision trees, or AI-based strategy selection.

[0062] In this embodiment, the system executes the state repair operation instruction data generated in the previous step to repair the abnormal state. This step involves actually performing the repair operation, attempting to restore the registers to the expected or consistent state. The repaired access result data is feedback after the repair operation is executed; it may indicate whether the repair was successful or provide new register state information. This may involve sending specific control commands to the hardware, re-executing part of the original access operation, or triggering the hardware's self-test / recovery mechanism.

[0063] In this embodiment, finally, after the repair operation is executed, to ensure the effectiveness of the repair, the system will re-verify the consistency of the repaired access result data based on the original access operation execution status feature data. This verification aims to confirm whether the repair has truly solved the problem and ensure that the register state has achieved the expected eventual consistency. For example, if the original operation was a read, the system verifies whether the repaired value meets expectations; if the original operation was a write, the system verifies whether the write was ultimately successful and stable. If the repair is successful and the state is consistent, the repaired result is returned as the final result; if the repair fails or inconsistencies still exist, a higher-level error handling mechanism may be triggered. Through this verification, the system can obtain the final access result data after verification and repair, which is the final result that the system considers reliable and consistent after all verification and repair processes.

[0064] In this embodiment, through the above technical solution, this application can acquire initial access result data and analyze its characteristics, and perform matching analysis in conjunction with preset register state change patterns to accurately identify state anomalies. Based on these anomaly characteristics and preset repair strategies, the system can generate and execute state repair operation instructions to proactively repair the abnormal state. Finally, by re-verifying the consistency between the repaired result and the original access operation execution state, it ensures that the access result returned to the user has been verified and repaired, thereby greatly improving the reliability, data accuracy, and system stability of cross-platform hardware register access, and effectively avoiding potential system failures and data errors caused by inconsistent hardware states.

[0065] In one feasible implementation, the step of generating state repair operation instruction data based on the state anomaly feature data and a preset state repair strategy set includes: analyzing the state anomaly feature data to obtain anomaly type data and anomaly severity data; retrieving matching repair strategy template data from the preset state repair strategy set based on the anomaly type data, wherein the repair strategy template data includes repair operation sequence data, repair operation parameter data, and repair verification rule data; adjusting the parameters of the repair strategy template data based on the anomaly type data and anomaly severity data to obtain adjusted repair strategy data; and converting the adjusted repair strategy data into executable state repair operation instruction data.

[0066] In this embodiment, the step of analyzing the state anomaly feature data to obtain anomaly type data and anomaly severity data aims to perform in-depth diagnosis of detected register state anomalies. State anomaly feature data may contain various information, such as deviations between actual and expected register values, access operation error codes, response time anomalies, or unexpected states of specific flag bits. By analyzing these features, the system can identify specific anomaly types, such as data write errors, read errors, timing conflicts, insufficient permissions, and hardware fault indications. Simultaneously, the system also assesses the severity of the anomaly, such as minor data deviations, temporary failures of critical functional modules, or serious errors that could lead to system instability. This can be achieved through predefined rule sets, pattern recognition algorithms based on historical data, or decision tree models incorporating expert knowledge. For example, the severity of the anomaly can be determined based on the error code classification, the magnitude of register value deviation from a preset range, or the criticality of the affected register.

[0067] In this embodiment, when retrieving matching repair strategy template data from the preset state repair strategy set based on the anomaly type data, where the repair strategy template data includes repair operation sequence data, repair operation parameter data, and repair verification rule data, the preset state repair strategy set is a knowledge base containing various repair schemes for different anomaly situations. Each repair strategy template data is for a specific anomaly type or class. When the system identifies a specific anomaly type, it searches for the most matching repair strategy template in the set based on that type of data. For example, if the anomaly type is "data write error," it may match templates for "retry write" or "restore to the last correct state." The repair strategy template data is structured, containing repair operation sequence data to define the steps to be executed during the repair process; repair operation parameter data to specify the specific parameters of these operations, such as write value, delay, number of retries, etc.; and repair verification rule data to evaluate the repair effect after the repair operation is completed, such as rereading and comparing with the expected value, checking specific status bits, etc.

[0068] In this embodiment, when adjusting the parameters of the repair strategy template data based on the anomaly type data and anomaly severity data to obtain the adjusted repair strategy data, the repair strategy template data provides a general repair framework. However, to achieve more accurate and efficient repair, it needs to be customized according to the specific anomaly situation. This step uses the identified anomaly type data and anomaly severity data to fine-tune the retrieved repair strategy template data. For example, for "data write error," if the anomaly severity data indicates that the error is an occasional minor deviation, the number of retries in the repair operation parameter data can be set to a smaller value; if the error is a persistent and serious problem, the number of retries may need to be increased, or more complex diagnostic steps may need to be added to the repair operation sequence data. Parameter adjustment processing may involve modifying the specific instructions in the repair operation sequence data, adjusting the values ​​in the repair operation parameter data (such as delay, write value range, etc.), and even adjusting the thresholds in the repair verification rule data according to the severity to ensure that the repair strategy is highly matched with the current anomaly situation.

[0069] In this embodiment, when converting the adjusted repair strategy data into executable state repair operation instruction data, the adjusted repair strategy data is still a high-level logical description and needs to be converted into an instruction sequence that the underlying system or hardware can directly understand and execute. This step is responsible for mapping abstract repair operations (such as "reset registers" or "reinitialize module") to specific platform-specific hardware operation instructions. This typically involves decomposing logical operations into a series of read / write commands, control signals, etc., that conform to the timing and protocol requirements of a specific hardware interface. For example, if the repair strategy data indicates the need to "reset a module," it may be converted into a series of write operations to the control registers of that module, which need to conform to the timing and protocol requirements of a specific hardware interface. This conversion process ensures that the repair strategy can be executed accurately by the system, thereby achieving effective repair of abnormal states.

[0070] In this embodiment, through the above technical solution, after performing state consistency verification on the initial access result data, the application first meticulously analyzes the state anomaly characteristic data to obtain anomaly type data and anomaly severity data when generating state repair operation instruction data. Based on these diagnostic results, the system can accurately retrieve the repair strategy template that best matches the current anomaly from a preset strategy set. Furthermore, by adjusting the parameters of the repair strategy template data based on the anomaly type data and anomaly severity data, the generated repair strategy is no longer generalized but highly customized and adaptive. For example, different repair operation sequences can be used for different types of errors (such as data errors and timing errors); for errors of different severity, the number of retries, delays, or recovery ranges can be adjusted. This refined strategy selection and parameter adjustment improves the accuracy and efficiency of state repair, avoids over-repair or under-repair, and thus ensures the rapid recovery of hardware register states and the stability of system operation. Compared with generating repair instructions solely based on anomaly characteristics, this solution can more intelligently and effectively cope with complex hardware register anomalies, improving the robustness and reliability of the entire cross-platform hardware register access method.

[0071] In one feasible implementation, the step of adjusting the parameters of the repair strategy template data based on the anomaly type data and anomaly severity data to obtain adjusted repair strategy data includes: determining the target register set data and repair operation type data of the repair operation based on the anomaly type data; determining the execution priority data and time window data of the repair operation based on the anomaly severity data; extracting repair operation sequence data from the repair strategy template data based on the target register set data and repair operation type data; performing time-series adjustment processing on the repair operation sequence data based on the execution priority data and repair operation time window data to obtain time-series adjusted repair operation sequence data; setting the parameter adjustment range data and verification threshold data of the repair operation based on the anomaly severity data; and integrating the time-series adjusted repair operation sequence data, parameter adjustment range data, and verification threshold data to obtain the adjusted repair strategy data.

[0072] In this embodiment, the anomaly type data is the result of classifying detected register state anomalies, such as read / write errors, timeouts, data corruption, and permission conflicts. Based on these specific anomaly type data, the system can accurately identify which registers or register groups are affected by the "target register set data" and what type of "repair operation type data" needs to be performed, such as reset, rewrite, clear cache, or reinitialize. This ensures the targeted nature of the repair operations and avoids unnecessary intervention in irrelevant registers. For example, this can be achieved through a predefined mapping table between anomaly type data, target register set data, and operation type data. When a specific anomaly type data is detected, the system queries this mapping table to obtain the corresponding target register set data and repair operation type data.

[0073] In this embodiment, the anomaly severity data is a quantitative assessment of the impact of the anomaly on system functionality, such as minor, moderate, severe, or critical. Based on the anomaly severity data, the system can dynamically determine the execution priority data of repair operations (e.g., high, medium, low, or urgent, routine) to ensure that critical anomalies are handled promptly. Furthermore, the time window data for repair operations can be determined, i.e., the maximum or optimal time period during which repair operations are allowed to execute. This is particularly important for systems with high real-time requirements, preventing the repair process from consuming excessive resources or causing prolonged system downtime. For example, the execution priority data and time window data can be determined through a policy configuration table based on the anomaly severity data.

[0074] Based on this, the repair strategy template data is a predefined set of general operation steps for different repair scenarios. Once the specific target register set data and repair operation type data are determined, the system can accurately filter out the most matching repair operation sequence data from these repair strategy template data. This repair operation sequence data contains a series of atomic operations required to complete a specific repair task, such as "read register X -> calculate new value -> write register X -> verify register X". The repair strategy template data can be stored as structured data, such as XML, JSON files, or database records, containing the definitions and parameters of various repair operations. The system retrieves and extracts the corresponding repair operation sequence data from the repair strategy template data based on the target register set data and repair operation type data as keywords.

[0075] In this embodiment, the original repair operation sequence data may only represent logical steps, but actual execution requires consideration of execution priority data and time window data. Through timing adjustment, the system arranges the execution order and resource allocation of operations based on the execution priority data, ensuring that high-priority operations are executed first. Simultaneously, combined with time window data, the system optimizes the execution timing and duration of the repair operation sequence data. For example, it may split time-consuming operations, delay non-critical operations, or execute independent operations in parallel to meet real-time requirements or avoid exceeding preset time limits. Scheduling algorithms (such as priority scheduling and time-slice round-robin) can be used to reorder and allocate time for the repair operation sequence data.

[0076] Furthermore, remediation operations often involve parameters (such as write values, latency, and retries) and validation criteria. Based on the severity of the anomaly, the system can dynamically set the adjustment range and validation threshold for these parameters. For example, for severe anomalies, the parameter adjustment range might be broader, allowing for more aggressive remediation attempts; while the validation threshold might be more stringent, requiring a higher success rate or more precise validation results. This helps to strike a balance between remediation effectiveness and system stability. Anomaly severity data can be correlated with parameter adjustment range and validation threshold data through a mapping table or rule engine.

[0077] In this embodiment, the results of all the preceding fine-tuning adjustments are finally aggregated to form a complete and executable adjusted repair strategy data. This adjusted repair strategy data not only includes the repair steps (time-adjusted repair operation sequence data), but also specifies the acceptable parameter variation range for these steps during execution (parameter adjustment range data), and the criteria for judging whether the repair is successful (verification threshold data). This integrated strategy is highly customized and can more effectively guide subsequent state repair operations.

[0078] In this embodiment, through the above technical solution, this application can accurately determine the target register set data and repair operation type data based on anomaly type data, thereby making the repair operation highly targeted and avoiding unnecessary intervention in irrelevant registers. Simultaneously, the execution priority data and time window data of the repair operation are dynamically determined based on anomaly severity data, ensuring that critical anomalies are handled promptly and efficiently, and effectively controlling the impact of the repair process on system real-time performance. Based on this, repair operation sequence data, after time-adjusted processing, is extracted from the repair strategy template data and combined with parameter adjustment range data and verification threshold data set according to anomaly severity data, ultimately forming highly customized adjusted repair strategy data. This makes the state repair process no longer a simple template application, but allows for refined and dynamic adjustments based on specific anomaly scenarios, improving the accuracy, efficiency, and reliability of the repair operation, effectively avoiding the introduction of new system inconsistencies due to improper repair, and thus ensuring the stability and data consistency of cross-platform hardware register access.

[0079] In one feasible implementation, before executing the platform-specific hardware operation instruction data to obtain initial access result data, the method further includes: performing integrated security verification processing on the platform-specific hardware operation instruction data to obtain security verification result data; the integrated security verification processing includes permission verification processing, conflict security verification processing, and state security verification processing; based on the security verification result data, when the security verification passes, executing the platform-specific hardware operation instruction data to obtain initial access result data; when the security verification fails, generating security blocking response data and returning the final access result data after verification repair to the user.

[0080] In this embodiment, the integrated security verification process aims to perform a comprehensive, multi-dimensional security check on the hardware operation instructions to be executed, ensuring their legality and security, and avoiding negative impacts on the system. Specifically, this process includes permission verification, conflict security verification, and state security verification. Permission verification verifies whether the user or process requesting the execution of the hardware operation instruction has the appropriate permissions. For example, the system can maintain a permission list or policy specifying which users or processes can access specific registers or perform specific types of operations (such as read, write, or modify), and prevent unauthorized access by comparing the currently requested permissions with preset policies. Conflict security verification focuses on detecting whether the hardware operation instruction to be executed will cause resource contention or logical conflicts with other ongoing or upcoming tasks. This can be achieved by analyzing the instruction's target address, access timing, and the system's current resource usage to identify and avoid potential problems. State security verification assesses whether the current state of the target hardware register or related system components is suitable for executing the upcoming operation. For example, by checking the register's status flags, system mode, or expected state model, it ensures that the operation is performed in a safe and consistent state, avoiding system crashes or data corruption due to improper operation.

[0081] In this embodiment, based on the security verification result data, when the security verification passes, the system will allow the execution of platform-specific hardware operation instructions to obtain initial access result data. Conversely, when the security verification fails, the system will generate security blocking response data and execute the step of returning the final access result data after verification repair to the user, promptly informing the user of the reason for the operation failure and preventing potential security risks from further escalating.

[0082] In this embodiment, through the above technical solution, this application effectively solves the potential security risks and vulnerabilities that may exist before executing platform-specific hardware operation instructions. The permission verification process ensures that only requests with legitimate permissions can access hardware registers, thereby preventing unauthorized malicious operations. The conflict security verification process can pre-identify and avoid resource contention or logical conflicts with other tasks, improving system stability and data consistency. The state security verification process ensures that hardware operation instructions are executed only when the target register is in a safe and consistent state, avoiding system crashes or data corruption due to improper operation. When security verification passes, the instruction is executed smoothly, ensuring normal business operations; when verification fails, the system can promptly generate security blocking response data and return it to the user, effectively preventing the execution of unsafe operations and providing clear feedback to the user, thus greatly enhancing the security, reliability, and robustness of the entire cross-platform hardware register access method.

[0083] In the embodiments of this application, the cross-platform hardware register access method receives user-input access request data and performs operations such as parsing, conflict prediction calculation, platform adaptation conversion, instruction execution, and status verification and repair. This achieves an efficient cross-platform register access mechanism, enabling cross-platform compatibility, effective management of concurrent access conflicts, and automatic detection and repair of status anomalies, thereby improving system reliability and development efficiency.

[0084] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the cross-platform hardware register access method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0085] This application also provides a cross-platform hardware register access system, see reference. Figure 2 The cross-platform hardware register access system includes: a memory 10, a processor 20, and a cross-platform hardware register access program stored on the memory 10 and executable on the processor 20. The cross-platform hardware register access program is configured to implement the steps of the cross-platform hardware register access method.

[0086] The cross-platform hardware register access system provided in this application, employing the cross-platform hardware register access method in the above embodiments, can improve system reliability and development efficiency. Compared with the prior art, the beneficial effects of the cross-platform hardware register access system provided in this application are the same as those of the cross-platform hardware register access method provided in the above embodiments, and other technical features of the cross-platform hardware register access system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0087] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0088] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. All equivalent structural transformations made under the technical concept of this application using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the scope of patent protection of this application.

Claims

1. A cross-platform hardware register access method, characterized in that, The method includes: Receive user-input access request data and obtain the original access request data; The original access request data is parsed to obtain parsed access feature data. Based on the parsed access feature data and the current access task status, conflict prediction calculation is performed to obtain conflict avoidance scheduling data. Based on the conflict avoidance scheduling data, the parsed access feature data is subjected to platform adaptation conversion processing, and platform-specific hardware operation instruction data is obtained based on the dynamically detected operating system platform features. Execute the platform-specific hardware operation instructions to obtain the initial access result data; The initial access result data is subjected to state consistency verification processing, and state repair processing is performed based on the register state change pattern to obtain the final access result data after verification and repair. The final access result data after verification and repair is returned to the user.

2. The cross-platform hardware register access method as described in claim 1, characterized in that, The steps of parsing the original access request data to obtain parsed access feature data, and then performing conflict prediction calculations based on the parsed access feature data and the current access task status to obtain conflict avoidance scheduling data include: The original access request data is parsed to extract target register address feature data, access timing feature data, and access priority feature data to obtain the parsed access feature data. Obtain the current access task status, which includes the set of access tasks currently being executed, the execution progress of the access tasks, and the estimated completion time; Based on the target register address feature data and access timing feature data, matching access pattern data is retrieved from the historical access record database to obtain access pattern matching result data. Based on the current access task status and the access pattern matching result data, the conflict probability prediction calculation is performed using the target register address feature data and access timing feature data to obtain conflict probability prediction data. Based on the conflict probability prediction data and the access priority feature data, scheduling planning is performed to obtain the conflict avoidance scheduling data.

3. The cross-platform hardware register access method as described in claim 2, characterized in that, Based on the current access task status and the access pattern matching result data, the steps of performing conflict probability prediction calculation using the target register address feature data and access timing feature data to obtain conflict probability prediction data include: Analyze the execution progress of the access task in the current access task status, and calculate the predicted remaining execution time of the access task; Historical conflict occurrence pattern data is extracted from the access pattern matching result data. The historical conflict occurrence pattern data includes conflict type distribution data, conflict time distribution data, and conflict resolution strategy data. Using a pre-trained conflict prediction model, based on the remaining execution time prediction data of the access task, the historical conflict occurrence pattern data extracted from the access pattern matching result data, the target register address feature data, and the access timing feature data, the probability value of access conflict is calculated to obtain the conflict probability prediction data.

4. The cross-platform hardware register access method as described in claim 3, characterized in that, The method further includes: Historical conflict occurrence records are obtained from the historical access record database. Based on the historical conflict occurrence records, conflict time distribution training data is extracted to establish time-dimensional conflict probability distribution function data. Based on the historical conflict occurrence record data, conflict type distribution training data is extracted to establish conflict correlation matrix data for different types of access operations; Training data on the remaining execution time of historical access tasks are obtained from the historical access record database. The time-dimensional conflict probability distribution function data and the conflict correlation matrix data are fused and calculated to obtain dynamic conflict probability prediction function data. Based on the dynamic conflict probability prediction function data and the preset model training dataset, the pre-trained conflict prediction model is trained and generated.

5. The cross-platform hardware register access method as described in claim 1, characterized in that, The steps of performing platform-adaptive conversion processing on the parsed access feature data based on the conflict avoidance scheduling data, and obtaining platform-specific hardware operation instruction data based on dynamically detected operating system platform features, include: Based on the access timing arrangement data in the conflict avoidance scheduling data, determine the access instruction execution time window data; Dynamically detect the operating system platform characteristics of the current operating environment, including system call interface characteristics, memory management characteristics, and hardware access mechanism characteristics; Based on the characteristics of the operating system platform, an adaptation strategy is selected, which includes instruction conversion rules, permission management rules, and error handling rules. Within the access instruction execution time window, the parsed access feature data is converted in real time according to the adaptation strategy to obtain platform-specific hardware operation instruction data.

6. The cross-platform hardware register access method as described in claim 1, characterized in that, The steps for performing state consistency verification on the initial access result data, and state repair processing based on the register state change pattern to obtain the verified and repaired final access result data include: The initial access result data is obtained, and the access operation execution status feature data and access result value feature data are analyzed. The register state change pattern of the target register is obtained from the register state monitoring module. The register state change pattern includes normal state change pattern, abnormal state change pattern and state recovery pattern. The access result value feature data is matched and analyzed with the register state change pattern to obtain state anomaly feature data. Based on the aforementioned abnormal state feature data and the preset set of state repair strategies, state repair operation instruction data is generated. Execute the state repair operation instruction data to repair the abnormal state and obtain the repaired access result data; Based on the access operation execution status feature data, the consistency of the status of the repaired access result data is verified to obtain the final access result data after verification and repair.

7. The cross-platform hardware register access method as described in claim 6, characterized in that, The steps for generating state repair operation instruction data based on the aforementioned state anomaly feature data and the preset state repair strategy set include: Analyze the abnormal status feature data to obtain abnormality type data and abnormality severity data; Based on the anomaly type data, a matching repair strategy template data is retrieved from the preset state repair strategy set. The repair strategy template data includes repair operation sequence data, repair operation parameter data, and repair verification rule data. Based on the anomaly type data and anomaly severity data, the parameters of the repair strategy template data are adjusted to obtain the adjusted repair strategy data. The adjusted repair strategy data is converted into executable state repair operation instruction data.

8. The cross-platform hardware register access method as described in claim 7, characterized in that, The steps for adjusting the parameters of the repair strategy template data based on the anomaly type data and anomaly severity data to obtain the adjusted repair strategy data include: Based on the anomaly type data, determine the target register set data and repair operation type data for the repair operation; Based on the severity data of the anomaly, the execution priority data and time window data of the repair operation are determined; Based on the target register set data and repair operation type data, repair operation sequence data is extracted from the repair strategy template data; Based on the execution priority data and the time window data of the repair operation, the repair operation sequence data is subjected to timing adjustment processing to obtain the timing-adjusted repair operation sequence data. Based on the severity data of the anomaly, set the parameter adjustment range data and verification threshold data for the repair operation; By integrating the time-adjusted repair operation sequence data, parameter adjustment range data, and verification threshold data, the adjusted repair strategy data is obtained.

9. The cross-platform hardware register access method as described in claim 1, characterized in that, Before the step of executing platform-specific hardware operation instruction data to obtain initial access result data, the method further includes: Integrated security verification processing is performed on the platform-specific hardware operation instruction data to obtain security verification result data; the integrated security verification processing includes permission verification processing, conflict security verification processing, and state security verification processing; Based on the security verification result data, when the security verification is successful, the platform-specific hardware operation instruction data is executed to obtain the initial access result data; when the security verification fails, security blocking response data is generated and the final access result data after the verification is repaired is returned to the user.

10. A cross-platform hardware register access system, characterized in that, The cross-platform hardware register access system includes: a memory, a processor, and a cross-platform hardware register access program stored in the memory and executable on the processor, the cross-platform hardware register access program being configured to implement the steps of the cross-platform hardware register access method as described in any one of claims 1 to 9.

Images