Hacker News Reader

Comment by mschuster91 | Hacker News Reader

One thing that has always interested me, how is backwards compatibility done for older CPU instruction set?

Like the new VFMADD* instructions. So if I wanted to write a binary which supports post-2013 CPUs as well as previous ones, my way of doing this would be:

1) have a huge array of function pointers for every function that could use said instructions

2) in main() check if the CPU supports the instructions, if yes: populate array with fast functions, if not, populate with backwards-compatible functions.

Naturally this comes with a performance hit at every call as at least one (or two, if you fill the arrays at compiletime, and in main just switch the array pointer) indirections. Is this really how stuff gets done?

View on HN

If you're using shared libraries in your program, you already have this extra indirection - at compilation/link time the compiler/linker doesn't know where in memory the shared library will be when the program is run, so every call into a library goes through the procedure linkage table (PLT), which works by looking up the 'real' function pointer in the global offset table (GOT).

So yea, populating this at runtime depending on the CPU features supported by your CPU is possible, and the linux dynamic linker does this: http://man7.org/linux/man-pages/man8/ld.so.8.html (check out the section on hardware capabilities).

for an example, checkout this: http://pasky.or.cz/dev/glibc/ifunc.c

Two implementations are compiled (one is optimized using instructions only available on certain processors), and the decision of which one to use is made at program startup.

We should bring this point out next time there's a wave of comments saying that static linking is the one true way.

If you need to redirect all your function calls through a giant array, you can technically do that with static linking too. Just sayin'...

I think the best way would be to patch all the call instructions via something like a relocation table, depending on the results of the check.

Nearly impossible to do in a high-level language, but it's the way an Asm programmer would probably think of doing it.

As far as I know you can do stuff like dynamic linking the right libraries as needed, or use different code paths / function points / virtual functions for those instructions.

Linux on ARM used to have an ABI called OABI which would assume the CPU had FPU support, in case it didn't the kernel would catch the exception, perform the FPU operation in the kernel and return the result back to the program. This ended up being incredible slow however, with performance penalties for hardfpu machines as well. The new ABI (EABI) requires that the binary be built either for soft or hard float, which no longer requires the kernel to get involved.

What you describe is exactly what's done by most software. In fact, there are often several versions of each function, for each variety of CPU instructions supported. Take a look at x264 or libvpx for an example.

You can do dynamic linking at runtime so the indirections use direct immediate jump instructions.

Reply on news.ycombinator.com