duangsuse::Echo
今天讲之前那个 x86 汇编的 helloworld 为什么出问题吧... 讲完再写不影响的,我已经基本会简单的 Qt 了... 就是我还看不到内存泄漏溢出、悬垂指针(Use-after-free)和非线程安全的风险
讲完再写个 ARMv7 glibc (arm_v7-unknown-linux-gnu) #llvm #sysadmin #recommended #binary #backend
(arch_subarch-vendor-os-abi-objectfmt) where
arch: CPU 解释器平台,如 ARM、x86、x86_64、SPARC
编译到原生代码的语言,诸如 C/C++ 需要程序员时刻考虑底层的实现细节,诸如硬件解释器平台
一般来说不同的硬件处理器((嵌入式)微控制器)平台有不同的 ISA(指令结构,Instruction Structure Architude)和解释器体系结构,与其他平台差异很大
所有代码被翻译成由 0(低电位)和 1(高电位)组成的,一定大小的二进制数字(如 0101、1111)组合成的一定长度的单元(必须是 2 的整数倍,一般最小为 8 位二进制数字)「字节序列」
然后被机器处理器按程序计数器(指令指针)进行取指令、解码逻辑分派、执行
就是说不同的平台之间有实现差异,举个例子来说,ARM 系列的 RISC(精简指令集系处理器)就只能使用
好吧我承认上一个例子是不好的,再举个例子,ARM 机器有
上面的看不懂没有关系... 因为这些知识还不是系统的,有太多涉及你们可能不知道的知识,而我也不写例子所以大概是一脸蒙蔽
因为我现在不是讲这个...
subarch: CPU 解释器子平台,如 ARMv7、ARMv8
举个例子,有些版本的 ARM 处理器(比如 ARMv6-M)有
所以 ARMv6 处理器就不能执行(或者不能很好的支持)有这些指令的 ARMv6-M 代码(指令序列)
ARMv6-M 程序员手册
ARMv7-M 程序员手册
我忽略了其他的一些平台差异,诸如字节序(大端/小端)、寄存器集合、浮点实现、子平台特性(诸如 AVX、SSE、NEON)等
vendor: 生产厂家类型,如 SUSE、PC、Apple、NVIDIA
不说了... 都知道,我们一般都是 PC 或者 unknown
os: 操作系统平台,如 Linux、OpenBSD、Win32
一般都是 win32 或者 Linux
这里有个容易混淆的地方是 win32 是一个平台,包括 32 位和 64 位 Windows,从 Windows 3.1(第一个使用 NT 内核的 Windows 版本开始)就叫 win32 了
Windows 的 64 位版本里 Win32 支持貌似叫 WOW64(Windows on Windows64)
abi: 程序二进制(底层运行环境)接口,如 GNU glibc、MSVC、Android、Musl
Musl 貌似是部分兼容 Glibc 的,一般用于嵌入式开发
Glibc 是很传统的 Unix-like 系统 C 语言基础库,老的闭源 libc 的替代者
MSVC,M$ VisualC (runtime?) msvcrt*.dll,类似 Glibc
ABI 是应用程序到操作系统交互的一栋桥梁。很少有人不使用 libc 开发应用程序,当然你用汇编
objectfmt: 对象文件格式,如 COFF、ELF、MachO
常用 ELF,Extesible Library Format,可扩展库格式,它也是基于 COFF,Linux 很早就给予其内建支持了
MachO 是苹果 Darwin(OS X(这个 X 是罗马数字 10,读 "ten"))用的可执行文件格式,妈的在我这里 Linux 环境里处理起来好麻烦啊
ABI 的吧... 虽然都是很简单的程序而已,连分支都没有用到
(arch_subarch-vendor-os-abi-objectfmt) where
arch: CPU 解释器平台,如 ARM、x86、x86_64、SPARC
编译到原生代码的语言,诸如 C/C++ 需要程序员时刻考虑底层的实现细节,诸如硬件解释器平台
一般来说不同的硬件处理器((嵌入式)微控制器)平台有不同的 ISA(指令结构,Instruction Structure Architude)和解释器体系结构,与其他平台差异很大
所有代码被翻译成由 0(低电位)和 1(高电位)组成的,一定大小的二进制数字(如 0101、1111)组合成的一定长度的单元(必须是 2 的整数倍,一般最小为 8 位二进制数字)「字节序列」
然后被机器处理器按程序计数器(指令指针)进行取指令、解码逻辑分派、执行
就是说不同的平台之间有实现差异,举个例子来说,ARM 系列的 RISC(精简指令集系处理器)就只能使用
load/store
指令访问内存,而 x86 系列的 CISC(传统的复杂指令系处理器)很大一部分指令都可以访问内存,典型的方式是使用 effective address(迫真?)(实际上,我还不记得 ARM 系列一般都有哪几种参数寻址方式)好吧我承认上一个例子是不好的,再举个例子,ARM 机器有
j
指令用于跳转(设置程序计数器来实现类似 Java goto
一样的功能),而 x86 里这是 jmp
指令,你看字面上都不一样所以他们是不能直接互相兼容的,换句话说就是「x86 机不能直接解释 ARM 的指令字节序列,而 ARM 也不能直接解释 x86 的指令字节序列」上面的看不懂没有关系... 因为这些知识还不是系统的,有太多涉及你们可能不知道的知识,而我也不写例子所以大概是一脸蒙蔽
因为我现在不是讲这个...
subarch: CPU 解释器子平台,如 ARMv7、ARMv8
举个例子,有些版本的 ARM 处理器(比如 ARMv6-M)有
DMB DSB ISB
这种(码位控制)指令,而有些没有(诸如 ARMv6)所以 ARMv6 处理器就不能执行(或者不能很好的支持)有这些指令的 ARMv6-M 代码(指令序列)
ARMv6-M 程序员手册
ARMv7-M 程序员手册
我忽略了其他的一些平台差异,诸如字节序(大端/小端)、寄存器集合、浮点实现、子平台特性(诸如 AVX、SSE、NEON)等
vendor: 生产厂家类型,如 SUSE、PC、Apple、NVIDIA
不说了... 都知道,我们一般都是 PC 或者 unknown
os: 操作系统平台,如 Linux、OpenBSD、Win32
一般都是 win32 或者 Linux
这里有个容易混淆的地方是 win32 是一个平台,包括 32 位和 64 位 Windows,从 Windows 3.1(第一个使用 NT 内核的 Windows 版本开始)就叫 win32 了
Windows 的 64 位版本里 Win32 支持貌似叫 WOW64(Windows on Windows64)
abi: 程序二进制(底层运行环境)接口,如 GNU glibc、MSVC、Android、Musl
Musl 貌似是部分兼容 Glibc 的,一般用于嵌入式开发
Glibc 是很传统的 Unix-like 系统 C 语言基础库,老的闭源 libc 的替代者
MSVC,M$ VisualC (runtime?) msvcrt*.dll,类似 Glibc
ABI 是应用程序到操作系统交互的一栋桥梁。很少有人不使用 libc 开发应用程序,当然你用汇编
syscall
手动调用内核函数并且自己写 ldscript(开发更底层的程序的时候可能用得到,比如链接内核、内核模组(模块)什么的)就算了objectfmt: 对象文件格式,如 COFF、ELF、MachO
常用 ELF,Extesible Library Format,可扩展库格式,它也是基于 COFF,Linux 很早就给予其内建支持了
MachO 是苹果 Darwin(OS X(这个 X 是罗马数字 10,读 "ten"))用的可执行文件格式,妈的在我这里 Linux 环境里处理起来好麻烦啊
ABI 的吧... 虽然都是很简单的程序而已,连分支都没有用到
GitHub
llvm/Triple.h at master · llvm-mirror/llvm
Project moved to: https://github.com/llvm/llvm-project - llvm/Triple.h at master · llvm-mirror/llvm
#ce #cplusplus #LLVM https://github.com/Mivik/rin/blob/main/blueprint.rin
Mivik 大佬又开了新坑……(突然发现好像自己并不是要学编译原理一样了😢) 有点像 Rust ,目前
编程风格和 kamet 差不多,手写分词/解析,不过更 C++ 化还用了atomics(jit.cpp),ast 和 gc 什么的没看,估计是智能指针
就语言设计看好像类型推导的少一些,支持 namespace,这个语言可能比 kamet 更正式
估计 mivik 大佬以后要走上自写语言打 OI 的不归路了(
Mivik 大佬又开了新坑……(突然发现好像自己并不是要学编译原理一样了😢) 有点像 Rust ,目前
编程风格和 kamet 差不多,手写分词/解析,不过更 C++ 化还用了atomics(jit.cpp),ast 和 gc 什么的没看,估计是智能指针
就语言设计看好像类型推导的少一些,支持 namespace,这个语言可能比 kamet 更正式
估计 mivik 大佬以后要走上自写语言打 OI 的不归路了(
GitHub
Mivik/rin
Contribute to Mivik/rin development by creating an account on GitHub.
#cplusplus #English #PLT #ce #parsing #llvm https://zhuyi.fan/post/write-a-bf-compiler-with-joy.html
🌝🌚 看来是 CS ,爱了爱了
https://raptazure.github.io/posts/purs-react/ #functional #JS #tt #English 草这又是个大佬... 类型论大佬都喜欢英语
#oi #school #life 这位同学亲切一点,好像还在学德语🤔
🌝🌚 看来是 CS ,爱了爱了
https://raptazure.github.io/posts/purs-react/ #functional #JS #tt #English 草这又是个大佬... 类型论大佬都喜欢英语
#oi #school #life 这位同学亲切一点,好像还在学德语🤔
zhuyi.fan
Write a BF Compiler with Joy
Post Write a BF Compiler with Joy of Personal Blog: Schrodinger's Utopia. Discuss about codegen, esolang, llvm, parser, peg, programming here!
duangsuse::Echo
关于这个我说点想法,就比如上图复杂的印花是以6边形旋转而成,在定义『矩形』和『正方形』getArea() 后我简单定义父类『龟』来在Graphics上绘制它,阐述类的封装和多态抽象性(area 正方形= sqrt(4w), 矩=s sqrt(ww+hh) ), 通过点1次 画N边形() 引入子程序调用和成员继承 ,在下节『列表处理』我会回顾这节的矩形:xy累加调用,getArea() ,顺便引入队列 从小到大 逐个绘制 环境配置是 VSCode redhat.java 。 教学目标是理解判断/重复流控、for和while…
https://github.com/libfirm/jFirm/blob/master/src/example/BrainFuck/BrainFuck.java#L152 看 MiniJava 时发现了一个MIR 编译框架,奇怪的知识增加了!
还有靠谱的以及不太靠谱的 #LLVM
考虑到 cheerpJ javafiddle.leaningtech.com 已经有 sun JavaCompier 的打包,考虑下搬运
还有靠谱的以及不太靠谱的 #LLVM
考虑到 cheerpJ javafiddle.leaningtech.com 已经有 sun JavaCompier 的打包,考虑下搬运
GitHub
jFirm/BrainFuck.java at master · libfirm/jFirm
Java Bindings for libFirm intended for compiler construction courses (focus is on ease of use) - jFirm/BrainFuck.java at master · libfirm/jFirm