6 ms·

Does any one here use a lot of assembly in their job? If so, what do you do? I started getting fascinated about computer architecture a while back, but then I

Does any one here use a lot of assembly in their job? If so, what do you do? I started getting fascinated about computer architecture a while back, but then I saw how dead embedded programming was in my area.

vsampath 9y ago
I work on PC firmware (i.e. BIOS) and do have the pleasure of writing and debugging 16-bit x86 (although that's not my whole job description). If you or anyone else is intrigued, we are hiring! https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite/job/US-CA-Santa-Clara/System-Software-Engineer_JR1903489 https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCar...
flohofwoe 9y ago
Not for writing code but for reading C/C++ compiler output during performance optimization and debugging sessions.
- DamonHD 9y ago
  Same here. I do have to drop little snippets of asm in to code for bare metal stuff, but generally looking at the output of the compiler to see if it and I are on the same page is my main use. However, as we may well be about to switch our IoT device to ARM from AVR, this might be a useful primer...
Stenzel 9y ago
Since you ask, I use lots of assembly level programming for digital audio signal processing. Some ARM instructions offer special DSP specific features like saturation and fractional arithmetic that have no equivalent int C, so it justifies using assembly. Smaller ARM cores without NEON offer some kind of miniature SIMD by operating on two 16-bit or four 8bit numbers, these can speed up things as well. To take full advantage of these it is best to write some portion of code in assembly. I usually wrap a processing sequence into a gcc-style inline assembly macro, this way I can easily compare with a C-only macro and maintain portability, and it saves me from having to deal with the complete instruction set and calling conventions.
- geokon 9y ago
  Do you have any good examples? It's something id like to try (however in c++) but I'm not sure how to do it in a smart/not-too-ugly way
- oriolid 9y ago
  I've also been working with DSP processors in audio processing. The only time I've used actual inline assembly was storing stack pointer to measure stack usage. For saturating arithmetic and other stuff we used compiler intrinsics, which freed us from handling register allocation, stack management etc by hand. On that processor there weren't special instructions for saturating arithmetic but a flag was used instead, the compiler also kept track of that one too. We did read the assembly result and tweaked C code until assembly looked like what was expected, though.
  - dmytrish 9y ago
    Technically, assembly is not required for measuring stack: just use regular C address of any local variable/function argument (minus an address of some local variable in main) to have some approximation of stack usage.
    - oriolid 9y ago
      True. But I was young, stupid and had just completed a course on assembler on that processor. Money well spent.
fla 9y ago
Mostly reading disassembly for some types of low-level debugging.
kabdib 9y ago
I've done several embedded projects in the past 5-10 years years. Mostly it's a matter of writing just enough assembly to get things running, and flipping into C when humanly possible because life is short. Talk to old video game veterans [waves]. We wrote tons of assembly because there wasn't much choice. But these were largely 8-bit processors, the compilers weren't any good and the code space was constrained. But I was talking with a guy recently who said he'd written hundreds of thousands of lines of 68K assembly, and I have no idea why you would do that because 68K C compilers, Pascal compilers, anything compilers were pretty good even back in the benighted 80s. Well, better than assembly. Of course, once you flip into C you're still not in an environment where you have much of a runtime (I kept having to explain to a contractor why he couldn't do heap operations in an early boot phase, much less expect the results to be addressable later). Even in a very code-space sensitive project, I started off with a tiny bit of assembly, then made everything more or less functional in C, then went back and hand-coded routines as we needed to get bytes back: http://www.dadhacker.com/blog/?p=1911 http://www.dadhacker.com/blog/?p=1911 My level of fascination with an architecture can be dramatically by the quality of the available tooling. If there's nothing then that's fine, green fields are great fun. But if the tooling sucks (TI and your DSP software, I'm looking at you) or is horridly expensive, then I'm usually going to look for excuses to use something else.
pjc50 9y ago
Like kabdib, I've done far more reading disassembly than writing it, because for most purposes it's easier to use C as a macro assembler. I used to work next to someone programming Tilera manycore systems in assembler, because that's a sufficiently weird architecture that you need to do that in order to see any benefit. This is probably why manycore has never really taken off.
deleted 9y ago
[deleted]
tmccrmck 9y ago
Anyone involved in compilers will inevtibaly be reading lots of assembly.

vsampath 9y ago

I work on PC firmware (i.e. BIOS) and do have the pleasure of writing and debugging 16-bit x86 (although that's not my whole job description). If you or anyone else is intrigued, we are hiring! https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCareerSite/job/US-CA-Santa-Clara/System-Software-Engineer_JR1903489 https://nvidia.wd5.myworkdayjobs.com/en-US/NVIDIAExternalCar...

flohofwoe 9y ago

Not for writing code but for reading C/C++ compiler output during performance optimization and debugging sessions.

DamonHD 9y ago
Same here. I do have to drop little snippets of asm in to code for bare metal stuff, but generally looking at the output of the compiler to see if it and I are on the same page is my main use. However, as we may well be about to switch our IoT device to ARM from AVR, this might be a useful primer...

Stenzel 9y ago

Since you ask, I use lots of assembly level programming for digital audio signal processing. Some ARM instructions offer special DSP specific features like saturation and fractional arithmetic that have no equivalent int C, so it justifies using assembly. Smaller ARM cores without NEON offer some kind of miniature SIMD by operating on two 16-bit or four 8bit numbers, these can speed up things as well. To take full advantage of these it is best to write some portion of code in assembly. I usually wrap a processing sequence into a gcc-style inline assembly macro, this way I can easily compare with a C-only macro and maintain portability, and it saves me from having to deal with the complete instruction set and calling conventions.

geokon 9y ago
Do you have any good examples? It's something id like to try (however in c++) but I'm not sure how to do it in a smart/not-too-ugly way
oriolid 9y ago
I've also been working with DSP processors in audio processing. The only time I've used actual inline assembly was storing stack pointer to measure stack usage. For saturating arithmetic and other stuff we used compiler intrinsics, which freed us from handling register allocation, stack management etc by hand. On that processor there weren't special instructions for saturating arithmetic but a flag was used instead, the compiler also kept track of that one too. We did read the assembly result and tweaked C code until assembly looked like what was expected, though.
- dmytrish 9y ago
  Technically, assembly is not required for measuring stack: just use regular C address of any local variable/function argument (minus an address of some local variable in main) to have some approximation of stack usage.
  - oriolid 9y ago
    True. But I was young, stupid and had just completed a course on assembler on that processor. Money well spent.

fla 9y ago

Mostly reading disassembly for some types of low-level debugging.

kabdib 9y ago

I've done several embedded projects in the past 5-10 years years. Mostly it's a matter of writing just enough assembly to get things running, and flipping into C when humanly possible because life is short. Talk to old video game veterans [waves]. We wrote tons of assembly because there wasn't much choice. But these were largely 8-bit processors, the compilers weren't any good and the code space was constrained. But I was talking with a guy recently who said he'd written hundreds of thousands of lines of 68K assembly, and I have no idea why you would do that because 68K C compilers, Pascal compilers, anything compilers were pretty good even back in the benighted 80s. Well, better than assembly. Of course, once you flip into C you're still not in an environment where you have much of a runtime (I kept having to explain to a contractor why he couldn't do heap operations in an early boot phase, much less expect the results to be addressable later). Even in a very code-space sensitive project, I started off with a tiny bit of assembly, then made everything more or less functional in C, then went back and hand-coded routines as we needed to get bytes back: http://www.dadhacker.com/blog/?p=1911 http://www.dadhacker.com/blog/?p=1911 My level of fascination with an architecture can be dramatically by the quality of the available tooling. If there's nothing then that's fine, green fields are great fun. But if the tooling sucks (TI and your DSP software, I'm looking at you) or is horridly expensive, then I'm usually going to look for excuses to use something else.

pjc50 9y ago

Like kabdib, I've done far more reading disassembly than writing it, because for most purposes it's easier to use C as a macro assembler. I used to work next to someone programming Tilera manycore systems in assembler, because that's a sufficiently weird architecture that you need to do that in order to see any benefit. This is probably why manycore has never really taken off.

deleted 9y ago

[deleted]

tmccrmck 9y ago

Anyone involved in compilers will inevtibaly be reading lots of assembly.