11–20 of 48 posts
Why don't people use AT&T syntax for ARM?
AT&T syntax is a uniquely X86 thing.
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.
Not for writing code but for reading C/C++ compiler output during performance optimization and debugging sessions.
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...
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.
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.
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
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.
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.
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.
Earlier quoted context omitted.
AT&T syntax is a uniquely X86 thing.
I was very surprised when I'd discovered that the assembly in the Linux kernel sources for x86 was written in the AT&T syntax and the assembly for ARM was not. I always thought that the AT&T syntax was supposed to be independent from an architecture.
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.
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 ad…
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
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.
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 ad…
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.