First-generation Memory Disaggregation for Cloud Platforms @Arxiv

CXL disaggregation because:

  1. Memory inefficiency: s platform-level memory stranding
  2. Current cloud vendor try on memory disaggregation: require no modifications to
    customer workloads or the guest OS./ the system
    must be compatible with virtualization acceleration techniques/ the system must be available as
    commodity hardware.

Continue reading "First-generation Memory Disaggregation for Cloud Platforms @Arxiv"

FusionFS: Fusing I/O Operations using $CISC_{Ops}$ in Firmware File Systems

The paper is joined work between my upperclassman Jian Zhang who's currently taking Ph.D. at Rutgers.

Current Hw-Sw co-design

  • Hardware Trend
    • Design a fast path to reduce latency.
  • Software Trend
    • Do kernel bypass/zero-copy


FusionFS comes up with aggregated I/O ops into $CISC_{Ops}$, the fuses and offloads data ops are carried out on the co-processor on storage. These higher throughputs are gained with assurance to the resource management fairness, crash consistency, and fast recovery.

  • Kernel FS pushes all the W/R to the VFS Layer, this does not necessarily mean it's slow, often the time waiting for heavy-weighted Writeback, page cache is not hit, I/O queue locks waiting for the device ready, or deep VFS calls.

  • User FS may have some of the W/R intercepted and bypass the kernel. Some of the userspace semantic fusion is implemented using FUSE.

  • Device FS(Before CrossFS is Firmware FS) makes FS Lib directly call the firmware to wait until it can make DMA to memory.

    • Good for Disaggregation & Concurrency throughput
    • Mainly for NVM when speed is high, not applicable to SSDs
  • This paper used Compute Offloading, which is greatly applied in the SMartNIC. Storage plus the data processing makes transparent to the kernel, the kernel only needs to know some of the results is fused.

    • write fusion
    • read fusion
    • data replacement for locality
    • PolarDB - PCIe layer compute offloading. I think it could be replaced by CXL.
  1. crc-append interpreted into CISCops Basically, based on the predefined rules, the co-processor is able to fuse most of the data operations like LevelDB CRC, open read-write close.

  2. CFS I/O scheduling.

  3. Durability maintained by Micro Tx.


  1. Large sequential data read/write will introduce preprocessor overhead, at least for data calculation and buffer store. Can pattern matching and make bypass the data processing.

  2. This paper shared a lot of similar designs with CrossFS for resource management, durability, and Permission checks.

  3. I'm curious why not implement the SSD main controller? It's meaningless to write on NVM because programmers must do handmade I/O fusion on such devices.

  4. Performance is roughly the same with NOVA when with slow device CPU. I don't know if IO thread affinity and other kernel optimization are applied, the additional hardware has real benefits. However, the recovery speed is really quick because of MicroTx.


  1. Still could apply kernel bypass over the FusionFS.
  2. SSD main controller/ Memory controller implementation is better than adding another CPU.


  1. POLARDB Meets Computational Storage: Efficiently Support AnalyticalWorkloads in Cloud-Native Relational Database
  2. CrossFS: A Cross-layered Direct-Access File System

Lustre 文件系统使用

最近帮学长跑实验,同时也是毕业论文的实验,用的 Lustre。然后又重新读了一遍古老的PLFS、PMFS论文。同时用的是AMD超算集群,最多可以到512台node。

[scb5090@ln131%bscc-a6 ~]$ lfs quota -h -u scb5090 /public1
Disk quotas for usr scb5090 (uid 6171):
     Filesystem    used   quota   limit   grace   files   quota   limit   grace
       /public1  19.13G    450G    500G       -   50865       0       0       -
uid 6171 is using default file quota setting
[scb5090@ln131%bscc-a6 ~]$ lfs quota -h -u scb5090 /public2
lfs quota: cannot resolve path '/public2': No such file or directory (2)
[scb5090@ln131%bscc-a6 ~]$ lfs quota -h -u scb5090 /public3
Disk quotas for usr scb5090 (uid 6171):
     Filesystem    used   quota   limit   grace   files   quota   limit   grace
       /public3      0k      0k      0k       -       0       0       0       -
uid 6171 is using default block quota setting
uid 6171 is using default file quota setting


[Computer Architecture] Sniper Intro


The code is available at

The raw result is

admin@ubuntu_1604:~/sniper/test/lab0$ make
../../run-sniper -c ./config-lab0.cfg -- ./toy-lab0
[SNIPER] Warning: Unable to use physical addresses for shared memory simulation.
[SNIPER] Start
[SNIPER] --------------------------------------------------------------------------------
[SNIPER] Sniper using SIFT/trace-driven frontend
[SNIPER] Running full application in DETAILED mode
[SNIPER] --------------------------------------------------------------------------------
[SNIPER] Enabling performance models
[SNIPER] Setting instrumentation mode to DETAILED
[RECORD-TRACE] Using the Pin frontend (sift/recorder)
User program begins
<toy-lab0.c, clflush, 21> clflush to be run
[[email protected], iterate, 311] CLFLUSH instruction executed
<toy-lab0.c, clflush, 21> clflush to be run
[[email protected], iterate, 311] CLFLUSH instruction executed
<toy-lab0.c, clflush, 21> clflush to be run
[[email protected], iterate, 311] CLFLUSH instruction executed
<toy-lab0.c, clflush, 21> clflush to be run
[[email protected], iterate, 311] CLFLUSH instruction executed
User program ends
[TRACE:0] -- DONE --
[SNIPER] Disabling performance models
[SNIPER] Leaving ROI after 2.83 seconds
[SNIPER] Simulated 0.0M instructions, 0.1M cycles, 0.36 IPC
[SNIPER] Simulation speed 11.9 KIPS (11.9 KIPS / target core - 84229.9ns/instr)
[SNIPER] Setting instrumentation mode to FAST_FORWARD
[SNIPER] Elapsed time: 3.06 seconds

Optional: Run '../../tools/' in this directory to generate cpi-stack output for this run
Optional: Run '../../tools/' in this directory to generate power output for this run
Optional: Run '../../tools/' in this directory to view detailed statistics for this run
Optional: Run '../../tools/' in this directory to view the system topology for this run

The modified code is

      fprintf(stderr, "[[email protected], %s, %d] clflush to be run\n",  __func__, __LINE__);


The Sniper simulator allows one to perform timing simulations for both multi-program workloads and multi-threaded, shared-memory applications with 10s to 100+ cores. The maintainer is a researcher at NUS, Cambridge, Intel, and Ghent University.

Cache implementation

We have the cfg for the cache. So I consult their dispatch process in the source code.

# Configuration file for the Sniper simulator

# This file is organized into sections defined in [] brackets as in [section].
# Sections may be hierarchical withsub-sections split by the '/' character as
# in [section/sub_section].
# values can be "strings" , numbers, or true/false, existing values
# should indicate the type

# This section controls various high-level simulation parameters.
magic = false # Enable performance simulation straight away (false), or wait for Roi{Begin,End} magic instruction (true)
roi_script = false # Allow ROI to be set by a script, and ignore Roi{Begin,End} magic instructions
inst_mode_init = cache_only
inst_mode_roi = detailed
inst_mode_end = fast_forward
inst_mode_output = true
syntax = intel # Disassembly syntax (intel, att or xed)
issue_memops_at_functional = false # Issue memory operations to the memory hierarchy as they are executed functionally (Pin front-end only)
num_host_cores = 0 # Number of host cores to use (approximately). 0 = autodetect based on available cores and cpu mask. -1 = no limit (oversubscribe)
enable_signals = false
enable_smc_support = false # Support self-modifying code
enable_pinplay = false # Run with a pinball instead of an application (requires a Pin kit with PinPlay support)
enable_syscall_emulation = true # Emulate system calls, cpuid, rdtsc, etc. (disable when replaying Pinballs)
suppress_stdout = false # Suppress the application's output to stdout
suppress_stderr = false # Suppress the application's output to stderr

# Total number of cores in the simulation
total_cores = 64

enable_icache_modeling = false

# This section is used to fine-tune the logging information. The logging may
# be disabled for performance runs or enabled for debugging.
enabled = false
stack_trace = false
disabled_modules = ""
enabled_modules = ""
mutex_trace = false
pin_codecache_trace = false
circular_log = false

enabled = false
interval = 5000
filename = ""

scheme = barrier
report = false

quantum = 100                         # Synchronize after every quantum (ns)

# This section describes parameters for the core model
frequency = 1        # In GHz
type = oneipc        # Valid models are oneipc, interval, rob
logical_cpus = 1     # Number of SMT threads per core

#dispatch_width = 4
#window_size = 96
issue_contention = true
num_outstanding_loadstores = 8
memory_dependency_granularity = 8 # In bytes
lll_dependency_granularity = 64 # In bytes. Model the MSHR for overlapping misses by adding additional dependencies on long-latency loads using cache-line granularity
lll_cutoff = 30
issue_memops_at_dispatch = false # Issue memory operations to the cache hierarchy at dispatch (true) or at fetch (false)

# This section describes the number of cycles for
# various arithmetic instructions.

mispredict_penalty=14 # A guess based on Penryn pipeline depth

# Penalty of a page walk (in cycles)
penalty = 0
# Page walk is done by separate hardware in parallel to other core activity (true),
# or by the core itself using a serializing instruction (false, e.g. microcode or OS)
penalty_parallel = true

size = 0              # Number of I-TLB entries
associativity = 1     # I-TLB associativity

size = 0              # Number of D-TLB entries
associativity = 1     # D-TLB associativity

size = 0              # Number of second-level TLB entries
associativity = 1     # S-TLB associativity

perfect = false
passthrough = false
coherent = true
cache_block_size = 64
cache_size = 32 # in KB
associativity = 4
address_hash = mask
replacement_policy = lru
data_access_time = 3
tags_access_time = 1
perf_model_type = parallel
writeback_time = 0    # Extra time required to write back data to a higher cache level
dvfs_domain = core    # Clock domain: core or global
shared_cores = 1      # Number of cores sharing this cache
next_level_read_bandwidth = 0 # Read bandwidth to next-level cache, in bits/cycle, 0 = infinite
prefetcher = none

perfect = false
passthrough = false
cache_block_size = 64
cache_size = 32 # in KB
associativity = 4
address_hash = mask
replacement_policy = lru
data_access_time = 3
tags_access_time = 1
perf_model_type = parallel
writeback_time = 0    # Extra time required to write back data to a higher cache level
dvfs_domain = core    # Clock domain: core or global
shared_cores = 1      # Number of cores sharing this cache
outstanding_misses = 0
next_level_read_bandwidth = 0 # Read bandwidth to next-level cache, in bits/cycle, 0 = infinite
prefetcher = none

perfect = false
passthrough = false
cache_block_size = 64 # in bytes
cache_size = 512 # in KB
associativity = 8
address_hash = mask
replacement_policy = lru
data_access_time = 9
tags_access_time = 3  # This is just a guess for Penryn
perf_model_type = parallel
writeback_time = 0    # Extra time required to write back data to a higher cache level
dvfs_domain = core    # Clock domain: core or global
shared_cores = 1      # Number of cores sharing this cache
prefetcher = none     # Prefetcher type
next_level_read_bandwidth = 0 # Read bandwidth to next-level cache, in bits/cycle, 0 = infinite

perfect = false
passthrough = false

perfect = false
passthrough = false

evict_buffers = 8

model = oneipc        # Performance model during fast-forward (none, oneipc)

interval = 100000     # Barrier quantum in fast-forward, in ns
include_memory_latency = false # Increment time by memory latency
include_branch_misprediction = false # Increment time on branch misprediction

spin_loop_detection = false

num = 0

enabled = false
min_size_bits = 10
max_size_bits_local = 30
max_size_bits_global = 36

ins_per_core = 10000  # After how many instructions should each core increment the global HPI counter
ins_global = 1000000  # Aggregate number of instructions between HOOK_PERIODIC_INS callbacks

type = parametric_dram_directory_msi
variant = mesi                            # msi, mesi or mesif

total_entries = 16384
associativity = 16
max_hw_sharers = 64                       # number of sharers supported in hardware (ignored if directory_type = full_map)
directory_type = full_map                 # Supported (full_map, limited_no_broadcast, limitless)
home_lookup_param = 6                     # Granularity at which the directory is stripped across different cores
directory_cache_access_time = 10          # Tag directory lookup time (in cycles)
locations = dram                          # dram: at each DRAM controller, llc: at master cache locations, interleaved: every N cores (see below)
interleaving = 1                          # N when locations=interleaved

software_trap_penalty = 200               # number of cycles added to clock when trapping into software (pulled number from Chaiken papers, which explores 25-150 cycle penalties)

type = constant                           # DRAM performance model type: "constant" or a "normal" distribution
latency = 100                             # In nanoseconds
per_controller_bandwidth = 5              # In GB/s
num_controllers = -1                      # Total Bandwidth = per_controller_bandwidth * num_controllers
controllers_interleaving = 0              # If num_controllers == -1, place a DRAM controller every N cores
controller_positions = ""
direct_access = false                     # Access DRAM controller directly from last-level cache (only when there is a single LLC)

standard_deviation = 0                    # The standard deviation, in nanoseconds, of the normal distribution

enabled = false

enabled = true
type = history_list

enabled = false

reschedule_cost = 0 # In nanoseconds

# This describes the various models used for the different networks on the core
# Valid Networks :
# 1) magic
# 2) emesh_hop_counter, emesh_hop_by_hop
# 3) bus
memory_model_1 = emesh_hop_counter
system_model = magic
collect_traffic_matrix = false

link_bandwidth = 64 # In bits/cycles
hop_latency = 2

link_bandwidth = 64   # In bits/cycle
hop_latency = 2       # In cycles
concentration = 1     # Number of cores per network stop
dimensions = 2        # Dimensions (1 for line/ring, 2 for 2-D mesh/torus)
wrap_around = false   # Use wrap-around links (false for line/mesh, true for ring/torus)
size = ""             # ":"-separated list of size for each dimension, default = auto

enabled = true
type = history_list
enabled = false

ignore_local_traffic = true # Do not count traffic between core and directory on the same tile


moving_avg_enabled = true
moving_avg_window_size = 1024
moving_avg_type = arithmetic_mean

# Uses the analytical model (if enabled) to calculate delay if cannot be calculated using the history list
max_list_size = 100
analytical_model_enabled = true

window_size = 1000        # In ns. A few times the barrier quantum should be a good choice

type = simple
transition_latency = 0 # In nanoseconds

cores_per_socket = 1

sampling = 0 # Defines N to skip X samples with X uniformely distributed between 0..2*N, so on average 1/N samples

#base_address = 0 # Start address in hex (without 0x)
iter_start = 0
iter_count = 36

pthread_replace = false   # Emulate pthread_{mutex|cond|barrier} functions (false: user-space code is simulated, SYS_futex is emulated)
nprocs = 0                # Overwrite emulated get_nprocs() call (default: return simulated number of cores)
clock_replace = true      # Whether to replace gettimeofday() and friends to return simulated time rather than host wall time
time_start = 1337000000   # Simulator startup time ("time zero") for emulated gettimeofday()

enabled = false
address_randomization = false # Randomize upper address bits on a per-application basis to avoid cache set contention when running multiple copies of the same trace
stop_with_first_app = true    # Simulation ends when first application ends (else: when last application ends)
restart_apps = false          # When stop_with_first_app=false, whether to restart applications until the longest-running app completes for the first time
mirror_output = false
trace_prefix = ""             # Disable trace file prefixes (for trace and response fifos) by default
num_runs = 1                  # Add 1 for warmup, etc

type = pinned

quantum = 1000000         # Scheduler quantum (round-robin for active threads on each core), in nanoseconds
core_mask = 1             # Mask of cores on which threads can be scheduled (default: 1, all cores)
interleaving = 1          # Interleaving of round-robin initial assignment (e.g. 2 => 0,2,4,6,1,3,5,7)

quantum = 1000000         # Scheduler quantum (round-robin for active threads on each core), in nanoseconds
core_mask = 1             # Mask of cores on which threads can be scheduled (default: 1, all cores)

core_mask = 1             # Mask of cores on which threads can be scheduled (default: 1, all cores)

quantum = 1000000         # Scheduler quantum, in nanoseconds
debug = false

numscripts = 0

type = none
injector = none

type = none

type = none

enabled = false

Cache source code evaluation

Files related to cache in Sniper
config folder

gainestown.cfg contains the configuration of the L3 cache. The nesting contains the nehalem.cfg file

The nehalem.cfg file contains the configuration of L2 cache and L1 cache.

The default sniper argument is the gainestown.cfg file.

typedef int64_t SInt64;  
typedef int32_t SInt32;  
typedef int16_t SInt16;  
typedef int8_t  SInt8;  
typedef UInt8 Byte;  
typedef UInt8 Boolean;  
typedef uintptr_t IntPtr;  
extern UInt64 PC;  

\sniper\commoncore\memory_subsystem Contains the definition and specific implementation of the storage system in sniper.

  • parametric_dram_directory_msi\

Determine if the current access cache misses or hits, if it is a hit to access cache (including write back and read cache), if the cache misses, then insert cache.

CacheCntlr::processMemOpFromCore(Core::lock_signal_t lock_signal,  
Core::mem_op_t mem_op_type,IntPtr ca_address, UInt32 offset,  
Byte* data_buf, UInt32 data_length,bool modeled,bool count);  
/* Accepts a store access or a store write request, determines if the current cache access is hit or missing, and then calls a different processing function.  */  
SharedCacheBlockInfo* CacheCntlr::insertCacheBlock(IntPtr address,  
CacheState::cstate_t cstate, Byte* data_buf,  
core_id_t requester, ShmemPerfModel::Thread_t thread_num);  
/* This is called by the previous method when a cache misses. The main function is to find cache blocks to replace */  
void CacheCntlr::accessCache(  
Core::mem_op_t mem_op_type, IntPtr ca_address, UInt32 offset,  
Byte* data_buf, UInt32 data_length, bool update_replacement);  
/* The operation when the cache does not have a hit is also called by the processMemOpFromCore method. It consists of two main functions: read cache/write cache。 */  
  • cache\

Each actual cache is defined as an object by the Cache class, such as L1-icache, which contains the basic information about the cache, including size, type, connectivity, and some operations to get the information. The cache class also includes two methods to access and insert the cache: accessSingleLine and insertSingleLine, both of which are called from CacheCntlr.

/* cache attributes */  
// Cache counters  
UInt64 m_num_accesses;  
UInt64 m_num_hits;  
// Generic Cache Info  
cache_t m_cache_type;  
CacheSet** m_sets;  
CacheSetInfo* m_set_info;  
/* cache constructor */  
Cache(String name,String cfgname,core_id_t core_id,UInt32 num_sets,  
UInt32 associativity, UInt32 cache_block_size,  
String replacement_policy, cache_t cache_type,  
hash_t hash = CacheBase::HASH_MASK,  
FaultInjector *fault_injector = NULL,  
AddressHomeLookup *ahl = NULL);  
/* accessSingleLine: When a cache hit occurs, the Cache controller calls the accessCache method, which in turn calls this method in the cache class. This method reads and writes to the cache. */    
CacheBlockInfo* accessSingleLine(IntPtr addr,  
access_t access_type, Byte* buff, UInt32 bytes,  
SubsecondTime now, bool update_replacement);  
/* insertSingleLine: When cache misses, the Cache controller calls the insertCacheBlock method, where it further calls this method in the cache class.    */  
void insertSingleLine(IntPtr addr, Byte* fill_buff,  
bool* eviction, IntPtr* evict_addr,  
CacheBlockInfo* evict_block_info, Byte* evict_buff,  
SubsecondTime now, CacheCntlr *cntlr = NULL);  
  • .\cache\cache_base.h

The CacheBase class includes some basic information about the cache, such as connectivity, cache size, and also includes some type definitions, such as replacement policy. It also includes some type definitions, such as replacement policy, which needs to be changed if a replacement algorithm is added.

enum ReplacementPolicy  
};//replace the enum type
  • cache\cache_set.cc和cache_set.h

The cache substitution algorithm is a set of cache lines in a group, the number of cache lines is the degree of connectivity. The substitution algorithm selects an appropriate cacheline in the group to be replaced. Each group is defined as an object by the CacheSet class, which includes more basic operations on cache. accessSingleLine method calls the read_line and write_line methods, and insertCacheBlock calls the insert method.

/* cache hit, used for data reading */  
void read_line(UInt32 line_index, UInt32 offset, Byte *out_buff,  
UInt32 bytes, bool update_replacement);  
/*  cache hit, used for data writing back */  
void write_line(UInt32 line_index, UInt32 offset, Byte *in_buff,  
UInt32 bytes, bool update_replacement);  
/*  cache miss, apply the agorithm to replace item in the cache  */  
void insert(CacheBlockInfo* cache_block_info, Byte* fill_buff,  
bool* eviction, CacheBlockInfo* evict_block_info,  
Byte* evict_buff, CacheCntlr *cntlr = NULL);  

In addition to the access methods for cacheset, the following two methods need to be changed if you need to add your own replacement algorithm.

/* Create corresponding cache_set objects depending on the replacement algorithm. */  
CacheSet* CacheSet::createCacheSet(String cfgname, core_id_t  
core_id,String replacement_policy,  
CacheBase::cache_t cache_type,  
UInt32 associativity, UInt32 blocksize,  
CacheSetInfo* set_info);  
/* Create corresponding cachesetinfo objects according to the replacement algorithm. */  
CacheSetInfo* CacheSet::createCacheSetInfo(String name,  
String cfgname, core_id_t core_id,  
String replacement_policy, UInt32 associativity);  
/* Determine the type of the substitution algorithm according to the input string of the substitution algorithm. */  
CacheSet::parsePolicyType(String policy); 
  1. .\cache\

Each cacheline will have an object created by the class cacheBlockInfo to hold additional information about the cache line, such as tag bits, used bits, etc. If the addition of a replacement algorithm requires additional information, consider adding it in this place or in the previous layer of cacheset.

IntPtr m_tag;  
CacheState::cstate_t m_cstate;  
UInt64 m_owner;  
BitsUsedType m_used;  
UInt8 m_options;  
// large enough to hold a bitfield for all available option_t's  
  1. .\cache\cache_set_lru.cc和cache_set_lru.h

The lru algorithm that comes with sniper, whose base classes are both cacheset classes, implements the getReplacementIndex method and updateReplacementIndex method of the base class. The former is used to select the appropriate cache line to be replaced when looking for a replacement cache line, according to the algorithm that determines the replacement. The latter is used for the update operation that the replacement algorithm needs to perform when a certain cache line is accessed (read, write back, insert) (updating itself with additional information, such as the LRU access record).


clflush is often executed when a hacker is carrying out the spectre attack. Invalidates from every level of the cache hierarchy in the cache coherence domain the cache line that contains the linear address specified with the memory operand. If that cache line contains modified data at any level of the cache hierarchy, that data is written back to memory. The source operand is a byte memory location. The semantics is defined below:

flush Cache Line

Opcode / InstructionOp/En64-bit ModeCompat/Leg ModeDescription
NP 0F AE /7 CLFLUSH m8MValidValidFlushes cache line containing m8.

Instruction Operand Encoding

Op/EnOperand 1Operand 2Operand 3Operand 4
MModRM:r/m (w)NANANA

CLFLUSH operation is the same in non-64-bit modes and 64-bit modes.



Intel C/C++ Compiler Intrinsic Equivalents

void _mm_clflush(void const *p)

Protected Mode Exceptions

#GP(0)For an illegal memory operand effective address in the CS, DS, ES, FS or GS segments.
#SS(0)For an illegal address in the SS segment.
#PF(fault-code)For a page fault.
#UDIf CPUID.01H:EDX.CLFSH[bit 19] = 0.
If the LOCK prefix is used.

Real-Address Mode Exceptions

#GPIf any part of the operand lies outside the effective address space from 0 to FFFFH.
#UDIf CPUID.01H:EDX.CLFSH[bit 19] = 0.
If the LOCK prefix is used.

The Process of finding the execution point

It’s hard first to execute the code just with the static analysis. So it’s natural to utilize gdb just with option --gdb on for run_sniper. However, the sift requires the thread synchronization but gdb is hard to make all thread synchronized. So I gave up. First browsing the code, I found function void PerformanceModel::queueInstruction(DynamicInstruction *ins) which first padding the code into a queue and simulate them with the iterator.

void PerformanceModel::iterate()
   while (m_instruction_queue.size() > 0)
      // While the functional thread is waiting because of clock skew minimization, wait here as well
      DynamicInstruction *ins = m_instruction_queue.front();
      LOG_ASSERT_ERROR(!ins->instruction->isIdle(), "Idle instructions should not make it here!");
      if (!m_fastforward && m_enabled){
      delete ins;

The instruction is dispatched there. So I first printf("sb"); to test whether it can be interleaved inside the instruction. The result is yes, but so many sbs, around a thousand both even before the program begins and after the program shuts. My guess is that the emulator has the init.S for OS booting, and some C runtime loaded in the first place. And clflush should be selected from other syscalls.

So our problem converted to how to identify the 4 clflush from other syscalls. First, I did’t find the identifier as my code in the riscv simulator. Then, I found ins has a lot of identifiers:

class DynamicInstruction {
    // Private constructor: alloc() should be used
    DynamicInstruction(Instruction *ins, IntPtr _eip) {
        instruction = ins;
        eip = _eip;
        branch_info.is_branch = false;
        num_memory = 0;

    struct BranchInfo {
        bool is_branch;
        bool taken;
        IntPtr target;
    struct MemoryInfo {
        bool executed; // For CMOV: true if executed
        Operand::Direction dir;
        IntPtr addr;
        UInt32 size;
        UInt32 num_misses;
        SubsecondTime latency;
        HitWhere::where_t hit_where;
    static const UInt8 MAX_MEMORY = 2;
    Instruction *instruction;
    IntPtr eip; // Can be physical address, so different from instruction->getAddress() which is always virtual
    BranchInfo branch_info;
    UInt8 num_memory;
    MemoryInfo memory_info[MAX_MEMORY];

    static Allocator *createAllocator();


    static DynamicInstruction *alloc(Allocator *alloc, Instruction *ins, IntPtr eip) {
        void *ptr = alloc->alloc(sizeof(DynamicInstruction));
        DynamicInstruction *i = new(ptr) DynamicInstruction(ins, eip);
        return i;

    static void operator delete(void *ptr) { Allocator::dealloc(ptr); }

    SubsecondTime getCost(Core *core);

    bool isBranch() const { return branch_info.is_branch; }

    bool isMemory() const { return num_memory > 0; }

    void addMemory(bool e, SubsecondTime l, IntPtr a, UInt32 s, Operand::Direction dir, UInt32 num_misses,
                   HitWhere::where_t hit_where) {
        LOG_ASSERT_ERROR(num_memory < MAX_MEMORY, "Got more than MAX_MEMORY(%d) memory operands", MAX_MEMORY);
        memory_info[num_memory].dir = dir;
        memory_info[num_memory].executed = e;
        memory_info[num_memory].latency = l;
        memory_info[num_memory].addr = a;
        memory_info[num_memory].size = s;
        memory_info[num_memory].num_misses = num_misses;
        memory_info[num_memory].hit_where = hit_where;

    void addBranch(bool taken, IntPtr target) {
        branch_info.is_branch = true;
        branch_info.taken = taken; = target;

    SubsecondTime getBranchCost(Core *core, bool *p_is_mispredict = NULL);

    void accessMemory(Core *core);

We first found how Instruction size for identifier, but other than clflush, there’s other instructions of size of 9. Then we got meminfo, take meminfo->addr, but it’s changeable every run. Then we found something for identifier well, that is opcode, which unique to every ISA. Their code section is quite different.

[Computer architecture] Microcode Instruction, ISA


report gradescope


2 week 4 ques

Paper reading

one compulsory and one optional


Stack and accumulator

Stack vs. Accumulator(implicitly)
e.g. C \(\leftarrow\) A + B

Stack Accumulator GPR GPR
Push A Load A Load R1, A Load R1, A
Push B Add B Add R3, R1, B Load R2, B
Add Store C Store R3, C
Pop C

Stack: no register, but stack

  • Pros
    • Simple Model of expression evaluation (Reverse Polish Notation)
    • Short instruction, i.e., push, pop, etc.
  • Cons
    • Stackcan‘tberandomlyaccessed
    • Stack accessed every operation, to be a bottleneck
      Accumulator: one register, i.e., accumulator
  • Pros
    • Shortinstructions
  • Cons
    • Accumulator is only temporary storage, thus with high memory traffics.


  • CISC
    • Complex instruction set computer • Rep: x86
  • RISC
    • Reduced instruction set computer • Reps: RSIC-V, MIPS, SPARC
  • Main features of RISC, in contrast to CISC
    • A large number of registers and a highly regular instruction pipeline, allowing a low number of clock cycles per instruction (CPI) for high throughput
      • SPARC and RISC-V both with 32 general-purpose integer registers
      • X86, 8 general-purpose integer registers
    • Uniform instruction format
    • Load-store architecture
      • Only load and store instruction can access memory

Hardwired vs. Microcoded

  • Microcoded control (PLA)
    • Implemented using ROMs/RAMs
    • Indirect next_state function: “here’s how to compute next state”
    • Slower ... but can do complex instructions
    • Multi-cycle execution (of control)
  • Hardwired control
    • Implemented using logic (“hardwired” can’t re-program)
    • Direct next_state function: “here is the next state”
    • Faster ... for simple instructions (speed is function of complexity)
    • Single-cycle execution (of control)

Why Microcode

How RISC to CISC and then to RISC

Control vs. Datapath

control can be split between datapath, where numbers are stored and arithmetic operations computed and control, which sequences operations on datapath.

Single-Bus Datapath for Mircrocoded RISC-V

Microinstructions written as register transfers:

  • MA:=PC means RegSel=PC; RegW=0; RegEn=1; MALd=1
  • B:=Reg[rs2] means RegSel=rs2; RegW=0; RegEn=1; BLd=1
  • Reg[rd]:=A+B means ALUop=Add; ALUEn=1; RegSel=rd; RegW=1

Microcode Sketches

Instruction Fetch:

  • MA,A:=PC
  • PC:=A+4
  • wait for memory
  • IR:=Mem
  • dispatch on opcode

Pure Rom Implementation

  • Instruction fetch sequence 3 common steps
  • ~12 instruction groups
  • Each group takes ~5 steps (1 for dispatch)
  • Total steps 3+12*5 = 63, needs 6 bits for µPC
  • Opcode is 5 bits, ~18 control signals
  • Total size = \(2^{6+5+2}*(6+18)=2^{13}*24 = ~25KiB\)!

Reduce Control Store Size

  • Reduce ROM height (#address bits)
    • Use external logic to combine input signals
    • Reduce #states by grouping opcodes
  • Reduce ROM width (#data bits)
    • Restrict µPC encoding (next, dispatch, wait on memory, …)
    • Encode control signals (vertical µcoding, nanocoding)

Microcoded r Hardcoded -> Hardwired

Horizontal vs. Vertical µCode

  • Horizontal µcode has wider µinstructions
    • Multiple parallel operations per µinstruction
    • Fewer microcode steps per macroinstruction
    • Sparser encoding ⇒ more bits
  • Vertical µcode has narrower µinstructions
    • Typically a single datapath operation per µinstruction
      • separate µinstruction for branches
    • More microcode steps per macroinstruction
    • More compact ⇒ less bits but requires more capability of paralization
  • Nanocoding
    • Tries to combine best of horizontal and vertical µcode

WCS 可编程


buffer overflow 攻击 Return-Oriented-Programing

图灵完备 在这个系统中写程序能够找到解决方法(尽管不保证运行时和内存)

[Computer Architecture] superscalar

Greater Instruction-Level Parallelism (ILP)

  • Multiple issue “superscalar”
    • Replicate pipeline stages ⇒ multiple pipelines
    • Start multiple instructions per clock cycle – CPI < 1, so use Instructions Per Cycle (IPC)
    • E.g., 4GHz 4-way multiple-issue
      • 16 BIPS, peak CPI = 0.25, peak IPC = 4
    • But dependencies reduce this in practic
  • “Out-of-Order” execution
    • Reorder instructions dynamically in hardware to reduce impact of hazards
  • Hyper-threading

Pipelining recap




pipelines complexities exlained


  • More than one Functional Unit
  • Floating point execution!
    • Fadd & Fmul: fixed number of cycles; > 1
    • Fdiv: unknown number of cycles!
  • Memory access: on Cache miss unknown number of cycles
  • Issue: Assign instruction to functional unit




Some static multiple issues

VLIW: very long instruction word


The solution can be easily found




[ ] A. In-order processors have a CPI >=1

[x] B. more stages allow a higher clock frequency

[x] D. OoO pipleines need speculation

[ ] E. superscalar processor can execute