刚接触 AArch64 汇编的人往往会对编译器生成的一类代码感到困惑。

考虑下面这样一个简单的 C 函数：

extern int foo;

int *bar(void) {
    return &foo;
}

在开启 PIE（Position Independent Executable）后，不同架构的编译器通常会生成如下代码。

leaq foo(%rip), %rax

adrp    x0, foo
add     x0, x0, :lo12:foo

两种架构都采用了 PC-relative（PC 相对）寻址，即结合 PC 寄存器（x86-64 中的 %rip 或 AArch64 中的 pc）与预定义偏移量计算目标符号的最终地址。 但相比 x86-64 一条 LEA 指令即可完成地址计算，AArch64 却需要两条指令。这是为什么？

在 VSCode 中使用 CMake Tools 插件开发 C++ 时，如果选用 MSVC 编译器，可能会遇到编译信息乱码的问题：

warning C4267: 鈥滃弬鏁扳€�: 浠庘€渟ize_t鈥濊浆鎹㈠埌鈥淒WORD鈥濓紝鍙�鑳戒涪澶辨暟鎹�

乱码的产生通常是由于文本的创建者和解析者之间存在编码差异。在本例中，MSVC 的编译器 cl.exe 以 UTF-8 编码输出中文信息，却被 CMake Tools 以错误的 GBK 编码解析，进而导致乱码。

1.58 bit 量化技术通过将每个权值量化为仅有三个状态，最大程度地节约显存并加速推理。

Unsloth AI 在 Run DeepSeek R1 Dynamic 1.58-bit 一文介绍了 1.58 bit 动态量化版的 DeepSeek R1 671b（以下简称 unsloth 版）。我们知道 DeepSeek R1 70b 及以下的版本都是通过知识蒸馏得到的，唯有 671b 是满血的版本。然而原版 671b 的推理需要大量显存及算力，仅模型文件便有 404GB。

unsloth 版有选择地对部分权值作 1.58 bit 量化，将模型文件压缩至 131GB，同时也保持了不错的生成质量。结合 llama.cpp 实现的 CPU+GPU 混合推理，我们可在低成本的硬件上部署 671b 模型。

上回 我们讲了如何在跳板机背后的服务器上使用 VS Code Remote - Containers。DevContainer 中还有个棘手的问题是网络代理，本文将聊聊在 VS Code 中配置代理的问题，以及我目前的解决方案。

假设有如下网络拓扑：

其中 Server J 是跳板机，Server B 是目标服务器。现在需要让 VSCode 经由 Server J 连接到 Server B，并在 Server B 上使用 Remote - Containers 插件开启一个容器。

On developing sdxtra there comes a problem that is to calculate cohesive digests for numeric values, in a way agnostic to their types. This post discusses the problem and presents solutions in Go, though the ideas are applicable to other languages as well.

在本文开始前，我们先看一个奇怪的问题。以下两个函数，为什么 reborrow_good 能通过编译，而 deref_bad 不能？

fn reborrow_good(p: *const i32) {
    let _p = &raw const *p;
}

fn deref_bad(p: *const i32) {
    let _v = *p;
}

三号和她逛了美术馆。

此前她已经来过一次，说这里面有好些标榜着“现代艺术”的新奇玩意儿，一个人逛完感觉要长脑子了。美术馆外的景观更是一绝，隔江远眺，对岸高楼参差，繁华尽收眼底，只可惜当时天气不好，灰蒙蒙的。但现在秋高气爽，天空湛蓝而清澈，再没比这更适合出游了。

今天的故事源自数月前我在 r/learnpython 上回答的一个问题。以下是对该问题的转述：

将 64 位浮点数 1.0 不断除以 2，多少次后恰好变为 0？

x, i = 1.0, 0
while x:
    x /= 2.0
    i += 1
print(i)  # 1075

fn main() {
    let mut x = 1.0f64;
    let mut i = 0;
    while x != 0. {
        x /= 2.0;
        i += 1;
    }
    println!("{}", i);  // 1075
}

let x = 1,
  i = 0
while (x) {
  x /= 2
  i++
}
console.log(i) // 1075

古语云：“一尺之槌，日取其半，万世不竭”。但很显然，此话不适用于这个问题。浮点数的精度是有限的，当 x / 2 足够小时，浮点数终无法表示，便会得到结果 0。如以上代码所示，循环将终结在第 1075 次。

1075 次。这表明 64 位浮点能表示的最小数在 $2^{-1075}$ 这个量级，再小的数超出了表示范围，也就归于零了。但 1075 这个数很奇怪，它离 1024 很近，但又多出来一些，有零有整的，这是为什么呢？

本站此前是依托 Github Pages 搭建的，即静态文件托管于 Github 上，再将自定义域名 i.hsfzxjy.site CNAME 到 hsfzxjy.github.io。这种方案免费是免费，但国内的访问速度不甚良好，有几个省甚至出现了超时的现象。为了优化访问，本站现将静态文件迁移至 Cloudflare Pages 上，并使用 Cloudflare 的自选 IP 加速访问。