HN Theater @HNTheaterMonth

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] https://www.youtube.com/watch?v=zBkNBP00wJE [2] https://github.com/lefticus/6502-cpp [3] https://github.com/CalPlug/Heathkit_ET-3400

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.

> 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 https://www.youtube.com/watch?v=zBkNBP00wJE

⬐ huhtenberg

> That's mostly failure to use C++.

How is it a failure when people just find idiomatic C++ undesirable, exactly because it's very different from C.

Basically, the best C++ feature by a very long mile is that it can in fact be used as an extension of C. That's what made it popular in the first place and that's still "what people want".

If it's a failure, then it's that of the C++ committee evolving the language in an echo chamber.

⬐ _gabe_

> That's mostly failure to use C++.

Isn't this the no true Scotsman fallacy? It looks like you're agreeing with the parent poster that a lot of people use a small subset of C++ to pretend that it's C with extras. If this is true, it's not a failure of all these people because they don't _really_ understand C++. It's a failure of the language designers because they have made something that nobody can agree on how to use.

⬐ einpoklum

I should have used a different word. I meant "failure to do X" as in "not doing X", not as in "lack of success in the attempt to do X"

See the two meanings here:

https://dictionary.cambridge.org/dictionary/english/failure

You cannot also use stdio and most stdlib, so what?

You would want to use C++ for stronger type safety, proper enumerations, templates instead of undebuggable macros, namespaces,....

https://news.ycombinator.com/item?id=31406942

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

https://www.youtube.com/watch?v=zBkNBP00wJE

MCUs also don't support full-blown C, and it isn't a show stopper to keep advocating it, so why should it be for a language with better safety options, even with constraints.

⬐ scoutt

> You cannot also use stdio and most stdlib, so what?

You can still use a subset of stdio and stdlib. Newlib also provides hooks you can use to implement fopen and the like, if you want.

> better safety options

Safety is not always the utmost priority. At least, not that kind of safety. It seems people forget this concept from time to time.

> templates instead of undebuggable macros

This is if you use complex macros, which is not always the case. I've been doing embedded for 20 years and I rarely (very rarely) find problems with macros.

But you know what's undebuggable on embedded? Complex inheritance, which sooner or later you'll hit with OOP.

For a system in which you don't have a screen, or logs, or any kind of output, that is usually not in your table, and you have to study failures by telling someone to look at an LED, or by guessing what could have gone wrong, you have to keep your system simple.

Add templates to the mix and good luck opening the project six months later, when a customer calls with a problem.

Edit: But again, used with caution, C++ can be used in embedded, at least the way I use it, as explained before.

⬐ pjmlp

The same subsets are available in C++ as well, with stronger type checking and RAII for closing those handles.

Yeah, safety and IoT unfortunately aren't something that go together.

Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming.

The same reason you give for using macros.

⬐ scoutt

> RAII

C++ is used mostly with exceptions disabled on embedded, so failing constructors are a PITA. You have to keep track of valid states with a bool. Now every function entry has:

    if (!m_bValid)
        return;

I hate it.

> Yeah, safety and IoT unfortunately aren't something that go together.

Don't forget that IoT is just a minuscule fraction of embedded. Not everything is connected online or requires safety as top priority.

> Using C++ doesn't require OOP all over the place, nor crazy template metaprogramming.

So we agree. But I think you should be considering the possibility that there might be something going on between you and C, and that it could be possible that not every C developer out there is out of their mind (considering the quantity of past, present and future C projects).

Make peace with C, because the world runs on C and we'll be long gone by the time C will be replaced by something else :)

⬐ pjmlp

In the history of C++, RAII predates exceptions by several years.

When I got introduced to C++, via Turbo C++ 1.0 for MS-DOS in 1993, I decided that there was hardly a reason to use C other than being forced to use it by external reasons.

Thankfully there are plenty of places that have moved beyond running on C. :)

⬐ scoutt

> beyond running on C

Can we agree that for at least the past 25 years, 99% of devices runs on C and/or depends on C and/or relies on C, or its development ran/relied/depended on C? From Windows/MacOS/Linux kernels up to the FW in your mouse, keyboard, monitor and HDD controllers.

It's difficult to escape C :)

⬐ pjmlp

Using C compilers written in C++, yeah really difficult to escape C.

Windows has been migrating into C++ since Windows Vista, when VC++ introduced kernel support. Its C universal runtime is written in C++ with extern "C" entry points. Ah and then there is COM/WinRT, also mostly about C++ and .NET, even if the ABI is compatible with C (for masochists).

macOS uses C++ for drivers, a kernel without drivers isn't of much use.

Speaking of which, in Android all drivers written using Project Treble (required as of Android 8) are either C++ or Java based, and now Rust is also into the picture. The only C is the "classical" Linux upstream stuff.

⬐ OskarS

Yeah, checking return codes is a thing you NEVER have to do in C...

The "exceptions are evil, but without exceptions you can't fail a constructor!" is a really irritating canard when it comes to C++. First off all, the terribleness of exceptions is way overhyped, but even if you do want to avoid them, this is not a problem: just use a factory function instead of a constructor and return a `std::optional` (or a default-constructed value and an error code if you want to avoid `std::optional` for some weird reason).

I like pure C a lot and it definitely has a place in areas like embedded. But this kind reflexive disdain for C++ using uninformed arguments is really tiresome. C++ is fine.

⬐ scoutt

> the terribleness of exceptions is way overhyped

It's not that exceptions are terrible. I have nothing against them. The thing is that most of the time they are not affordable, especially in embedded. Some compilers don't even support them (some 8-bit IIRC). Most (including mine) embedded C++ programs have exceptions disabled.

> return a `std::optional`

The same goes for std. I don't know the overhead of possibly duplicating these classes(1) for every instance of std::optional. Most (including mine) embedded C++ programs don't use std.

30KB of extra code is nothing for desktop/server applications, but it's not convenient for a MCU with 64KB of flash.

(1): https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...

> just use a factory function instead

This is practical with an efficient heap allocator (which I might not have). What happens if I want a scoped (on stack) instance of a class?

See how things are quickly getting more complicated with C++?

⬐ OskarS

It's that amount of lines UNCOMPILED. Of course uncompiled code wouldn't fit in 64kb of flash (the compiler wouldn't fit either, you know). Compiled, std::optional takes up essentially no overhead, basically the same as if you're returning a single bool along with your object.

> This is practical with an efficient heap allocator (which I might not have). What happens if I want a scoped (on stack) instance of a class?

There is absolutely no reason to do a heap allocation for a factory function in modern C++ (or even relatively ancient C++, in fact). The fact that you would think so indicates you simply don't know C++ at all.

Tell me, where in these six lines do you see a heap allocation? Where in the total of 6 instructions this compiles down to do you see anything that couldn't run in any embedded environment? Tell me how these six instructions wouldn't fit inside your 64kb of flash:

https://godbolt.org/z/rErWPbbbx

And again, EVEN IF you're so religiously and irrationally opposed to using std::optional, you can just return a default-constructed object and an extra bool indicating successful construction. I don't know why you would considering you could just return an optional, but whatever, you can do it that way if that's what you prefer.

You're just wrong about this stuff, and it's this kind of lazy, uniformed criticism of C++ that really rubs me the wrong way. If you wanna use C, use C! Nobody's stopping you, it's a fine language. Just leave the C++ discussions to the people who actually know what the language is.

⬐ scoutt

Just chill, OskarS. I know the difference between compiled code and source code. Regarding std::optional, I even admitted "I don't know the overhead of possibly duplicating...".

30KB was a ballpark about exceptions plus std in general, by including things you expect to use when using std (like std::string).

The patterns I knew and saw with std::optional usually returned "new something", but yeah, you can return a copy too if the class fits in the stack.

And I am not religiously and irrationally opposed to anything.

> really rubs me the wrong way

Relax, my friend. Life is short.

⬐ OskarS

> The patterns I knew and saw with std::optional usually returned "new something", but yeah, you can return a copy too if the class fits in the stack.

Oh, fer crying out loud... It DOES NOT return a copy, it constructs it directly in place. This is called "copy elision" (also known as "return value optimization", or RVO), and has been done by compilers for three decades, and is actually mandated behaviour in modern C++. I don't know where you saw these examples, but you would never use operator new with std::optional: it takes a value, not a pointer.

You have a very annoying style of being wrong about absolutely everything you say, and then acting superior about it when people call you on your bullshit.

Somehow C64 can deal with them.

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

https://www.youtube.com/watch?v=zBkNBP00wJE

"C++20 For The Commodore 64"

https://www.youtube.com/watch?v=EIKAqcLxtT0

⬐ tialaramex

But a C64 is still only talking about 64kB of RAM. The post you're replying to claims that Template complexity gets unreasonable on a large machine, such as a Linux system. Not sure I agree, but "it's fine on a C64" isn't evidence in your favour unless you've forgotten Linux doesn't even run on a Commodore 64.

⬐ pjmlp

So it is fine on a 64KB system, but unmanageable on a platform that gets all the different kinds of boilerplate to run cloud workloads, got it

⬐ tialaramex

I mean, apparently this is confusing, but yes, obviously.

If your Commodore 64 template is dealing with say, foozles that might be 8-byte, 12-byte or 16-byte, the complexity incurred is pretty small, bugs with foozle<16> are likely to be something mere mortals can understand and fix.

On a more complicated system like a cloud Linux setup the template may be for foozles that can be in any colorspace and on a remote machine or locally, and now sometimes the bug with foozle<HSV,remove> involves a fifty line error message because the compiler doesn't realise all that happened is you meant to write foozle<HSV,remote> ...

It's not even as if the C++ committee isn't aware that templates are a problem. Remember template meta-programming wasn't really intended from the outset, and a big part of the point of Concepts was to at last let you write code that compilers can provide readable errors for when it's wrong.

⬐ pjmlp

The whole issue with Linux and C++ is political, there are other OSes that don't suffer from such issues and gladly accept templates.

https://developer.apple.com/documentation/driverkit

https://docs.microsoft.com/en-us/cpp/build/reference/kernel-...

https://fuchsia.dev/fuchsia-src/development/languages/c-cpp/...

https://genodians.org/nfeske/2019-01-22-conscious-c++

⬐ saagarjha

To be fair, DriverKit runs in userspace. IOKit, its spiritual predecessor, only allowed for the use of Embedded C++.

⬐ pjmlp

True, but that isn't the case for the other more modern examples.

Also IO Kit is no more, unless one is running an outdated macOS installation.

And talking about the past, maybe discussing about dynamic dispatch of Objective-C messsages on NeXTSTEP drivers with the previous Driver Kit, would also be quite interesting regarding "bloat".

⬐ saagarjha

IOKit remains the only way to write kernel extensions, which are still supported but discouraged if DriverKit does the job. NeXtTSTEP using Objective-C for drivers was certainly very cute but I guess they just didn’t want to have driver makers learn the language :(

⬐ pjmlp

> Devices supported on macOS 11 and later require DriverKit. Use IOKit in your apps and services to discover and use devices.

https://developer.apple.com/documentation/iokit

Going forward not for long.

⬐ tialaramex

I understand that for C++ programmers "That's possible" versus "That's a good idea" is a distinction without a difference, however for the rest of us the fact you can use templates as much as you like in, say, Windows drivers, does not magically mean it's a good idea to write complex templated code in Windows drivers.

The constraints in /kernel like forbidding exceptions are because otherwise they (Microsoft) need to do a bunch of extra work to support your bad idea. But your use of templates has no impact on their work, so knock yourself out adding as much complexity as you like this way.

⬐ kaba0

Why exactly? They are a compile time concept which only generates code for types where it is needed. That C devs instead copy-paste the same code 10s of times, use some shitty slow linked list, or the worst, use textual macros doesn’t make any of them a better tradeoff imo.

⬐ pjmlp

Here is another example, running C++ straight on car firmware free of Linux politics via AUTOSAR certification standard.

https://www.parasoft.com/blog/breaking-down-the-autosar-c14-...

But what do they state specifically? Ah, right.

> "The document allows in particular the usage of dynamic memory, exceptions, templates, inheritance and virtual functions."

https://www.autosar.org/fileadmin/user_upload/standards/adap...

⬐ tialaramex

It definitely feels like we're talking past each other. I keep telling you why people think it's a bad idea, and you keep showing that you're allowed to do it anyway. We know. That's the difference between impossible and a bad idea.

⬐ pjmlp

Nope, it is the difference regarding politics of what goes into the Linux kernel and the rest of the world, and it is quite clear to which side each of us belong.

⬐ stonemetal12

You keep saying it is a bad idea like it is a given. He keeps saying 5 bazillion programmers are quite successful with your "bad idea" so maybe it isn't so bad. Is there any evidence either way on the effects of templates on code quality?

⬐ flohofwoe

C++ or even C isn't exactly "fine" on any 8-bit system though. It's nice for a little demo, it can even be tolerable for some real-world projects when mixed with large amounts of inline assembly, but those 8-bit ISAs have been designed mainly for manual assembly coding, not high level compiled languages like C.

⬐ uuidgen

C translates directly to ASM in many cases. It just makes managing offsets and other stuff easier.

C++ adds type-safety on top of that for no cost. It's great when your compiler tells you that there is no operator =|(PORTD, PINA). Did you mean |=(PORTD,PIND) or =|(PORTA,PINA).

⬐ mananaysiempre

If you really want that in C, you can either use functions and wrap everything in (incompatible but internally identical) structs, or use Sparse and annotate those integer types to be incompatible. Not that you must prefer that to C++ (even if I do), just to note that you can make do with C if you want to.

⬐ flohofwoe

> C translates directly to ASM in many cases.

But usually much worse ASM than what a human would write on such CPUs, because the C compiler is still restricted by artificial high-level concepts like calling conventions, and it needs to wrestle with instruction sets that are not very compiler-friendly and tiny non-orthogonal register sets. C++ just adds a whole level of code obfuscation on top, so it's harder to tweak what code the compiler actually generates.

⬐ mananaysiempre

Honestly unless you’re on something like an ATtiny with < 1K of RAM or doing cycle-counted stuff a properly adapted high-level language is fine. I mean, Forth (doesn’t have to but usually) uses an interpreted virtual machine and people have used and liked it on 6502s since those were the new hotness.

As far as I’ve seen, two things make C and C++ specifically problematic on 8-bitters: automatic promotion to int for all expressions, with int required to be at least 16 bits (a language problem); and subpar codegen on accumulator architectures and other things that are not like desktops (a compiler problem).

⬐ flohofwoe

Forth is much better for creating tiny executables than C on 8-bit ISAs though, performance takes a hit because of all the calls/jmps, but it's still surprisingly good. C compilers on the other hand often create "obviously" dumb and inefficient code, at least in my experience (6502 may be better than Z80 in that regard though).

⬐ dgellow

I love these videos, Jason is doing fantastic work with his YouTube channel and C++ Weekly series.

⬐ pjmlp

Check his CppCon 2021 presentation, done on a C64 emulator thanks constexpr. :)

⬐ dgellow

Thanks, I will :)

Here, targeting Commodore 64 with C++17.

https://www.youtube.com/watch?v=zBkNBP00wJE

I was using Turbo Basic, Turbo Pascal, Turbo C++ (with C++ collections), and Clipper on MS-DOS, with 640 KB of memory.

It was just fine, then there are those that nowadays even toy with C++17 on C64.

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

https://www.youtube.com/watch?v=zBkNBP00wJE

Really, unless we are talking about PIC and AVRs with like 4KB, we are optimizing for the wrong target.

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: https://www.youtube.com/watch?v=zBkNBP00wJE

In case you never seen this, enjoy Jason Turner's “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” talk. :)

https://www.youtube.com/watch?v=zBkNBP00wJE

c'mon, you can run C++17 code on Commodore 64 (https://www.youtube.com/watch?v=zBkNBP00wJE) and MS-DOS (https://www.youtube.com/watch?v=yHrC_rZUaiA), what more do you want ?

> what can you tell it using C++ to the compiler optimizer? I'm not really a C++ guy so, really, do you have more options?

Yes, in several ways, including:

* Move semantics - you can make the compiler aware that some values are "going away" soon and can be cannibalized rather than conserved. * Compile-time execution - a significant (and growing) subset of the language can simply be computed at compile-time rather than run-time. So if you have a certain function which computes something - anything that doesn't involve I/O (and until C++20 - uses a fixed amount of memory), and your inputs are known in advance, the function won't have to run whenever you run the program, but would be removed entirely in favor of the result.

To see how these and other language features combine to allow for highly-efficient code, check out this video:

CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” https://www.youtube.com/watch?v=zBkNBP00wJE

Where you write an implementation of the Pong game - with high-level, straightforward code, and no "dirty tricks" - whose compilation result requires exactly 0 stack and 0 heap space.

⬐ burfog

Some of that capability is there only to overcome optimization problems that were created by C++ features. You don't need to make the compiler aware that some values are "going away" soon if that is clearly obvious. Without layer upon layer of object obfuscation, optimization is a much easier problem.

In C too, functions are removed entirely in favor of the results. This is a quality-of-implementation issue. There are good and bad compilers for most languages. C is less dependent on compiler quality however, with relatively simple compilers being able to produce good output for stylistically typical code.

This talk proves this point exactly:

https://youtu.be/zBkNBP00wJE

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.

https://developer.apple.com/swift/blog/?id=27

Even though actually it can work this out in your module!

> 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.

https://www.youtube.com/watch?v=zBkNBP00wJE

edit: If you just want a quick fix, check out what a simple keyword does here: https://youtu.be/zBkNBP00wJE?t=1616

> 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]: https://www.youtube.com/watch?v=zBkNBP00wJE

⬐ pjmlp

Anyone using Turbo C++ on MS-DOS already had that experience. :)

Hence why microcontrollers like ESP32 are much more poweful than many think of.

You mean like a Commodore 64?

https://youtu.be/zBkNBP00wJE

⬐ codesushi42

Yawn.

Yes. But even C was considered too slow for something like a Motorola 68000 back in the day. Of course it's possible.

Besides, C++ can be just as performant if you ignore a huge proportion of its language features and abstractions, but what's the point then? Just use C.

And this is precisely why embedded engineers do so.

⬐ pjmlp

The point is that C will never have proper arrays, strings, bounds checking, real constants instead of magic defines, compile time programming, modules.

⬐ codesushi42

Yet somehow it has stayed relevant for more than 45 years.

Go figure.

⬐ pjmlp

One cannot teach new tricks to old dogs.

What has made relevant was the rise of FOSS UNIX clones and the GNU guidelines for using C.

All major desktop OSes were already on the path of adopting C++ frameworks. BeOS, Windows, OS/2, Mac OS.

Thankfully C has been shown the door on Apple, Google, Microsoft, Sony, Nintendo and ARM platforms.

Others will follow.

FOSS UNIX clones and old time embedded developers are the only ones keeping C relevant.

⬐ codesushi42

Again, yawn. Now you are conflating embedded systems with other things. And resorting to ad hominem attacks assuming that all C programmers must be old, tired dummies. Pathetic.

Heard it all before, many times. C will be just fine whether you like it or not.

I also heard there's a new JavaScript framework out. Go fetch.

⬐ pjmlp

First of all, the only place worthy of JavaScript is the browser.

Secondly, apparently you are talking about PIC class systems as embedded, given that even a lonely ESP32 has C++ SDK support.

Thirdly, AUTOSAR now advises C++14 as certification language.

Do you read Embedded Magazine? Most C proud devs are using C89 alongside proprietary language extensions for their target boards + Assembly, and very resistant to any kind of improvements, not even using unit tests or static analysis tools.

Old dogs indeed, I bet that until 2030 the new C++ generations will take over the remaining holdouts.

⬐ nec4b

ESP32 SDK is written in C, but can be compiled with C++. All the libraries for the WiFi, BT, FreeRTOS,... are written in C. Are you one of those people who think everything before their time was bad and only what they do is worth something. I don't know why would you have such demeaning attitude towards people who laid the foundations on which we can build on. Is somebody forcing you to use C?

⬐ pjmlp

My time in computing started during the mid-80's, C had hardly any meaning outside UNIX clones, on our home computers running CP/M, AmigaDOS, MS-DOS, TOS, or other mainframe platforms like VAX/VMS, ClearPath, OS/400, z/OS,....

So those of my generation know that C being the very first systems programming language, the only way to write portable code across platforms in high level languages, is a kind of cargo cult from C devs.

Yes, I should have been more explicitly regarding ESP32's SDK. Point being that ESP-IDF Tools Installer supports C++.

⬐ nec4b

Since almost all of the operating systems you listed were written in different languages, some specifically designed for a single hardware, the believe of your peers at the time, that C was the only way to write portable code at that time was pretty much correct. This was one of the design features of C. C is also a small, relatively easy to write a compiler for language. That is also a reason why so many mcu manufacturers included a C compiler with their products instead of a C++ compiler, even though C++ is also an old language.

⬐ pjmlp

C is portable alright, as long as the underlying OS looks like UNIX.

Apparently you lack some knowledge of portability efforts done in other programming languages.

There is plenty of material available from old manuals, scanned papers and what not.

⬐ nec4b

C doesn't need an OS, and the OS doesn't need to look like UNIX at all if you're using one. We were originally talking about embedded systems and you since you mentioned ESP32 SDK, most of those libraries are portable to other MCUs and none of them has an OS or anything to do with UNIX.

"Apparently you lack some knowledge of portability efforts done in other programming languages.

There is plenty of material available from old manuals, scanned papers and what not."

Besides you mounting a personal attack here, I don't get you're point here. I have never said that there was no other portable language.

⬐ pjmlp

Any language doesn't need an OS, it just needs enough bare metal glue to run.

I thought C was portable everywhere, if we are conditioning it to specific libraries, then again other capability available to any programming language.

After all that ESP 32 SDK won't run without Windows wrappers. Any language can have OS specific wrappers, nothing special about C as well.

So now it is a personal attack to point out lack of knowledge?!?

⬐ nec4b

I'm happy that you now agree that C doesn't need an UNIX like environment to be portable. You haven't pointed out any lack of knowledge, you were just being rude. Again you are arguing with a straw man, I haven't claimed anywhere that C is special (there are other system languages), although it is true that not all languages are equal when it comes to bare metal.

For the note: ChaiScript is from Jason Turner. He also does CPPCast ( https://www.youtube.com/channel/UCuCjADS4u3uJDTqUaG0H9dA) and is a regular presenter at CPPCon ( https://www.youtube.com/watch?v=zBkNBP00wJE ).

Many of his videos / tutorials are worth a look if you are interested in C++.

That is a popular example, because it is a simple way to describe the difference between templates versus bare bones C coding.

And in some scenarios even a little 2x speedup does impact

With template specializations that speedup can be increased even further and since compiler does see template bodies, there are even more opportunities for the optimizer to do its work.

C++ can be used in something like a Commodore 64 just fine, in fact with smaller binaries thanks to constexpr all things.

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

https://www.youtube.com/watch?v=zBkNBP00wJE

Those architecture astronauts are able to benefit from abstractions and type safety, while still being able to target a C64 class computer.

https://youtu.be/zBkNBP00wJE

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.

https://liveblue.wordpress.com/2013/11/28/subsurface-switche...

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" (https://www.youtube.com/watch?v=zBkNBP00wJE)

⬐ Taniwha

exactly - it's that "system level" kernel point of view that's important - I write a lot of embedded/real time/kernel code and essentially the thing you have to avoid is "new" which is sort of the heart of the language ....

Why new? because you don't have a heap in the kernel, or practically on a system with 20k or ram, new is also bad in real time code because underneath it is malloc and (like printf/stdio) all the mutexes that protect code that is messing with the heap structure .... and that way lies priority inversions and heisenbugs and other dark beasties ...

(for a lot of real time code new is great at the beginning of time, but not on the fly while the world is running)

⬐ atilaneves

You can overload operator new to not use the heap. You can use allocators.

⬐ altmind

if you decide to use new/new[], you are bound to use the same allocator everywhere. c++ did not give you a chance to customize your allocation.

⬐ heavenlyblue

Overloading new (for the purpose, of e.g. adding a thread-local allocator) adds implicit global state that isn't always easy to manage.

⬐ martinlaz

Good memory management is never easy on a system level, so if one is overloading new, they'd better be comfortable around the complexities involved.

⬐ gpderetta

Sure, but no more than the standard allocator. Explicit allocator objects are a superior solution most of the time anyway.

⬐ amelius

Another potential problem is that "new" can throw an exception.

⬐ gpderetta

There are 4 options: 1) allocation can't fail for whatever reason. So new won't ever throw.

2) allocation can fail but you do not care to handle it. Your application will abort on an exception which is the best scenario.

3) allocation can fail and you want to handle it non locally (for example in a constructor). Exceptions work well in this scenario.

4) allocation can fail and you want to handle it locally: new(nothrow) is your friend. Remember to check for '!= nullptr'.

⬐ amelius

Exceptions require special stack-unwinding logic, which may not be adequate for a kernel (?)

⬐ gpderetta

Sure (although there is work ongoing to fix that), but that's only relevant for point 3 and in that case 4 is an option.

⬐ monocasa

In practice they don't on a lot systems. Last time I checked glibc baked in Linux's overcommit by default nonsense, just throws up it's hands and says 'malloc never fails'.

⬐ vbezhenar

That's not exactly correct. You can set ulimit and malloc will happily fail. And ulimit is pretty standard tool.

⬐ monocasa

ulimit on the resident set size hasn't worked since the Linux 2.4 days

⬐ zozbot123

> essentially the thing you have to avoid is "new" which is sort of the heart of the language ...

You can use placement-new syntax and ~Object() (direct call to the destructor), together with malloc/free, or any other memory-allocation primitive, just like in C. You don't have to use the inbuilt new operator.

Still, C++ should be considered a near-legacy language these days. Rust (even in its no_std subset) is progressing rather quickly.

⬐ monocasa

The Linux kernel absolutely does have a heap, most memory the kernel deals with is kmalloced.

As for small memory systems, even MISRA and the NASA guidelines say no memory allocation after initialization; having a bump pointer heap is very nice. Global operator new overrides are really nice in embedded systems too, I had one for the RTOS I worked on that let you specify memory region, alignment, etc and it worked by default for allocating any C++ object for free. Obvs you have to leave code behind that new's after initialization, or frees, but that's nothing new to small systems.

⬐ Taniwha

yes but it's explicit, you have call special kernel routines and manage the memory yourself, it's not hidden in some library somewhere causing 500 new/deletes outside of your knowledge .... I've certainly met programmers in the past who have not internalised that new/malloc are a couple of orders of magnitude more expensive than other language primitives like + .... and had to show them how to profile .... and discover that 90% of the time our large multithreaded app was spending was in malloc .... inside their bespoke strings package .... and that statically allocated strings on the stack and strncpy were perfectly good for 90% of what they were doing with strings and didn't spend any time at all time in low level heap mutexes

⬐ monocasa

I mean, the C standard library internally mallocs a bunch too, which is (one of many reasons) why the kernel has it's own modified version of a subset of the C library. If it were written in C++ the same rules would apply. When I was the lead for a C++14 RTOS that was MISRA compliant I had to write a custom collections library that's much more explicit. It's not that hard.

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] https://www.youtube.com/watch?v=ojZbFIQSdl8

[1] https://www.youtube.com/watch?v=zBkNBP00wJE

[2] https://www.youtube.com/watch?v=PJwd4JLYJJY

⬐ drej

Thanks! And just today, compile time regular expressions

https://www.youtube.com/watch?v=QM3W36COnE4

If we are speaking about something like a PIC with 8 KB I agree, for anything else comparable with a C64 or better, it is quite doable.

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

https://www.youtube.com/watch?v=zBkNBP00wJE

⬐ jstewartmobile

Turner obviously understands his tools, and exercised a lot of discipline with them to write pong within a resource budget.

The systems that I have encountered professionally have been uniformly more complicated, and written with less discipline, than Jason Turner's pong.

And that is not to say that the people who wrote the original programs were bad programmers. In business, you're trying to beat the other companies to the finish line, so a lot of siegeworks engineering happens out of necessity. Turner had the luxury of taking his time.

⬐ gumby

The point of a language like C++ is to build the abstractions that make it possible to quickly deploy something efficient and robust. Yes, that takes some time up front, but so does designing a board!

⬐ jstewartmobile

The abstractions are not free. The cost is negligible when working with megabytes. The cost is immense when working with kilobytes.

If you're doing something more complicated than toggling LEDs with one of these low-energy chips, C++ is a false economy--rapid progress in the beginning, and a slog of memory budgeting in the end.

⬐ tcbawo

It sounds like you have more of a problem with poorly written code than C++. The motto of C++ is to not pay for what you don't use. The rub is using abstractions doesn't absolve you of efficiency and design constraints.

⬐ gumby

Believe me I am used to programming machines with a KB of RAM, or even less, and small amounts of bank-switched program memory. I've been a compiler and RTOS developer, and have worked on telecom, avionics, automotive control, power generation, and instrumentation.

Certainly the abstractions can be free (at runtime -- may require the compiler to do hard work, but that's what it's for). A struct that allocates some of its instance variables into memory-mapped IO space and the other ones in regular ram can reduce errors that appear from splitting representations and/or doing explicit pointer arithmetic.

Can people write shitty code? Of course they can. Can you use your tools to reduce the chance that that will happen? Sure, sometimes.

Let's be realistic: while some of the very best programmers I've worked on have developed high-performance embedded systems, those are very few and far between. Most people writing embedded code have low status (this is the case in Japan and China in particular) so are often not the best developers, or are hardware engineers who figure writing some code isn't all that hard (isn't necessarily, but often leads to spaghetti) or are non-embedded programmers who figure "how hard can this be?" Another commenter's reference to hearing, "well it works when the optimizer is on" is a symptom of this.

Sure, people who fling around the STL on a small resource machine will rapidly suffer. But those people will fail regardless. I have built code that takes up less space with a C++ compiler than the C version.

⬐ jstewartmobile

Yes, yes. Since you are so experienced, and everyone else is "low status," riddle me this:

If C++ is so great, why does every joint turning out even halfway decent C++ have to subset the bejesus out of it? Even in game dev, where resources are plenty, they still subset it.

Could it be that maybe, maybe, someone discovered that even competent devs do better work when a few pieces of duct tape are stuck over the sharper, rustier edges of C++.

On low RAM devices, I'd subset it all the way down to plain C. Fellow low status developer Linus Torvalds would do that at the outset for any device.

⬐ pjmlp

Because many embedded developers are religiously against anything that isn't Assembly or a C89 dialect that only works in a specific CPU range, C99 and C11 are foreign words.

Language subsets is not unique to C++.

⬐ jstewartmobile

I would like a passport to that country with its strange and beautiful religion.

Where I'm at, C++ is the sugar sex magic that rights all wrongs and triumphs over evil.

edit: P.S., if I have a whole megabyte like Bjarne did in his AT&T days, I like C++ just fine.

⬐ pjmlp

You can ask Dan Saks about it.

CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”

https://www.youtube.com/watch?v=D7Sd8A6_fYU

Embedded Development with Dan Saks

https://cppcon.org/leveraging-modern-cpp-for-embedded-system...

When I started coding in C++ (Turbo C++), 640 KB were just fine, I could even make use of a full TUI framework (Turbo Vision).

Hence my point of view about PIC class processors with single digit KB, being eventually the only target not possible to use with C++, unless one wants to suffer a bit with linker scripts.

⬐ gumby

> If C++ is so great, why does every joint turning out even halfway decent C++ have to subset the bejesus out of it? Even in game dev, where resources are plenty, they still subset it.

I'm not sure what your point is. C++ is explicitly a multi-paradigm systems-programming language and any code base that used every feature would be unreadable.

The current project I am working on uses very few classes (where it does is mainly to drive computation into compile time rather than run time) and instead uses generic functions. I have seen other C++ code that uses classes and methods for basically everything -- I assume that house style works for them.

> Yes, yes. Since you are so experienced, and everyone else is "low status," riddle me this:

Have you ever worked in Japan, which is the case I explicitly called out? In most cases programming is what would be called in the US a "blue collar job". But even in the US, my experience as an embedded developer convinces me that embedded developers are typically not valued anywhere near as much as they deserve.

⬐ jstewartmobile

> I'm not sure what your point is.

In a scenario where templates, exceptions, and virtual functions are trouble waiting to happen, why even leave those temptations on the table?

> Have you ever worked in Japan, which is the case I explicitly called out?

Not asian--just think pulling the status and competence of foreign developers is kind of snobby and beside the point.

I like most of your comments, so trying not to be a dick about it. Last comment just rubbed me the wrong way is all.

⬐ captain_perl

I understand you're trying to be PC and all, but for the benefit of other readers, the grandparent poster was referring to the fact that lots of embedded development is done in Japan, but the software programmers are paid and respected less than "real engineers." That's just the well-documented culture there.

Yes it is possible.

Check this talk about fitting C++17 on a C64.

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

https://www.youtube.com/watch?v=zBkNBP00wJE

Also be aware that embedded devices like Arduino and Cortex-M (with Mbed OS) do use C++ toolchains.

Modern C++ compilers do pretty well on a Commodore 64, let alone many of the typical embedded deployments outside pico-controllers.

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

https://www.youtube.com/watch?v=zBkNBP00wJE

Most of the time is either religion against C++ or lack of modern tooling, given that most embedded toolchains are stuck with C90 and C++98.

⬐ abiox

> religion against C++

possibly. but given the how often i've seen c++ users treat c users like idiot savages or heathens that need conversion ("have you heard the good word of our lord and savior, c++?"), i could understand a negative sentiment.

⬐ pjmlp

Maybe if C developers wouldn't be ignoring Lint since 1979, and better type systems, we would be having better conversations.

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions."

Dennis M. Ritchie -- https://www.bell-labs.com/usr/dmr/www/chist.html

I would like the stack underlying my computing needs not to look like a Swiss cheese.

And yes, C++ is also not the ultimate solution for that as it is tainted by its C compatibility.

Modern C++ does just fine on a Commodore C64.

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

https://www.youtube.com/watch?v=zBkNBP00wJE

⬐ bb88

Sad that it took C++ almost 40 years to get there.

⬐ pjmlp

I was doing C++ development on MS-DOS already in the 90's.

Never cared for C beyond using it in Turbo C 2.0 for MS-DOS, and later when required to use it for university projects and client projects that explicitly required ANSI C89.

So it wasn't 64 KB, but it was perfectly usable on 640 KB systems.

The main problem has always been fighting misconceptions.

> to achieve our goal: C++ is too much OOP (runtime polymorphism)

That's not a correct statement anymore. There are a few examples of why this statment doesn't hold true but I think the biggest thing to point you to is this talk: https://www.youtube.com/watch?v=zBkNBP00wJE

With constexpr, const, and -O3 you're not going to beat C++ (or C) for any form of embeded-y systems development.

Also.... Phis are supported by OpenCL [0] [1] [2]. This lets you use a number of languages and libraries to better handle your computational tasks [3].

Why use Fortran, C++, or C when Haskell has Accelerate or when Python has ViennaCL [4].

Benifit from the computer science world's work. Don't write your own MPI code that you'll spend 4 months debugging when higher levels of abstraction exist for the problems you want to use. My best bet for you is: either use OpenCL's compute language which is very simple and allows you to do very complex operations completely in parallel on (cheap!) commodity hardware like GPUs for 4 years ago, or learn C++ just enough because the same things are doable using C++ and OpenCL libraries.

It's not too object oriented. Layers of abstraction don't slow code down if they are correctly developed. C++'s compilers and OpenCL have been correctly developed to give you frankly amazing performance for very high level features.

[0] - https://software.intel.com/en-us/iocl_tec_opg [1] - https://software.intel.com/en-us/blogs/2012/11/12/introducin... [2] - http://www.techenablement.com/portable-performance-opencl-in... [3] - http://www.iwocl.org/resources/opencl-libraries-and-toolkits... [4] - http://viennacl.sourceforge.net/

⬐ federchen13

>Benifit from the computer science world's work. (...) Sorry, isn't this a copy and paste from elsewhere? I'd bet I've seen this paragraph some time ago elsewhere.

Nevertheless, our task is not just to write codes that can be executed on the MIC. We must efficiently handle the large number of MIC cores on upcoming HPC systems. What makes the MIC so special is: (a) an increasing number of cores in the near future and, more importantly, (b) we can execute all our existing, highly optimized (vectorized) library codes (C, Fortran 77, IMSL, NAG, or whatever) on the MIC cores. With that we may face two different main approaches for using such many-core hardware: Firstly, we may use massively increasing amounts of data to make better predictions (Big Data, weather forecasting, ...). And secondly, we may use the many cores to develop and program new algorithms to process small data in new ways: With an increasing number of MIC cores, evaluations based on ‘exact values’, as opposed to approximations, will become much more attractive. (Don't take the term ‘exact values’ to literally, in most cases these values are based on approximations as well). That is an important option in those situations where approximations are not available (which is the case with the more sophisticated statistical methods). With today's Fortran, or with PGAS in general, we make a development (away from threading) towards merely (remote) data transfer (through PGAS memory). This allows to write the most sophisticated parallel codes with simple sequential syntax style and brings the amount of required codes for parallel computing to a minimum. Sounds good so far? But the situation is not quite that simple: The (remote) data transfer must be synchronized, i.e. you can only consume the remotely transferred data after some synchronization point. The problem is, if the programmer wants to use the MIC cores efficiently, she/he will need to use some of the cores for distinct purposes and thus, execute distinct parallel codes with different synchronization points on them. This will almost certainly break with what is called ‘ordered execution segments’ (Fortran terminology). ‘Ordered execution segments’ are a very severe limitation for parallel code execution (more precisely: remote data transfer) that is not based on a restrictive programming language but due to some extreme limitation of upcoming HPC hardware. With unordered (user-defined) segment ordering the programer loses nearly all the remote communication channels among the involved cores. Then, the only way left to transmit values remotely are the atomic data types: (binary or integer) scalar values only. Until recently, I had not much hope to circumvent the limitations of such user-defined segment ordering using atomics and thus, not much hope to make efficient use of the MIC cores with current Fortran. Yet, we can not offer professional style programming techniques, but instead some simple, rudimentary Fortran techniques and ‘tricks’ to overcome the limitations of atomics: https://github.com/MichaelSiehl/Atomic_Subroutines--How_the_... Anyone who complains or doubts about Fortran: Try this with your favorite parallel programming language or tool. cheers.

⬐ gravypod

GPUs already beat MICs in core count, performance, price per watt, and initial cost.

Why worry about writing specialized vectorized code? Just by using OpenCL your code will work like that. That's what OpenCL does. You give it chunks of data, you give it a kernel to run, then you run it on your data.

An extremely old AMD cards you can easily find 1280 "core" systems that can push GFLOPS of data through them.

OpenCL is the tool you should use for this. Not a hodge podge of messy fortran code that's been ""vectorized"".

Don't do the compiler's job.

⬐ federchen13

I think we are talking about different things. PGAS is intended to develop more sophisticated parallel LOGIC codes more easily, which is a requirement to handle upcomming MIC hardware. The logic codes itself will play a major role to make efficient use of such hardware and to develop new algorithms for upcomming hardware. I am not against OpenCL or anything else, but consider these as low-level parallelism. The MIC is just starting by now and is very distinct from GPUs. At this time, we are only preparing for the near future.

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] https://www.youtube.com/watch?v=zBkNBP00wJE

I'd love to see this rewritten in C++ using that transpiler written for that talk at the last CppCon.

https://www.youtube.com/watch?v=zBkNBP00wJE

⬐ mmastrac

I was trying to figure out which transpiler he was using, but I wasn't successful. I remember hearing about it on HN but can't remember the name!

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: https://www.youtube.com/watch?v=zBkNBP00wJE

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.

⬐ brucedawson

> None of it really shocking or new, unless you have been > writing to one compiler implementation instead of to > the standard.

I think you should focus more on giving concrete examples instead of making snide comments.

And, I'm not going to watch an eighty minute video in order to find out what you are talking about. Specific examples would be appreciated.

I agree that tagging globals as const can help the optimizer. If that is what you were talking about then I have no disagreement. However I have seen many people who expect speed wins when they tag member functions as const, or local variables as const. In those cases it is rare for 'const' to improve code-gen.

⬐ sqeaky

I was not attempting to be snide or rude. You are free to take the very concrete example I provided or not. You cannot say I didn't provide any.

The instant where the const keyword removes 95+% of the generated machine code is just after 28:00, but you should watch from at least a few minutes before that to establish context. That wasn't a global he put it on, but it wasn't a member variable either.

I recommend watching the whole talk, because the whole thing is pertinent to what optimizing can and cannot do. Because the speaker wants to get modern software onto an old machine he works around tight constraints while getting all of C++17. If you choose not to ignore something that you have expressed an interest in and is pertinent then you are doing something far worse than being rude and you are doing it to yourself.

Go benchmark you code, I have benchmarked mine. Putting const everywhere applicable helps even back in the pre-C++11 days. I state again not trusting and working with your optimizing compiler is simply an old an outmoded way of thinking.

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++:

https://www.youtube.com/watch?v=zBkNBP00wJE

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] https://www.youtube.com/watch?v=zBkNBP00wJE

⬐ None

None

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 https://www.youtube.com/watch?v=zBkNBP00wJE

If you're interested in modern C++...

https://www.youtube.com/watch?v=zBkNBP00wJE

Take a look at the useless features and bloat in this video. Modern C++ isn't what you think it is.

https://www.youtube.com/watch?v=zBkNBP00wJE

⬐ dreta

Could’ve easily written that in plain C. All the usage of C++ concepts like templates did, was made him write more code than necessary, and made the code harder to understand.

⬐ fredsanford

You're not worth the effort.

⬐ dreta

If i’m missing something obvious, please explain to me how using any of the C++ concepts made the code any better.

You have to keep in mind that this is a very simple piece of software. I wager you that using things like templates made the code unnecessarily harder to understand. I’ll also wager that by using templates he made the code harder to scale, since any remotely complex template, just like an overused base class, eventually becomes a set of special cases, or a set of specialised templates which defeats their purpose in the first place, and makes your code a nightmare to step through.

This is a typical example presented in a talk. It doesn’t reflect any large real-world software, where complex language solutions (useful ones, not the ones in C++) could actually benefit the programmer.

⬐ marchelzo

I agree completely. I couldn't believe it when he made that Frame struct and completely abused RAII just to execute some code at the beginning and end of a block. The only really big wins were the wrappers for writing to different memory locations, all of which could have been implemented in C using macros or inline functions.

⬐ inDigiNeous

That's a great talk that really shows that with modern C++ you can do some really nice optimizations and code minimizations, but it seems to require a discipline that can require a lot of thinking in the complex world of C++, to find those methods that for example Jason is talking about here.

Was pretty eye opening video to see that, that some of those complex looking instructions with a modern optimizing compiler can be surprisingly neatly optimized away.

⬐ fredsanford

I think discipline is a keyword here. It feels to me like being a professional means a fair amount of discipline should be required. Unless you're the nephew's uncle in law of the founders sister that knows VB and is "pretty good with compooturz" or the like.

Your second link reminded me of https://www.youtube.com/watch?v=nLv_INgaLq8 (which definitely builds on some of Matt's work).

https://www.youtube.com/watch?v=zBkNBP00wJE - C++17 for the Commodore 64.

Probable language warnings for my other suggestions:

* Rescuing Prince of Persia from the Sands of Time https://www.youtube.com/watch?v=FnEWBtCnFs8 (was this talk ever given elsewhere?)

* And You Shall Know Me By My Trail of Documentation - https://www.youtube.com/watch?v=fEgHdHdUDaA

* The History and Evolution of Computer Viruses - https://www.youtube.com/watch?v=s2g9lgYrYJM