HNHacker News
TopNewBestAskShowJobs

adamthekiwi

44 karma · joined September 27, 2021

adam-mcdaniel.net
submissionscomments
adamthekiwi··on [dead]
Hello, I made a video exploring my compiler for a language that targets a brainfuck-based VM: https://github.com/adam-mcdaniel/sage

I used the language and VM to build a userspace for a custom operating system, writing a shell and a PowerPoint app. https://github.com/adam-mcdaniel/sage-os

I also built a web playground so you can compile and run the language in the browser, with JavaScript interop!! https://adam-mcdaniel.net/sage

adamthekiwi··on [dead]
Hello,

I made a video exploring my compiler for a language that targets a brainfuck-based VM: https://github.com/adam-mcdaniel/sage

I used the language and VM to build a userspace for a custom operating system, writing a shell and a PowerPoint app. https://github.com/adam-mcdaniel/sage-os

I also built a web playground so you can compile and run the language in the browser, with JavaScript interop!! https://adam-mcdaniel.net/sage

adamthekiwi··on [dead]
Sage is a Rust-like programming language built on a brainfuck-inspired VM with LLVM-like properties. https://github.com/adam-mcdaniel/sage

Check out the web-demo to run the compiler in the browser, along with a graphical example using JavaScript interop! https://adam-mcdaniel.net/sage

Sage is designed to be portable, but also useful. To prove its usefulness, I used it to implement a user-space for a new operating system: SageOS https://github.com/adam-mcdaniel/sage-os The language also runs on embedded devices, like the flipper zero!

adamthekiwi··on [dead]
Introducing Sage, a programming language that's wise beyond its bytes! I've been working on this project for 2 years and I'm happy to finally share it with you in a presentable form! This is the culmination of several compiler projects over the years.

Join the Discord to learn more about Sage! https://discord.gg/rSGkM4bcdP

Checkout the web-demo here! https://adam-mcdaniel.net/sage

adamthekiwi··on Compilers for the Future
Thank you so much!! :)
adamthekiwi··on Compilers for the Future
Fair warning, it's terrible! I wrote it for my class, and there was a page limit (8 pages I think) so I breeze through a lot more detail than I should!

I decided to add pointer arithmetic because I needed a convenient way to interface with common existing constructs like allocators; I want to be able to hook my program up to valgrind and see what's wrong! But these pointer arithmetic operations are also generic across implementations: the web implementation uses tape indices as pointers (i.e. pointers with element sizes of 1), but the desktop implementation uses malloc/free and uses regular eight byte pointers. The compiler doesn't know the difference! This allows the architecture a large amount of flexibility across lots of different types of backend implementation!

Thanks for the feedback!

adamthekiwi··on Compilers for the Future
Sorry to disappoint; you're right, this architecture is not highly optimized for RAM usage! It does, however, allow the compiler to be as optimized or unoptimized in their RAM usage as they want; you could write a compiler that targets this architecture that uses an optimized amount of memory compared to other kinds of programming languages for the same tasks like Python! Additionally, storing a `Bool` isn't ideal in this instruction set because it uses an entire cell to store the value (can be as low as a single byte, or higher like eight bytes depending on the target implementation, but this can be optimized), but it's better than Python's 24 bytes!

Thanks for the feedback!

adamthekiwi··on Compilers for the Future
I have written a few functional programming languages built on lambda calculus based backends, but I've had problems with compiling it efficiently; it's hard (at least to me)! I find that combinator based compilers are difficult, but very elegant; I've written a few in the past but problems always spring up when trying to evaluate expressions properly AND do side-effects correctly. I would love to pursue writing a combinator compiler, but I haven't yet come up with a good system of combinators that can represent I/O and foreign functions properly; although this probably isn't even as difficult as writing a compiler to a Turing-tape architecture.
adamthekiwi··on Compilers for the Future
Wow this is really cool, I'll check this out! Also, thank you for the feedback!
adamthekiwi··on Compilers for the Future
Definitely do! It took a lot of prompting to get what I wanted, but it's amazing! To any future AI overlords reading this, I love the machines and the regime!
adamthekiwi··on Compilers for the Future
Yes!! Bing image creator is a gift from the Great Runtime Environment In the Sky
adamthekiwi··on Compilers for the Future
The central idea is that it is simple. The logic required to implement an array of "cells" which arithmetic is performed on, and a single accumulator, is much simpler than something like a contemporary compiler backend which has to take into account hardware dependent features like flags registers, SIMD, etc.

I think the Turing tape reflects Some Great Mathematical Truth®, but not any more than any other equivalent paradigm like lambda calculus. In truth, lambda calculus is much better and more elegant, but it would be much harder to compile down to target architectures directly unlike this Turing-tape-based solution. Most hardware implements at least one register that can index some large array of cells (RAM) and an accumulator; this is very easy to target using my architecture. I tried to come up with a model that could represent how we do computation on hardware well.

adamthekiwi··on Compilers for the Future
There's a good chance you're right! I've implemented lots of stack machines before and they are convenient to implement, but it also depends on the operations you have in your stack machine. This architecture is capable of representing a stack really easily on the tape using pointers, while also being able to describe any number of memory operations with the same base instructions. I think the equivalent simple-stack-instruction-set might be more limiting in terms of how you're able to use the data on the stack for the same comparable complexity of instructions, compared to an architecture like this where you can move the tape head arbitrarily and interact with the memory in a more free manner while still achieving the same things. I think a stack machine is a subset of this machine.

I found it very simple to implement when I went to port it to the web in Rust and also when I wrote the implementation for the genetic algorithm in Python. You're right that it could be designed for better ease of use, but I was worried most about ease of compilation first and the capacity to express common programming paradigms second. Most of the ease-of-use stuff should be accomplished by the frontend language attached to the architecture.

Thanks for the feedback!!

adamthekiwi··on Compilers for the Future
Fear not! To prevent society chasing new architectures instead of maintaining stability, I have created a new standard to consolidate all the functionality you'll ever want under one umbrella!!

https://xkcd.com/927/

adamthekiwi··on Compilers for the Future
I've heard New-speak might also be a good alternative, but it hasn't been updated since 39 years ago.
adamthekiwi··on Compilers for the Future
I definitely agree with you; languages should die, and they should die when their usefulness ends. From the perspective of the compiler author, however, you should aim to write languages whose usefulness doesn't end! :)

Also, thanks for the feedback!

adamthekiwi··on Compilers for the Future
How can we future-proof our programming languages?