Hacker News Reader

Comment by pjmlp | Hacker News Reader

Hopefully by then the languages whose reason for pointer tagging exists in first place, won't matter as much as they still do today.

View on HN

Given its longevity and installed base, I see no reasonable possibility of C/C++ going away or being significantly curtailed in the next half century.

C is 50 years old this year. And it's everywhere

It's more likely we'll be (or my kids will be) involved in harm reduction around these systems, rather than outright replacement.

Who knows, maybe we'll have a cheap (semi-)automatic rewrite from C to a memory-safe language by then.

Look to other industries. There are plenty of standard things that are suboptimal, but still used because they're so standard. For example, the English language has plenty of inefficiencies and inconsistencies that date back over 1000 years. But to fix them would be too much work for too little gain.

Cobol and Fortran are still around, they even support modules, some form of generics and OOP, yet you don't see many people jump of joy writing new libraries in them.

Whereas people still jump for joy at writing new libraries in C++ and it's coming up on 40 years old.

C++11 saved the language from dying off. Somehow it's my favourite language to work in (though mainly because nobody is paying me to work in Rust)

We are talking mostly about C here, but in any case, I don't jump of joy when looking at code that depends on SFINAE, ADL and CTAD.

Pointers are a core part of the CPU memory model on both ARM and x64, so they aren't going away anytime soon; there's no reason compilers, JITs or runtimes couldn't use pointer tagging, just the same as C programmers.

True, but the way they are exposed to the programmers matter.

Languages like Modula-2 or Ada, to use two C like languages, don't suffer from pointer abuse as much as C, because they provide better abstractions, thus raw pointer tricks aren't as dangerous to the whole system stability.

While JIT and runtimes could make use of tagging as well, Lisp and Ada machines kind of proved the point that with memory safe runtimes, the CPU specialy extensions aren't as useful as general purpose CPUs hence why they moved away from such solutions.

So there is a certain irony that we are now going back into C Machines as the ultimate mitigation.

Lisp and Ada machines happened to be very slow in practice. Turns out people prefer CPU extensions to make their C code fast rather than compiling it to a more exotic architecture.

I missed the point, Lisp and Ada machines were never designed to run C code, other than a curiosity.

Well, the two points I was making were 1. people want to run C code anyways, so that's not really an option for general-purpose use and 2. Lisp and Ada machines ended up being slow for Lisp and Ada, which makes them pretty unattractive.

I don't think C is going away any time soon, and even if it did, C reflects a common model of how hardware works that is shared by plenty of other higher level languages. Also GCs use pointer tagging.

The irony of C Machines.

You mean most languages that run on virtual machines today, right? Java, JavaScript, C#, Lua, …

LLVM, WASM,....

LLVM is as much a virtual machine as the "C Virtual Machine" from the spec is. To my knowledge there are no LLVM IR interpreters.

https://llvm.org/docs/tutorial/BuildingAJIT1.html

watchOS uses an Apple flavour of LLVM bitcode as executable format.

GraalVM also supports LLVM IR.

watchOS does not support executing LLVM IR, or runs normal ARM code with a somewhat tweaked ABI that’s generated from Bitcode.

Executable format does not mean it is executed directly, rather the format used for the executable files shipped into the store, which then does the AOT compilation for the specific version of watchOS.

Better now?

That is accurate, but not probably not the definition this thread was using for “executable”.

Reply on news.ycombinator.com