如果要让我列出名为“让我感觉Chisel比verilog/sv好用的特性”的一个列表的话，“最后赋值生效”（Last Assignment Wins）这个赋值原则肯定位列其中。这个玩意非常之好用，但是也会出问题，今天发现自己因此写了一个隐秘的bug，故总结一下。

在 Chisel 的思维模式中，:=其实应该看作是一种“提议连接”（Proposing a connection），而非verilog中

基础概念

• TLA+是一种基于集合论和时序逻辑的形式化规范语言
• TLC是一个专门为 TLA+ 设计的模型检测器（Model Checker），通过穷举法遍历系统所有可能的状态，验证这些状态是否符合 TLA+ 写下的规范。

基础语法

• 不等号是/=或#
• 逻辑是TRUE和FALSE
• 元组(Tuples)：<<"a",-3,"bc">>
  • 下标访问：<<"a",-3,

总述

Chisel封装了一个非常强大的Queue，同时还建立了一个非常好的抽象模型，了解使用这个玩意可以有助于我们理解很多种类的缓冲。

Queue(io.in, entries = 4, pipe = false, flow = false)

参数介绍如下：

• entries (Int)：队列的深度（容量）。
• pipe (Boolean)：默认为false，是否允许 valid 信号的组合逻辑穿

Scheme是一种Lisp方言，在Scheme中可以采用continuation来实现非常强大的程序流控制，而且代码异常简洁优雅，下面介绍并讲解一种有栈协程的实现。

先贴代码（改编自The Scheme Programming Language, 4th Edition p.64）：

(define lwp-list '())

(define lwp 
    (lambda (thunk)
 

译者按：这是一篇通俗易懂的Lisp入门小品文，原文刊于《科学美国人》，你可以在这里找到原文的副本，以下为此文的中文翻译（LLM+人工修正）

在80年代中期，当我翻阅室友收藏的一系列《科学美国人》旧刊时，我遇到了道格拉斯·霍夫斯塔特写的这篇介绍Lisp的文章。当时我觉得它非常迷人，并且在这里（稍微非法地）提供给新一代Lisper以启发他们。

为了证明了Lisp的永恒性，如果您安装了以下别名，您仍

理论

• 并行和串行：是否有执行次序
• 一个内核启动一个网格(grid)，一个网格由多个线程块(block)组成，同一线程块内包含多个线程(thread)，同一网格中共享相同的全局内存空间，同一线程块内的线程可以通过同步和共享内存实现协作，不同线程块内的线程不能协作。
• CPU是MIMD，而GPU是SIMT
• SM（流多处理器）相当于一个CPU核，但每次同时计算多个任务
• 任务执行：锁步思想lock-st

为了开发Steam VR平台上面的东西，不得不在Windows系统上使用Visual Studio进行开发。Visual Studio上面很多配置都是需要去层层菜单里面找，用鼠标去点UI来配置（除非你还想直接碰xml这种玩意儿），这对于习惯了Linux上使用代码，CLI等等配置环境的我来说，感到非常不适应，踩了很多坑，在此总结一下这种 ~~UI操作构建系统~~ 的要点。

下面具体的菜单操作都是以V

新基础类型

• 虽然随着C99加入了long long类型而且编译器很早便支持了这个类型,但是直到C++11才正式加入标准
• UTF-8是一种可变长度的编码方法,一般直接用char类型处理(C++20加入了char8_t以和普通字符区分). 而UTF-16和UTF-32编码则分别对应char16_t和char32_t.

命名空间

• 可以内联命名空间,inline namespace V2,利用此特

• Tour of Scala,中文版
• Scala Online Playground
• A Compact Benchmark in C++, Java, Go, and Scala from Google(PDF)

Basic

// Types
// Any is the supertype of all types, Nothing is the subtype of all types

/

Types

Data is the root of the Chisel type system.

UInt and SInt extend Bits

虽然chisel能够自动推断宽度,但是最好还是指定一下宽度(如4.W)

UInt ()
UInt (8.W)
3.U(4.W) // An 4-bit constant of 3

We will need Scala vars to write

又是一个没写多少代码，但是却花了半个晚上思考程序OOP结构的夜晚，我发现这是在浪费时间，而且会让你的大脑很累，感觉昏昏沉沉的．所以我痛定思痛，写下下面的一些感悟总结. 不一定对，而且随着时间变化，一些观点也会改变吧.

1. OOP不是必要: 当需要实例化多个相同类型的对象时，使用OOP来组织程序是很好的，但当整个程序中只存在一个实例(单例)的时候，面向对象设计得到的收益并不是很大．
2. C++不是必要:

介绍

之前一直用Valgrind这个工具来定位C/C++程序的各种内存问题，结果发现还有这个由Google开发的调试工具Sanitizers，提供更全面的报错和更好的性能（Valgrind会导致程序减慢大概20到50倍，而Sanitizers只会减慢大概2到4倍）

Sanitizers能够覆盖到如下这些Valgrind不能检测到的问题：

1. Out-of-bounds access in stack

在做练习44的时候，在维基百科上面看到了一种不需要取模运算，而是利用异或、与实现的环形缓冲队列，比较有意思。

一般来说环形队列的写法都会疯狂取模%，比如判断环形队列是否队满，会写类似这样的代码：

cb->size-1 == ((cb->end - cb->beg + cb->size) % cb->size)

但是，取模运算%比较耗时，特别是对于Linux kern