With some help from bjorn3 this was reasonably straightforward. I think the PRs are good templates for of someone wanted to work on a real compiler and implement further SIMD functionality. This issue lists some missing intrinsics
This is interesting but not new. Max Bernstein published two blog post series on implementing Lisp, one on writing an interpreter in OCaml and the other on a compiler in C.
A little over a year ago, originally due to an interest in the deeper history of #compilers, I started diving deep into the #Talmud, studying #Aramaic, #gematria, and doing #DafYomi etc in what has become my deepest engagement with the rabbinic corpus yet -- the Talmud isn't a compiler but rather an extensible interpreter, compiled by compilers over the course of many centuries (build times have gotten significantly faster, my G-d), with novel extensions in the form of rabbinic commentary, glossia and the like being added nearly every century by publishers competing to compile the most elegant editions (Vilna Shaws being paradigmatic). And through studying Talmud and the greater body of rabbinic literature I've found myself encountering #magic/sorcery occasionally, and I just gotta say -- the #SICP metaphor of programming as pure magic, with the #hacker as a sorcerer, goes insanely deep when you start to dig into it.
I learned #FunctionalProgramming to escape the imperative programming languages, which in turn got me interested into #Compilers and #ProgrammingLanguages. Turns out, most of the real-world compilers are written in C and C++, so here I am back at square one.
After years of avoiding it for decades, I taught myself #Cpp in the last couple of weeks. So anyway, does anyone want me to write a series of #blog posts about making a #Lisp interpreter (https://github.com/kanaka/mal) in C++?
NMH BASIC (http://t3x.org/nmhbasic/) is a tiny BASIC interpreter for the 8086 that I wrote in the mid-1990's. It runs in 12K bytes and includes a minesweeper game that runs on a TTY. Of course a 12K interpreter was an anachronism in the 90's, but it still was a fun project. #retrocomputing, #basic, #compilers, #dos, #8086
I'm happy to welcome to Mastodon @AverageDog Nils Holm, author of "Write Your Own Retro Compiler" and other great books on compilers, programming languages, Lisp, and more.
Copy (assignment) semantics and/or requiring captured variables be constant/unchanged for function closures will cover 90% of use cases and make call stack management a brazilian times simpler for the compiler/runtime.
I found a great winter holidays reading. The book "Write Your Own Retro Compiler" by Nils Holm, which has just been published, describes the development of a self-hosting compiler that targets the Z80 on CP/M.
Phew, had me worried for a minute. I'm writing a simple XML 1.0 parser in #Rust just for practice, and on feeding it a 4.4MB XML file it took 56.5s to read it. I've done nothing to optimise it yet, but even so that sounded dire.
Then I remembered to use "release" mode, and the time dropped to 3.9s. Whatever the compiler is doing behind the scenes, I'll take that 14x speed boost, thank you.
"The thing is that maximal tree-shaking for languages with a thicker run-time has not been a huge priority. Consider Go: according to the #golang wiki, the most trivial program compiled to #WebAssembly from Go is 2 megabytes, and adding imports can make this go to 10 megabytes or more. Or look at Pyodide, the Python WebAssembly port: the REPL example downloads about 20 megabytes of data. These are fine sizes for technology demos or, in the limit, very rich applications, but they aren't winners for web development.
[...]
I work on the #Hoot#Scheme compiler, which targets #Wasm with GC. We manage to get down to 70 kB or so right now, in the minimal "main" compilation unit, and are aiming for lower; auxiliary compilation units that import run-time facilities (the current exception handler and so on) from the main module can be sub-kilobyte. Getting here has been tricky though, and I think it would be even trickier for #Python."
Either way, if you (or someone you know) would like to get started with #graphics programming, the #AMD Game Engineering team is excited to share their top tips with you 🌟
"A review of the state of the art in real time #graphics shading languages and #compilers in both graphics and compute. What are some of the differences between HLSL, GLSL, MSL, and WGSL?"
All credits to @daridrea for sharing this. Thank you! 😘
Disclaimer: I've no experience in graphics programming, but I find this field very fascinating and want to "dip my toes" into it. Thank you for sharing
More compiler debugging and I can now build a Z80 Fuzix kernel and user space that appear to work. Z80 code generation is based on the 8080 generator so the code is still fairly poor. Despite being able to run the compiler in 64K however the output is already often more compact, although much slower, than SDCC optimize for size. Still need to do more work on the linker for the relocatable user space, and then start trying to improve the code generation. #retrocomputing#z80#rc2014#compilers