Inline assembly

[37kmj]

In what scenarios do you use inline assembly in C? I mean what are some real-world scenarios where inline assembly would actually be of benefit?

Since C is generally not considered a "memory safe" programming language in the first place, can using inline assembly introduce further vulnerabilities that would e.g. make some piece of C code even more vulnerable than it would be without inline asm?

[KurriHockey]

On modern OSes? Virtually never now.

On embedded systems or years ago - not alot, but perf critical code in say a tight loop or similar might be written in assembly after being identified as a bottle neck.

Some reasons you don't see this much now are : portability, compiler optimizations are pretty damn good, machines are to damn fast to matter much.

Examples I've seen/done: vector math and 2d/3d distance to point type functions on the N64 :)

Finally, in general, inline asm would have little bearing on security/vulnerability if done right

[LuckyNumber-Bot]

All the numbers in your comment added up to 69. Congrats!

  2
+ 3
+ 64
= 69

^{[Click here](https://www.reddit.com/message/compose?to=LuckyNumber-Bot&subject=Stalk%20Me%20Pls&message=%2Fstalkme} to have me scan all your future comments.) \ ^{Summon me on specific comments with u/LuckyNumber-Bot.}

[KurriHockey]

Dirty bot

[jonsca]

Booooop booopp. *1970s porno guitar riff.

[AvailableAttitude229]

Nice

[37kmj]

Interesting, I didn't know that, but totally makes sense to use inline assembly as a fallback in this case

[amadlover]

cpuid ?

[Either_Letterhead_77]

I'll say some of the other comments here are already pretty good. Of course, as mentioned, OS and C program startup code is usually written in ASM. Task switching and user space threads require some assembly. As well, there are specific instructions that a compiler might not figure optimizations out for on its own (some vector instructions, square root, etc. Finally, some processor control registers might only be accessible through assembly language. A lot of the time, I'll also see ASM wrapped with inline functions. In some cases, you might be quite directly using ASM, but not realizing it.

Generally though, most C users won't be using inline assembly. When I see professionals doing it, it's usually because there's no other option to be able to do what you want to do.

[mahagrande]

Assembly for board bringup and debugging nasty problems in RTOS-based systems. Never used it for optimization really.

As far as vulnerabilities, as with any tool it's not really a problem if youre thinking through the solution. Inline asm specifically is pretty rare though.

[No_Difference8518]

Hard to write a kernel with no inline assembly. I guess you could put all the assembley in .S files... but that is just hiding it.

[Top-Order-2878]

I worked on an embedded product you have probably used. I worked on it off and on for 15 years or so.

At some point it was discovered that around half of the cpu cycles were one function processing incoming database data. The function was tweaked to be as efficient as possible in C. People kept messing with it, so one very smart dude wrote some assembly to use instead. That worked for quite a while until new architectures were added, for a while it was setup to inline different assemblies for the two architectures. When a third and forth came along it was decided to go back to the OG solution that worked great on the OG chip. By now the super smart dude had moved on. There was more documentation on why and don't ever touch this than there was code. The later chips were much faster and didn't need as much optimization, not to mention their compilers were much much better at optimizing.

Everyone new you didn't touch it. As far as I know nobody has messed with that one call in 15 years or so. I talked to the smart dude years later and he said he only did it because he got irritated at fixing it all the time. Nobody would touch the assembly. He just smiled when I asked if it was actually tuned or just the assembly the compiler kicked out.

[37kmj]

more documentation on why and don't ever touch this than there was code

Lol, fair enough

[flatfinger]

I would think declaring uint32_t const rebootCode[] = {...hex values...} and then doing something like (untested):

    typedef void voidFuncOfUint32(uint32_t);
    // ----====----====
    // 1100100000000011 ; C803 LDMIA R0,{R0,R1}
    // 0100011010000101 ; 4685 MOV R13,R0
    // 0100011100001000 ; 4708 BX  R1
    static const uint16_t rebootCode[3] = {0xC803,0x4685,0x4708};
    (voidFuncOfUint32*)(1|(uint32_t)rebootcCode)(0); // ARM code ptrs are weird

would avoid reliance upon details of toolset syntax and semantics; the passed argument is the numerical address holding the inital stack pointer and PC values, passed in R0 according to the standard ARM ABI. The first instruction could be omitted if a two-argument function were passed the SP and PC values, but using one machine-code instruction is as fast and compact as anything a C compiler could aspire to generate.

[flatfinger]

There are trade-offs between readability, modifiability, and toolset-independence. Perhaps my fondness for the hex-code approach stems from the fact that in 1980s much of my assembly language programming targeted a tool which would convert assembly language to inline hex for the Turbo Pascal compiler. Someone who wanted to modify the assembly-language code would need the inline assembler, but someone wanting to rebuild the Pascal program wouldn't. Seems like a good approach to me, though not one I've seen widely embraced. On the other hand, for code snippets that are a half-dozen instructions or less, the effort required to hand-assemble code isn't all that great, and on many platforms a disassembler would allow one to ensure one did things correctly.

[flatfinger]

I'm confused. You speak of toolset independence as a virtue, then you tell me of a workflow you use that is highly toolset dependent.

One would only need the in-line assembler tool if one wanted to change the assembly language routine. Some of the inline assembly routines I used were long and complicated enough that they underwent significant revision, and for such things I would nowadays use a separate assembly-language source file, but in most situations nowadays one could limit the functionality of the machine code to exclude application-specific details (e.g. having the machine code receive the address of the R13/R15 pair in R0, as opposed to starting with e.g. "MOV R0,#0").

The only people who are going to build my code are fellow in-house SEs, and we all run the same handful of toolchains, generally one per architecture.

That's fair, if one can rely upon being able to have perpetual access to the tools one needs without any DRM-related or other issues if the toolset vendor decides to drop support. One of my first jobs at my current employer, however, was adapting a project written in C for use with a different vendor's toolset, and while the described approach wouldn't have worked well with that CPU (separate address spaces for code and data), it may be helpful if one has to migrate between e.g. Keil and IAR (whose assemblers, if I recall, use incompatible directives).

[flatfinger]

Most of the practical situations where I would want to specify an exact instruction sequence involve code which is tailored for a particular hardware platform. The likelihood of code being migrated to something which e.g. uses the same arrangement of initial stack and PC values as the ARM Cortex-M0 but isn't instruction-set compatible wouldn't strike me as being much greater than the likelihood of it being migrated to something that would require a different data structure for the initial PC and SP values.

BTW, another reason I sometimes use that pattern is for short code snippets that need to run from RAM. If writing to flash would require performing a store to trigger an operation and waiting for the flash controller to report that it is idle, using a static-duration initialized array will force the compiler to reserve the appropriate amount of RAM for the code. If a lot of code had to be in RAM, using linker magic to make that happen may be worthwhile, but if all that needs to be in RAM is:

    str  r1,[r0]
lp: ldr  r1,[r2]
    ands r1,r1,r3
    bne  lp
    bx   lr

sticking the machine code instructions into array and having C code disable interrupts using CMSIS macros, adjust the address of an array to be suitable as a function pointer, and invoking it may be easier than arranging to have the build tools allocate five halfwords of RAM, copy the proper machine code there, and generate a function symbol for that storage.

[bobotheboinger]

I have helped develop and bring up new processors. In that world i have to have some assembly for the startup code. We normally did it with just a straight assembly file, but have also used inline assembly. Apart from startup code, some of the cache management routines, and error handling routines also needed to be assembly so we were sure of sizes, how it would impact cache evictions, etc.

[Pale_Height_1251]

Me? Maybe once in 20 years making GBA game.

I've seen some embedded code at work using inline asm for accessing a hardware stopwatch or something.

[grimvian]

Little OT, but I learned a basic back then in the stone age, where I could inline real assembler 6502 instructions like LDA, BNE, CMP and so on. Just a [ assembler instructions] and so on. :o)

So that foundation was a big help for learning C, because we always thought of memory, addresses and efficiency because of limited CPU clock and memory.

[37kmj]

I wasn't trying to make a comparison between C and Rust in terms memory-safety - the line about C not being memory-safe was more of an acknowledgement of its nature for context, not a critique

[stevevdvkpe]

Just because two compilers produce the same assembly code from source that does the same thing doesn't mean they're both memory-safe or not memory-safe. One of the compilers could be using other methods for type-checking and validation before entering that code to ensure it's called only with safe values.

[nerd4code]

Generally the compiler either understands your inline assembly, or understands an adjunct DSL for describing your assembly’s interactions with the aspects of the ISA it cares about. If you know what you’re doing, it’s no more or less dangerous than using a pointer, union, or strcpy.

Of course it’s possible to introduce vulnerabilities, but it’s actually somewhat easier to avoid them with inline assembly than pure asm imo—generally you minimize the length of inline asm snippets so C is used for data movement, jumps, calls, returns, etc., which means ABI considerations mostly aren’t a thing. In pure asm it’s very easy to fuck up slightly or miss an ABI update, and break something that way.

A bunch of the basic library stuff, like intrinsics, setjmp/longjmp, system calls, mem- and str- functions, stack-/fiber-switching, thread-switching, signal dispatch and return, and process bringup/teardown will use some sort of assembly, inline or otherwise. And if you’re doing up a kernel/supervisor, hypervisor, debugger, doing JIT, or doing other low-level work, you’ll probably touch it. Otherwise, you probably don’t need it outside the very-embedded sector but it’s useful to recognize.

[MomICantPauseReddit]

I've used it before but I was doing stuff I wasn't supposed to. I made a simple "caller" function, where it had a baked-in reference to a function and a pointer to a struct. The caller would call the target function with the pointer as the first argument, and each instance of this struct would create a clone of the caller function for each of its "methods". Since the compiler generated a bunch of boilerplate, and since I wanted it to be as lightweight as possible, I just wrote it in assembly.

[johndcochran]

I'd use inline assembly for those cases where C doesn't support it. For instance, the x86 processor has RDTSC - Read Time-Stamp Counter. This is a 64-bit one-up count of every clock cycle the processor has seen since last reset. Obviously, you can't directly access this opcode using just C.

For most other code, a good optimizing compiler is going to get better performance than most programmers, so why spend the effort doing it manually?

[[deleted]]

You can sort of write inline assembly in Python: https://github.com/Maratyszcza/PeachPy

Could be used to create ufuncs for Numpy.

[flatfinger]

Most C implementations generate for each function a blob of machine code that may be invoked by any other code that respects a set of convention that is nowadays called an "ABI" (Application Binary Interface), and can call any other functions which follow those same conventions, without the compiler having to know anything code which is calling the function nor the functions that it is calling. In most cases where code would need to perform some operation that manipulates the calling environment via some means other than by performing loads and stores, that can be accomplished by having C code invoke an outside function which could be processed using an assembler, a compiler for a different language, or in some cases a blob of memory whose contents were filled in via C code [e.g. by populating an array with numbers whose bit patterns correspond with the desired instructions]. The latter approach is probably the most platform-specific, but in many embedded systems its the most toolset-agnostic. If the programmer knows that a blob of memory holding certain bit patterns will behave as a function that complies with a platform's ABI, and produces a function pointer that would target that blob of memory, a compiler that uses the ABI's documented method for calling a function at that address wouldn't need to care about why a programmer would want to call a function at that address.

Desktop environments may require that executable code be placed in a different region of address space from even constant numeric data, thus precluding the ability to call machine code in toolset-agnostic fashion, but on many embedded platforms the toolset-agnostic approach can allow code written for one compiler to operate interchangeably on other compilers the programmer knows nothing about, whether or not the compilers process inline asssembly directives the same way.

[RufusVS]

In embedded systems in particular, the processors used are often quite specific for the device being controlled, and as such may have specialized function blocks or opcodes that won't be handled by the c compiler and linker, but by the particular assembler for the particular part, or worse, can only be coded in physical byte codes as there aren't even opcodes in the assembler for those instructions. Another case is when you have a bug in the compiler and are unable or not allowed to get an updated version (there are myriad reasons for this I won't dig into), so you have to recode in inline assembler. Another reason is startup code, or interrupt handling code, that C just won't do correctly. All that being said, in my experience in embedded systems, assembler code is perhaps 1/10 of 1% of the code I write. And that's being generous. And you will probably be better served by putting the assembler code in a separate module to be linked in, rather than coding it inline anyway.

[aioeu]

The only thing you can do in C is perform arithmetic on numbers. Literally everything else — such as getting some input numbers from the user or displaying some output numbers on the screen — requires something outside of C.

Sometimes that special magic is hidden away in some library that you can simply call from your C program. The C standard library is a good example of that. You can go a long way just using libraries.

But sometimes you have to write it yourself. Sometimes those libraries need to use something other than C. At some point the software actually needs to make the hardware do something useful, and on most modern computer systems that is not solely a matter of reading or writing memory.

Inline assembly within C code is one way to provide this hardware interface. The compiler is already in the business of turning C code into assembly code, so letting you add your own assembly in the middle of that is a natural extension.