Modern configurable processors enable application-specific optimization through three adaptation layers [4] : 1) Microarchitecture: FPGA/ASIC implementations with reconfigurable logic [5] ; 2) Instruction Set: Extensible ISA support through coprocessor integration [6] ; 3) Memory Hierarchy: Adaptive register files and cache configurations.

The GNU Binutils [7] toolkit provides essential infrastructure for configurable assemblers: 1) BFD Library: Unified object file manipulation; 2) GAS Architecture: Modular assembler framework with MD interface; 3) Linker Scripts: Customizable memory allocation strategies.

Our research platform features a hybrid RISC architecture with (see Figure 1 ):

The instruction set combines RR-type (register-register) and RI-type (register-immediate) formats with configurable addressing modes, serving as our primary case study for assembler development.

Configurable assemblers are supported by ongoing research in instruction set description languages (ISDL) [8] , which formalize processor architecture descriptions, enhancing the retargetability of compilers and assemblers. For example, ISDL allows for automatic assembler generation suited to specific instruction sets, improving tool flexibility and adaptability to evolving hardware. Recent advancements include Xiao and Liu’s 2023 ISADL, designed for Very Long Instruction Word (VLIW) architectures [9] , and their adaptive instruction set encoding method [10] , along with the Vienna Architecture Description Language proposed by Himmelbauer et al. in 2024 [11] . These developments contribute new perspectives and tools to ISDL research, advancing computing architecture design.

Our work’s approach to abstracting the assembler’s interface reflects the need for tools adaptable to changing instruction sets, aligning with trends in configurable tool development for diverse ISAs and ASIPs in SoC designs [12] .

Retargetable and configurable compilers/assemblers each bring unique flexibility to compiler design. Retargetable compilers, such as GCC, adapt across processor types by altering target descriptions, while configurable compilers allow user-defined tool customization for evolving hardware projects. Both approaches share a focus on adaptability to varying architectures. Recent key contributions include Arbone et al.’s model-driven inline assembler generator, enhancing retargetability and maintenance [13] , Povazan et al.’s adaptable generic compiler framework [14] , Korenkov et al.’s insights on ASIP compiler challenges [15] , and Vasilache et al.’s modular code generation design for tensor compilers [16] . Numerous studies address configurable tool design, including Taglietti et al.’s automatic pre-processor and assembler generation for ASIPs via ADLs [17] , Abbaspour and Zhu’s retargeting techniques for GNU binutils [18] , and Youn et al.’s assembler and linker platform for embedded systems [19] . Baldassin et al. demonstrate binary tool generation using ArchC within the GNU binutils framework [20] . Moona [21] presents a method for developing processor-specific tools through high-level ISA models, allowing retargeting across various designs.

Despite advancements in configurable assembler design, challenges persist, including a lack of standardization leading to inconsistencies, performance trade-offs compared to specialized compilers, and difficulties in supporting rapidly evolving hardware architectures. This paper aims to address these limitations to enhance the usability and performance of configurable assembler tools.

Hu Ming et al. [22] propose a curiosity-driven reinforcement learning method to efficiently synthesize CCSL constraints from incomplete specifications, significantly improving synthesis speed and accuracy over existing approaches.

MARTE extends UML with domain-specific stereotypes, tagged values, and constraints to model:

Key MARTE stereotypes relevant to our assembler design include:

We model the assembler’s configurable components using MARTE’s <<HwComponent>> and <<SwResource>> stereotypes (see Figure 2 ):

MARTE enables:

We applied MARTE to verify the TOP-32A extension (Section 2.3), ensuring that:

The model detected a bitfield conflict in RIB-32 instructions, which was resolved by adjusting the encoding schema.

To enable self-optimizing assembler behavior, we formulate the configuration adaptation process as a Markov Decision Process (MDP). The MDP interacts with the MARTE model to ensure formal constraints are satisfied during optimization.

The MDP is defined by the tuple :

$\begin{array}{l}{s}_t=({\text{HwProcessor}}_{cfg},{\text{HwMemory}}_{usage},\\ {\text{GaWorkloadEvent}}_{type},{\text{GaScenario}}_{progress})\end{array}$ (1)

where:

$\begin{array}{l}{a}_t\in \{\text{Modifybitfieldallocation},\text{Adjustregistermapping},\\ \text{Switchinstructionpipeline},\text{Adaptaddressingmode}\}\end{array}$ (2)

Each action modifies MARTE stereotypes (e.g., updating <<BitField>> constraints or <<HwMemory>> allocations).

$\begin{array}{c}ℛ\left(s_t,a_t\right)=\underset{\text{Correctness}}{\underset{︸}{w_1\cdot \text{EncodingSuccess}}}+\underset{\text{Efficiency}}{\underset{︸}{w_2\cdot \frac{1}{\text{EncodingTime}}}}\\ -\underset{\text{Safety}}{\underset{︸}{w_3\cdot \text{ConstraintViolations}}}\end{array}$ (3)

where $w_1,w_2,w_3$ are tunable weights, which were selected through grid search and cross-validation on a subset of training tasks. Constraint violations are detected via MARTE OCL checks.

$\begin{array}{l}\underset{\theta }{\max }{\mathbb{E}}_{{\pi }_{\theta }}\left[\underset{t=0}{\overset{T}{{\displaystyle \sum }}}{\gamma }^tℛ\left(s_t,a_t\right)\right]\\ \text{s}.\text{t}.\text{ocl\_check}\left(a_t,s_t\right)=\text{True},\forall t\end{array}$ (5)

By integrating MARTE’s formal constraints as hard filters in the policy network, we ensure:

Benchmarks on the TOP-32A extension showed a 22% reduction in average encoding time compared to static configurations, with zero constraint violations during optimization.

This section presents a streamlined framework for architecture-agnostic assembly translation, focusing on three core components: instruction abstraction, dynamic parsing, and configuration interfaces.

The assembler adopts a modular design with configuration-driven components ( Figure 5 ), utilizing a Common ISA Description Language (CIDL) to decouple processor-specific details from translation logic. Key features include:

The framework models instructions through three configurable elements:

The four-stage translation pipeline integrates with MARTE timing constraints:

The assembler supports processor customization through five key configuration files:

This interface enables rapid retargeting while maintaining formal verification through integrated MARTE constraints, complementing the RL-enhanced optimization discussed in Section 4. Benchmark results show 85% reduction in configuration effort compared to traditional assemblers when adapting to new ISA variants like TOP-32A.

The purpose of an assembler is to convert assembly instructions into machine code. Testing its correctness involves verifying that the generated machine instructions match the ISA definition. The process uses source files with various assembly instructions and their correct encodings as comments. The assembler converts these into an object file (.o), from which the “objdump” tool extracts binary code into a formatted text file. This file is then compared with the expected encodings.

The input assembly file includes test cases for each instruction format and operand type, ensuring comprehensive coverage (see Table 2 ). Figure 6 outlines the testing flow, while Figure 7 provides examples for RIC-32 compare instructions. A bash script automates the comparison by extracting machine instructions and correcting encodings, then checking for discrepancies ( Figure 8 ). All 26 test cases in the basic instruction set have been successfully validated.

Assembler configurability reflects its adaptability to changes in a processor’s instruction set. Good configurability allows quick updates to the assembler’s source code with minimal effort. Measuring this involves assessing development

time, which can be challenging due to varying complexity and developer skills. This study simplifies measurement by counting the lines of code affected by instruction set changes.

The testing model involves using typical instruction set changes as inputs and comparing affected code lines in both prototype and configurable assemblers. This approach assumes that testers lack detailed knowledge of the assembler’s internals, so all relevant lines are counted. The test inputs defined in Table 3 focus on changes in instruction encoding and assembly syntax, with results analyzed for each test scenario.

In this test, an addition and shift instruction “l.addx2” will be added to the TOP instruction set. This instruction has two formats: RI-32 and RR-32 (see Figure 9 ).

Under the configurable compiler structure, adapting to the above change is quite simple: since the instruction types already exist, it is only necessary to find the RI-32 and RR-32 entries in the instruction static table definition and add the instruction opcode name and corresponding encoding. Figure 10 describes the specific code changes after adding the “l.addx2” instruction.

Table 4 lists the lines of code affected after adding the “l.addx2” instruction. The first row of Table 4 represents the different types of configuration interface files for the assembler. As can be seen, this test has a minimal impact on the source code, and the modifier does not need to understand the internal workings of the assembler.

In a traditional assembler prototype, adding an “l.addx2” instruction would not only require modifying the instruction definition part but also handling the opcode parsing part. According to the analysis of the assembler backends for ARM, ARC, and OpenRISC platforms in Binutils, implementing the above change would involve modifying over 300 lines of source code on average.

In this test, a new instruction type will be added to the TOP instruction set, which has the format shown in Figure 11 . This format is similar to the RR-32 format but has four general-purpose register operands, with each register occupying 4 bits and ranging from “r8” to “r23”. Therefore, this instruction type is called RRR-32.

To add an instruction type under the configurable assembler framework, the following steps need to be completed:

Step 1. Add a new general-purpose register type. Modify the GPR configuration interface (“extif-gpr_table.c”) to add a register type ranging from “r8” to “r23”. The specific modification is listed in the code snippet in Figure 12 .

Step 2. Add the new instruction type identifier “INSN_TYPE_RRR32” to the interface file “extif-opcode.h”.

Step 3. Define the RRR-32 instruction type in the instruction type configuration file (“extif-insn_table.c”). Describing the instruction type, opcode, operands, and format abbreviation in sequence completes the definition of this type. The specific definition can be seen in Figure 13 , which also defines a test instruction ‘rrrtest’ within the RRR-32 instruction type.

The structure in Figure 13 may seem complex, but upon closer examination, it is similar to describing an instruction type in plain language. The RRR-32 instruction type can be described in plain language as follows: “The RRR-32 instruction type is an instruction containing four operands (‘.ope_num=4’), each operand is a register (‘format=‘RRRR’’); the opcode occupies bits 24 to 29 (‘enc_opc_lst=⋯’), the first three registers occupy bits 2 to 13 in sequence, each register occupies 4 bits, and the fourth register occupies bits 0, 1, 16, and 17 (‘enc_ope_lst=⋯’).”

Table 5 lists the lines of source code affected by adding the RRR-32 instruction type.

If using an unabstracted assembler prototype, adding a new instruction type would be highly complex. It would require extensive rewriting of dynamic parsing operations and deep knowledge of the assembler’s internals. Analysis of ARM, ARC, and OpenRISC backends in Binutils suggests such a change would involve modifying over 1,000 lines of source code on average.

In this test, the RRR-32 instruction type from Test 2 will be modified to an RRI-32 instruction type. It includes three register operands and one immediate operand, with each operand occupying 4 bits of encoding. The specific format definition is shown in Figure 14 .

To complete the modification of the instruction type under the configurable assembler framework, you only need to change the fourth operand in the RRR-32 instruction type definition to an immediate operand in the instruction configuration file (“extif-insn table.c”) and add the corresponding relocation information “r”. The specific modification steps are as follows:

Step 1. Add a relocation definition for the immediate operand in the relocation configuration file. This involves modifications to three configuration files:

This test will add a MIMD (Multiple Instructions Multiple Data) type instruction to the TOP instruction set. It will comprehensively test the configurability of the assembler. The format of this MIMD-type instruction is defined in Figure 15 . The instruction comprises three sub-instructions: AC (10 bits), MC (7 bits), and XMC (7 bits). AC includes six instruction types, while MC and XMC have four types each. To add this MIMD-type instruction to the configurable assembler framework, follow these steps:

Step 1. Define special registers used in MIMD in the special register configuration file (extif-spr_table.c). For example, the accumulators CH and CL. The specific modifications to the special register configuration file are shown below, where the fields in the special register table entries are, in order, the special register name, instruction type, and special register encoding.

After these steps, the assembler is complete. When encountering a MIMD instruction, the assembler’s lexical parser will parse out three instructions, then sequentially traverse these three instructions, query the newly established instruction type table, and generate the correct machine code.

Table 7 lists the lines of source code affected by adding the MIMD instruction type. Defining the MIMD instruction type affects approximately 235 lines of instruction and only involves the definition of structures and enumerations.

Adding this MIMD instruction type to the assembler prototype platform would require extensive modifications, including new instruction definition tables and parsing functions. Based on analysis of ARM, ARC, and OpenRISC platforms, it’s estimated that over 2000 lines of code would be affected.

Table 8 lists the test results for the above four test sets. The configurable assembler adapts well to changes in the instruction set: the modification amount for handling general instruction set changes is within 100 lines, and the modification amount for adding complex instructions like MIMD is also significantly lower than that of general assemblers.

To evaluate the effectiveness of our RL-enhanced MARTE constraint solver in assembler configuration optimization, we conducted comparative experiments across four typical ISA adaptation scenarios. The RL agent was trained using 200 historical configuration tasks with curriculum learning, achieving 92% convergence accuracy after 150 training epochs.

We compared three configuration strategies:

The evaluation metrics included:

Table 9 and Figure 16 demonstrate RL-MARTE’s superior performance in complex configuration tasks:

Key findings include:

These results validate that RL-MARTE effectively balances architectural constraints with optimization objectives, particularly excelling in:

The experiment demonstrates significant advantages in handling non-trivial ISA extensions like the MIMD case study, where RL-MARTE achieved 40% faster configuration than manual approaches while maintaining full constraint compliance.