CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” 

Depth One DJ yep. Gonna listen to Lex's interview with the creator of clang next.

Me too. I haven't used C/C++ for 20 years. This makes me want to start using C++. Lex's interview with Bjarne Stroustrup (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uTxRF5ag27A.html) is very interesting and inspiring.

Here is the reference: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-uTxRF5ag27A.html

I was actually here before, but then I lost this talk and I found it again trough Lex's podcast

Bwuahahaha!!! ME~!

Yes, subtitles are essential for all the non English-native people, too, I cannot understand everything by just listening.

What misconceptions do people have that it is dispelling? That modern languages can't run on older hardware? Or is there something else you're referring to?

i have just directed 32 people to this video :)

About the captions, I've noticed CppCon generally tends to have humans writing them (which you can tell because whole chunks of sentences appear at once, rather than word-by-word). But nowadays RU-vid does have automatic CC generation that is actually fairly good! So what I think happened is the CppCon channel admins enabled human-written captions on this video, which removed automatic CC, but never actually wrote the captions.

Why don't YOU write the captions? Do you not care about your coworker?

I did not understand what he meant by overhead in this context. Can you explain?

@@marcusterrel1686 When you call a method, create an object or even call a function normally without optimizations you will have a lot of overhead (meaning added instruction in the assembly code). But the compiler is able to understand that you don't really need methods or objects in some case and remove them for you. The more known example to remove overhead is the inline keyword.

_Arghh the sarcasm's too bright!! I cannot see the point!! Where is it!!_

Actually, i think with this level of optimizations modern compilers bring to the table - Wolf3d "might" be possible. granted you need to set it to lowest res or even stretch lines twice.

Aw u propably mean Line Interlacing

it is possible, but it will run at 1 frame per year.

@@jomunoz ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Pa9cC6HcgrE.html Granted SuperCPU, but still on a C64. :)

Honestly, I'm not so sure about that. Don't forget that Jason is literally earning a living by knowing C++ inside out, so of course he knows all the cool tricks. But that's like watching Tony Hawk and deducing that skating is easy because you only need a few quick feet movements. Actually learning the language is getting harder and harder since all the cool new features (which are genuinely improvements!) are nonetheless based on the old systems. So now you need a good understanding of both and so on

@@TheMrKeksLp I think by easier, he meant for those who do know it inside out because they can use the language more thoroughly and not take extra time to write workarounds for things that should be built-in because they are built-in.

The optimizer isn't going to do as good a job when things get complex enough. If it's written well, it should still be faster than many languages, but don't expect to have more lines of C++ code than of assembly like happened here in several versions of the code that often.

haha indeed, I wanted to show this particular moment to a friend of mine and I found it thanks to your comment! thanks

C64 modern programmers are so much better than this (in terms of effciency) it hurts. Check any recent demo from Oxyron, for an example. This video of c++ on c64 is entertaining, but says nothing about optimization. HL programming languages on c64 are nothing new, there existed several alternatives in the 80s, and these were not used for commercial projects (with some exceptions). You could do little things like this Pong game, but not really compete with the asm games of the time.

There is a couple of things to note about this. First, the point of this wasn't to write an extremely efficient c64 game, it was basically to show that a lot of the "C++ is bloated and can't write for small devices" is really not true. Secondly, about the efficiency, all I can say is isn't that obvious? The binary output is from an x86 compiler and then translated to 6502. These are vastly different platforms so the compiler would optimise in different ways. If the compiler he used was specifically targeting the 6502, then it would be a lot more efficient, but as he stated right at the start, adding a target to a compiler toolchain is hard.

@Darran: You got it right. You can show this video to the people who says that C++ compilers are bloated or less efficient than C. Theoretically, there can't be a performance difference for the same logic in both languages. I guess we are reaching there in practice now. @Luis: I'd seen that demo. Astonishing! As Darran said generating efficient c64 code is not the point of the presentation.

After watching this talk to me it seems that it takes a lot of knowledge, discipline and verification of assembly get 0 overhead. Where in C it is 0 overhead by default, any overhead is explicit.

That is the problem with modern c++, too complex. But if you want top-notch abstractions, high level language features and manageable code without sacrificing performance then you don't have a choice.

Reducing compile time is a valid optimization

Overuse const? That should be default. I use "val" (#define val auto const) almost everywhere.

Answer: “Oh snap, sorry, you needed to change that at runtime?” Then, with an innocent, interested expression, let them dig themselves a hole.

Pong is ultra simplistic though, I wonder how well we can get 0 overhead with a more contemporary app

Haha, this is why i don't like C++. I found the final C++ version almost unreadable

C, not C++. Huge difference. Almost none of what's been shown by Jason in this talk is possible in C.

I believe it doesn't change anything for optimizations, it just changes the fact that you can not change its value. If you think about it, const or not it is going to be a local variable regardless. The case of a static array is different, because a static array could be updated at some point, and the program would have to read the new values.

Glad it was helpful!

For Java, you have the output byte code right there for viewing. You can also run a reverse compiler on it to see what the code looks like after compilation. There might be simplifications like fewer intermediary variables or entire chunks of code reordered. But Java isn't really known for the highest performance, which makes looking into making highly tuned Java code make less sense. When you write something in Java, you are already admitting it's all right if it's about 2-4 times slower than the fastest option, and you make that choice to have an easier language to use that you can make meaningful software with faster and hopefully with fewer bugs. Simply put, all the bells and whistles in C++ make it a harder language to use than most popular languages.

That confused me too. Some research suggests the address for the current scan line is $D012, so I imagine it was just an oversight/typo.

Source files: github.com/lefticus/presentations/tree/CppCon2016/RichCodeForTinyMachines/Source

A quick search is telling me between 1.2k and 1.8k bytes for the ZIPPED ROM. Assuming compression removes 25%, that means the handwritten games use between 1.6k and 2.4k bytes. So ~1.5k here seems to be one of the more compact variants of the game.

Had a look around, best I could find: Pong by "Tomi Malinen" was 2 blocks, 512 bytes. Its single player and black and white. Its the smallest I could find on some random website I've never seen www.gb64.com/.

since no one else has replied, the video chips actually "drew" outside of the viewable area on a screen (overscan), which meant that a frame actually took longer to display than it looked like, that is, if you had a slow motion camera aimed at the screen, there would be a delay from when it drew "the last line at the bottom" and when it started to draw the top line again (ignoring interlacing) - the code he wrote to do the updates only changes the position of everything on the screen when the video chip is currently in the overscan region (horizontal line 240). Every so often you'll see some video that's been copied from VHS or laserdisc or even DVD and converted without cropping, and it'll have weird garbage going on at the edges of modern monitors/tvs/screens, same reason, overscan - you can capture raster that is out of bounds with modern capture hardware, and unless you crop it in handbrake or ffmpeg or whatever, the artifacts will be there. Technology Connections (or connextras) has some info about how the overscan areas were used during the era of analog broadcast around the time that color televisions hit the scenes.

awesome!

FYI it's there now.

If something is const in C++ it has to be known at compile time, this involves both the "constness" of an object as well as "const storage". It can not be deduced at run time, it has to be known at compile time. By making it const it is initialized when compiled and the compiler optimizes away everything on the stack that fits into the registers.

@@skilz8098 this just isn't true, const just means that the value assigned it won't be modified afterwards.

@@jacobschmidt It is true sometimes depending on context.

I tried converting VIC_II::make_sprite() to a constructor VIC_II::Sprite::Sprite() of a struct with a 21-byte member, and using placement new, but also that generated machine code for initializing the 21-byte array. Any better ideas?

I think I found the answer. And it is of course 63 bytes (3 bytes per line, 21 lines). The objects have to be declared const in the global scope. If they are non-const, they would still be initialized at runtime. For the required 64-byte alignment, I used a GCC extension, which clang appears to support (I am seeing .p2align 6 in the assembler output). The declaration is like this: struct Sprite { uint8_t memory[63] __attribute__((aligned(64))); template Sprite(D ... d) {...} }; and the usage is like this: const VIC_II::Sprite ball(...); Note: clang would omit const objects from the output unless they are explicitly referenced. So, for testing purposes, I added fwrite() calls for dumping the sprite data to the main() function, before the infinite loop.

I submitted my solution at github.com/lefticus/x86-to-6502/pull/2

The std::array that we used initially was mutable so the compiler was generating code assuming that the std::array is mutable. It built the whole array at runtime by generating the Color structure and storing it into an array. Furthermore, when we indexed it to call the `nearest_value` function on the array member, the in-lined code was generated for it by indexing into the runtime built array. So code was being generated to construct, store and index into the array. But we are using it as a read-only structure so we can let the compiler optimize it further by marking the array as read only. When we changed it to a `const` array, the compiler was given a hint that the array is a read-only array instead. The compiler can use this info to build the array but it wouldn't have been different from the code generated for the mutable structure at that stage. But the compiler didn't stop there. It saw that we only indexed a single value from the array from our now read only array. So it went a step further and didn't even bother to build the array. It instead took the value directly and calculated the result of `nearest_value` at compile time and saved that instead. This step removed the code for generating our array, and also indexing into it to calculate the `nearest_value` value. It can do this for a read-only array since it can know that the values of the array won't change. It can just index it at compile time and use the value directly instead. But if we just used the mutable array, it can never be sure that a subsequent call won''t change the values of the array so it's instead forced to generate code to build the initial array, index the array and get the values at runtime which ends up generating a lot more code. tldr; it didn't even bother to build the read-only array and compiled the resulting value of the function directly instead. That's why the code ended up being small.

24:30 wait - template functions can return `auto`?

39:00 wait - you can declare structs within functions?

59:00 wait - you can do… you can do whatever the heck that is?

@@RoamingAdhocrat Some of these features were pretty. You couldn't do any of these things in C++ 20 years ago. But you can for some time now.

@@RoamingAdhocrat por supuesto, and for ((int) i=0 , i

There are ANSI C compilers for 6502 for ages, and a handful of games has been developed for the NES in C. No need in x86 to 6502 translator, and C++17 isn't something you would want on the NES anyway.

This video shows C++17 is something you want on a NES. Why would you want to code in C when the higher level stuff costs nothing?

no, because that didn't matter at all as you had to wait ages for any program to load from tape

Oh, right, or type in programs from magazines :)

no because my PC starts in like 4s and loads programs in under 1s

Oh, but when I first go my C64 I had to load and store software to a cassette tape - loading software from that was not a very quick process. (Later got a floppy drive but it was not particularly very fast either, but better than tape.) Cartridges were for games and game companies. Yeah, you could turn it on and get a near instant prompt to start twiddling in BASIC, but so what?

Oh good point, I had forgotten about that. You reminded me of the pains of the olden days.

Quite impressive talk, BTW

Stroustrup has said that he believes people overemphasize the exception situation as bad. Yes, exception-safe code has some extra instructions in the binary (quite a lot actually), but unless your program is constantly throwing exceptions, expect those code paths pretty much never to be used. You only have to obsess over removing exceptions if the size of your binary matters. The result should run plenty fast, just a tad slower.

cross compiler

A cross-compiler translates all x86 instructions to (usually) one or more 6502 instructions

You can use an equivalent "for"-with-initialiser expression.

Until you’re done. That will be awhile after C++ stops evolving, well after everyone has mastered all its features, or so they think. C++, for better and worse, is perhaps a modern replacement for COBOL but less portable between implementations by its very nature, by design. C++ templates are themselves Turing-complete, and people have used them to have the C++ compiler generate an answer by “running” the template program. It is these sharp edges that will cut you the most, as C++ has a focus on performance, close-to-the-metal, and that means a huge number of things are specified as “implementation left to the vendor” and non-portable.

All your life, most bloated language ever

probably not. CISC has more complex instructions and those are simple to break down. It is harder to rearrange incompatible RISC instructions.

What would be the difficulty in writing an assembler? They are quite straight forward imho. A compiler on the other hand..

It wasn't an emulator. He had an actual C64.

Yeah. For C64 you have KickAssembler which I think is the preferred way to program it these days, if you want the lowest overhead possible.

Nooo, the C64

@@luis46coco Or the VIC-II too chip to be more precise.

Even the most recent versions? They even changed the Visual Studio IDE to .NET for some reason.

Kayak Fan Only the GUI wich uses C#. Same for PowerPoint.

I think he's counting the sub-registers separately... so maybe counting AH, AL, and AX as three registers

x86_64 has like 40 registers, if you count SSE registers and the like. Lookup x86_64 register map.

they did it :)