ScEpTIC.emulator.register_file package¶

Submodules¶

ScEpTIC.emulator.register_file.physical_register_file module¶

class ScEpTIC.emulator.register_file.physical_register_file.PhysicalRegisterFile(register_file_configuration)¶

Bases: ScEpTIC.emulator.register_file.register_file.RegisterFile

Implementation of a RegisterFile which uses physical registers. In this case, registers are pre-allocated but virtual addresses returned by alloca are still present and thus are managed with the self._addresses dictionary. On function call only _addresses values are saved.

diff(dump)¶: Returns the difference between the current state of the register file and the one saved inside a dump.

get_input_lookup(register_name)¶: Returns the input lookup information for a given register.

get_visual_dump()¶: Returns a string representing the memory

on_function_call()¶: Callback for function call. Each function has its own virtual registers, which all starts from %0. The only virtual registers that remains after register allocation are the one “removed” then by data layout, which represents only the addresses of elements inside the stack. So I must save them before execution of a function and restore them after its return.

on_function_return()¶: Callback for function return.

read_address(register_name)¶: Returns the value of an address register.

requires_register_allocation = True¶

reset(main)¶: Performs the reset of the register_file (after a cpu reset).

restore(dump)¶: Restores a dump of the register file.

set_address_input_lookup(register_name, input_lookup)¶: Sets the input lookup information for a given address register.

write_address(register_name, address)¶: Set the value of an address register. Address are considered only as values returned by alloca operations. There are different behaviours depending on physical/virtual register file. On physical register file, register allocation is performed. Alloca operations just make space on stack and their value is known compile-time. This means that the virtual register wouldn’t be mapped to a real one, since the stack offset is found and directly placed on the load/store operation that uses this portion of memory. Also, multiple alloca operations will be mapped to a single increment of the stack. (This is done in data layout) NB: this is to do not have register’s spill due to not doing data layout. In a “real” machine code, those spills won’t be there

ScEpTIC.emulator.register_file.program_counter module¶

class ScEpTIC.emulator.register_file.program_counter.ProgramCounter(function_name, instruction_number)¶

Bases: object

Program Counter. This emulator doesn’t assign a direct address to each instruction, so the PC is composed by the function name and the instruction number inside the function. function_name is used to get the correct context. The program counter can be seen as the address of function_name plus instruction_number (which is just an offset from function_name’s address). Since the actual program is not converted into machine code, the llvmir doesn’t have a proper address and this representation is needed.

increment_pc()¶: Increments the instruction_number.

pc_tree()¶: Returns the program counter with its call tree

resolve()¶: Returns the call trace of the program counter.

restore(saved_pc)¶: Restores the program counter from a previous dump.

save()¶: Returns a dump of the program counter.

update(function_name, instruction_number)¶: Updates the function_name and instruction_number with the provided values.

ScEpTIC.emulator.register_file.register module¶

class ScEpTIC.emulator.register_file.register.Register(name)¶

Bases: object

Register object. It has just a name and a value. This emulator is not interested in the actual type nor the data representation.

static direct(name, value)¶: Initializes a register, sets its value, and returns it.

ScEpTIC.emulator.register_file.register_file module¶

class ScEpTIC.emulator.register_file.register_file.RegisterFile¶

Bases: object

Register File. It contains registers of the architecture. The _reg_stack dictionary is used to save/restore registers or addresses on function call/return. This will preserve the correctness of the program, witout having to:

Perform register allocation

Perform datalayout calculation if register allocation is done

compare_with_dump(dump)¶: Returns if the status of register file is the same of a given dump.

diff(dump)¶: Returns the difference between the current state of the register file and the one saved inside a dump.

dump()¶: Returns a dump of the register file.

get_input_lookup(register_name)¶: Returns the input lookup information for a given register.

get_visual_dump()¶: Returns a string representing the memory

read(register_name)¶: Return the value of a register given its name.

read_address(register_name)¶: Returns the value of an address register.

property reg_type¶: Returns register file type

reset(main)¶: Performs the reset of the register_file (after a cpu reset).

restore(dump)¶: Restores a dump of the register file.

set_address_input_lookup(register_name, input_lookup_data)¶: Sets the input lookup information for a given address register.

set_input_lookup(register_name, input_lookup_data)¶: Sets the input lookup information for a given register.

write(register_name, register_value)¶: Set the value of a register given its name.

write_address(register_name, address)¶: Set the value of an address register. Address are considered only as values returned by alloca operations. There are different behaviours depending on physical/virtual register file. On physical register file, register allocation is performed. Alloca operations just make space on stack and their value is known compile-time. This means that the virtual register wouldn’t be mapped to a real one, since the stack offset is found and directly placed on the load/store operation that uses this portion of memory. Also, multiple alloca operations will be mapped to a single increment of the stack. (This is done in data layout) NB: this is to do not have register’s spill due to not doing data layout. In a “real” machine code, those spills won’t be there

ScEpTIC.emulator.register_file.virtual_register_file module¶

class ScEpTIC.emulator.register_file.virtual_register_file.VirtualRegisterFile¶

Bases: ScEpTIC.emulator.register_file.register_file.RegisterFile

Implementation of a RegisterFile which uses virtual registers. In this case, registers are allocated on-the-fly and on function call they are saved.

on_function_call()¶: Callback for function call.

on_function_return()¶: Callback for function return.

param_regs_count = 1000¶

requires_register_allocation = False¶

Module contents¶

ScEpTIC.emulator.register_file.create_register_file(register_file_configuration)¶: Creates and returns the proper RegisterFile implementation, given the configuration.

ScEpTIC.emulator.register_file.validate_configuration(register_file_configuration)¶: Validates the register file configuration passed by the user. On error a ConfigurationException is raised.