xOS上节仿真系统顺利从 uart 截获数据并顺利打印出字符，这节依赖于此，我要设计 xOS。 目前的 xOS 只支持栈区，也就是说它不支持堆区内存的分配。 启动代码启动函数做 4 件事情： 设置栈指针 清零 BSS 段 跳到 main 从 main 返回（实际上没必要返回，因为 main 返回之前可以设置一个死循环） 因此，启动代码大致如下： 123456789101112131415161

基础工作type.h利用编译器内置的宏，可以精确的生成有无符号的 8、16、32等数据类型，这样就不用包含别人的库了： 123456789101112131415161718192021222324#ifndef __TYPES_H__#define __TYPES_H__typedef __INT8_TYPE__ int8_t;typedef __INT16_TYPE__ int16_t;typ

地址空间由于计算机软件系统是一个裸机系统，因此没有虚拟内存系统，都是直接访存，也就是说 tlb 其实是相当于不工作的。 只要在start.S 中直接修改 csr 标记 CSR.CRMD.DA = 1 (直接地址模式)、CSR.CRMD.PG = 0 (关闭分页)。 地址段划分如下： 1234567891011121314151617181920212223242526272829303132333

前言前置知识：“CSRWR 指令将通用寄存器 rd 中的旧值写入到指定 CSR 中，同时将指定CSR的旧值更新到通用寄存器 rd 中。“ LoongArch 的调用规则： 寄存器 别名 用途 $r4 a0 第 1 个参数 $r5 a1 第 2 个参数 $r6 a2 第 3 个参数 … … … 我在初始化 csr_eentry 的时候，打算将 trap_entry 这个函

前言在做课程设计的时候，有这样的一个代码片段： 123456789101112131415#ifndef MEMORY_HPP#define MEMORY_HPP#define MEM_SIZE (64 * 1024 * 1024) // 64MB memory#define MEM_BASE 0x00000000 // CPU reset PC: 0xffffff

前言biriscv 的 issue 单元一旦接受到错误的指令，将会把错误的信号，包括目标 pc 发射到前端，提示前端取这个 pc 对应的指令。 前端需要把这个 pc 发射给 icache 单元，返回数据后，将这个 pc 的预测信息 next_taken 和 pc、inst 对齐，一块儿发给 decode 单元，实际上这就是 fetch 单元在做的事情。 但是一旦 npc 做成了两个周期，为了适配

问题我今天从 github 下拉一个仓库的时候，突然报错： 12345Connection closed by 20.205.243.166 port 22fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists.

biriscv_fetchbiriscv_fetch 是 biRISC-V CPU 的取指单元，位于 ICache 和 Decode 阶段之间，负责： 管理 PC (Program Counter) 向 ICache 发起取指请求 缓冲 ICache 返回的指令 处理分支跳转请求 支持 MMU（可配置） 下面的分析是没有支持 MMU 的。 branch 处理123456789101112131

第一章 超标量处理器概述为什么需要超标量为了提高 IPC。 普通处理器流水线流水线概述流水线就是为了降低指令周期的时间，提高频率的手段。 流水线的划分一般根据场景，进行划分流水段，并且每一个阶段的延迟尽量相近。 指令间的相关性RAW：无法避免；WAR：可以避免，写到其它寄存器。WAW：同 WAR，也可以避免，写到其它寄存器。 控制相关：只能靠预测器预取，一旦预测错误，会带来严重的性能问题。 超标量

预测器的组合逻辑级联代码实现所有预测器的连接（config-mixins.scala:603-609）： 123456789101112// 初始输入（全0预测）val resp_in = (0.U).asTypeOf(new BranchPredictionBankResponse)// 组合逻辑链ubtb.io.resp_in(0) := resp_inbim.io.resp_in(0)