CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” on HackerTube: recommended by 13 Hacker News commenters across 10 separate months, 2016–2024.
talk · intermediate · evergreen
Jason Turner's CppCon 2016 talk builds a simple Commodore 64 game using C++17, showing how constexpr and const let a modern compiler produce tight 6502 code. He walks through assembly output to show abstractions being optimized away.
A perennial favorite, recommended as proof that expressive modern C++ can compile to efficient code even on tiny retro hardware.
“there is a wonderful talk by Jason Turner about writing a simple Pong clone for the Commodore 64 in modern C++”
20 Hacker News comments link this video. Each one links back to its thread.
Absolutely. There was a fantastic talk at CppCon last year, using C++17 to program a game for the Commodore 64. Using standard C++ idioms, the optimizer was easily able to make it compile down to efficient machine code. [1] ▶ this video
in “C++ on Embedded Systems” · View on HN
For those who haven't seen it, there is a wonderful talk by Jason Turner about writing a simple Pong clone for the Commodore 64 in modern C++: ▶ this video
in “Twenty years later I wrote a Tetris again” · View on HN
There's a great talk [1] in which C++17 features are used to build an efficient Pong clone on C64. As I recall, the author wound up writing an (obviously limited) x86-to-6502 translator to get around the lack of 6502 support. [1] ▶ this video
in “I learned to program a C64 in basic and compiled C (2020) [video]” · View on HN
Creativity flourishes with the right restrictions. In this case, the graphics and sound limitations. Also, just because you're targeting old platforms doesn't mean you need to use old platform's tools. Modern tools make it so much easier to develop on these old platforms, check out this talk about coding in C++17 for the Commodore 64 ▶ this video
in “8bitworkshop” · View on HN
> Nor does it have any concern for the elegance of its design. It has a lot of inelegant facilities, which, when used under the hood, allow you to express your elegant abstractions. > Hence the common practice of using a small subset C++ and pretending it's just C with Extras. That's mostly failure to use C++. Since C++11, and especially with later updates to the standard, idiomatic C++ is very different from C - even if you're not using a lot of the standard library. I'll link to a talk already linked-to in another comment in this discussion: Rich code for tiny computers / Jason Turner, CppCon 2016 ▶ this video
in “Common libraries and data structures for C” · View on HN
> I was hoping someone could prove this, actually. Maybe this presentation by Jason Turner from CppCon 2016 can illustrate just what can be done in C++17. His target in the presentation is a C64, but I think it illustrates well just what you can do with the language, and hence what tools are available for writing fast code. ▶ this video edit: If you just want a quick fix, check out what a simple keyword does here: ▶ this video
in “Comparison of C++17, Go, and Java for a next-generation sequencing tool” · View on HN
This talk proves this point exactly: ▶ this video Watch from 27:00 where he talks about using const wherever possible so the compiler can optimise. It reduces a full function call to work out a colour in 3D space from thousands of instructions to one. After watching this and a few others particularly dynamic dispatch in Swift, I find myself adding as many hints as I can and applying the most restrictions / scoping possible. Final, const, Private etc. [link] Even though actually it can work this out in your module!
in “I translated a simple C program to x86_64 and it was slower” · View on HN
> And once You think you’ve run hw to its limits there are plentiful demos and examples around to blow your mind watching what people have been able to do with these machines (often in obscure ways). What blew my mind was using a modern C++ compiler to build optimized software for that old hardware. Here's an example with the Commodore 64 [0]. [0]: ▶ this video
in “Getting started with bare-metal assembly” · View on HN
For the note: ChaiScript is from Jason Turner. He also does CPPCast ( [link] ) and is a regular presenter at CPPCon ( ▶ this video ). Many of his videos / tutorials are worth a look if you are interested in C++.
in “ChaiScript – Easy to Use Scripting for C++” · View on HN
Also highly recommended: Anything by Jason Turner and Ben Deane. Examples: - Ben Deane - Using Types Effectively [0] - Jason Turner - Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17 [1] - Ben Deane & Jason Turner - constexpr ALL the Things! [2] [0] [link] [1] ▶ this video [2] [link]
in “C++: Associative map containers with compile-time lookup” · View on HN
I think this way of looking at it old. Even if the const-ness is somehow subverted without generating an error then most compilers (or at least GCC and Clang) will presume the code is compliant and make optimizations following what the standard allows. This potentially results in undefined behavior when that pointer you mentioned is used to modified a thing that ought to be const. Consider the amount of optimizations seen in the video from CppCon 2016: ▶ this video Jason Turner, the presenter, is writing code a few lines at a time and cross compiling for the Commodore 64. He shows his assembly at many steps of the way and shows how many functions are completely elided when const (and later constexpr) are used correctly. There are a ton of other good talks from CppCon 2016 including one about const and what optimizations it makes possible and several about how compilers are more willing to "break" code that is non-compliant by making its behavior undefined. None of it really shocking or new, unless you have been writing to one compiler implementation instead of to the standard.
in “Add a const here, delete a const there” · View on HN
Your second link reminded me of [link] (which definitely builds on some of Matt's work). ▶ this video - C++17 for the Commodore 64. Probable language warnings for my other suggestions: * Rescuing Prince of Persia from the Sands of Time [link] (was this talk ever given elsewhere?) * And You Shall Know Me By My Trail of Documentation - [link] * The History and Evolution of Computer Viruses - [link]
in “Ask HN: What's your favorite tech talk?” · View on HN
Check out the cppcon 2016 presentation by Jason Turner and watch how eager the compiler optimizes away code when const is enabled on values. Cool presentation too, and uses Godbolt's tool ▶ this video
in “Epiphany-V: A 1024-core 64-bit RISC processor” · View on HN
"Template specialization means more generated code, which, again, must fit in 2kb." Have fun, "Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17" ▶ this video
in “Honey, I shrunk {fmt}: bringing binary size to 14k and ditching the C++ runtime” · View on HN
I have an ET-3400 on the shelf behind me! I was just playing with it the other day. After watching Jason Turner's CppCon talk on writing an i386 to 6502 assembly translator [1][2], I started working on a fork that would target the 6800. I only got about 3 instructions working, but that's really all you need for some really simple test code with optimization turned to the max. It also turns out that someone wrote a fantastic emulator specifically for the ET-3400 trainer [3], and I managed to get my application running on it! [1] ▶ this video [2] [link] [3] [link] There is something special to me about the idea of writing modern C++, and compiling it for such early microprocessors. The 512 bytes of RAM is a pretty big limitation though. I wanted to try and emulate an EEPROM using an Arduino or FPGA, but got stalled out on the project. From time to time I like to browse through the LLVM backend documentation, but I can't seem to commit to trying to build a backend.
in “Motorola 6800” · View on HN
C maps to the machine well. (Low-level programmers will probably crucify me for that.) But take its lack of closures as an example. Closures require either some kind of memory management, or clever program transformations, at which point you lose the simplicity of just having the stack and heap. As much as a generation of Java programmers (like myself) grew up thinking that C++ was old hat and Java was its natural successor, C++ has been quietly ahead of Java with regard to lambdas, generics, type-level trickery. Not to mention performance and backward-compatibility [1]. But reading C++ makes my eyes bleed. I much prefer FP for business logic and web-app development. Haskell is fast but it's no C++, and that's OK. I wouldn't want Haskell to take C/C++ market-share. I want it to compete against other languages that don't give me performance, safety or terseness. [1] C++17 on the Commodore 64: ▶ this video
in “What is the case against F#? (2009)” · View on HN
let's keep in mind that even though Torvalds said this from the kernel point-of-view, he agreed in porting his userspace app Subsurface from C with GTK to C++ with Qt. [link] Besides, there's really not much point in comparing, 1991 non-standardized "vector<bool> sounds like an awesome idea but first we have to find a compiler which implements inheritance properly" C++ with 2018 "you can compile template metaprogramming and constexpr stuff on commodore 64 and windows 10 and it works fine" ( ▶ this video )
in “I disagree with Linus Torvalds about C++ (2009)” · View on HN
I'd love to see this rewritten in C++ using that transpiler written for that talk at the last CppCon. ▶ this video
in “From PS4 to 1.44 MB Floppy: Porting Retro City Rampage to MS-DOS [video]” · View on HN
I'm having hard time deciding if this is a cleaner approach than converting subset of x86 asm to 6502 asm[0]. The reassembler seems like it has smaller surface area to worry, more rigid semantics, but then again it is very platform specific.. [0] ▶ this video
in “The LLVM+SDCC toolchain” · View on HN
Take a look at the useless features and bloat in this video. Modern C++ isn't what you think it is. ▶ this video
in “The cost of forsaking C” · View on HN