14 ms·

Is anyone still using assembly language? You betcha (2007)

• sylware 4y ago
  pro: you are not dependent of grotesquely and absurdely massive and complex compilers, until you don't over abuse the preprocessor. and that alone...
  • turminal 4y ago
    Another pro is that it's often possible to beat the performance of said compilers in places where that matters if you're willing to put enough time into it.
    • bluGill 4y ago
      Sure, but by the time you do the CPU manufactures have come out with a different CPU with different ideal optimizations. If your code is compiled you just flip a switch on the compiler and your code is now better optimized for the new CPU than your previously well optimized code. If this really matters you can compile several hundred different versions of your code for the several hundred different X86 variants out there. And if management wants to try ARM, compiled code it is just a small change to your compiler to do that, again possibly hundreds of different executable for all the ARM variants if you feel the need.
    • PaulDavisThe1st 4y ago
      12 years ago, we used asm for the inner loop that does peak metering in Ardour. It is essentially doing a greater_than comparison on every single sample that passes through the program, which could potentially be millions per second. Using SIMD instructions directly from asm with a not-small buffer size reduced the CPU cost by 30%. Last year, someone was updating this code to include ARM and some newer SIMD instruction sets. We discovered that in that time period, gcc has gotten to the point where even our hand-crafted asm is barely any better (and in some cases worse) than gcc's own generated code. Compilers improve!
      • sylware 4y ago
        It depends where you draw the complexity lines: some will prefer to do anything otherwise than to depend on those grotesquely and absurdely massive and complex compilers: Rube Goldberg Machine Syndrom.
      • StillBored 4y ago
        Its true that compilers improve, but i would be willing to bet that if you took the C code and ran it on the original machine there is a good chance that the assembly would out perform it. Hand optimized assembly doesn't necessarily age well, because a large part of the skillset is conforming the code to the processor micro-architecture. Compilers do a lightweight version of this with the -mtune where they utilize tables reflecting the number and type of functional units, instruction latency and throughput, etc to make various tradeoffs in instruction selection and/or placement. The usual "simple" example is a memcpy operation. There are about a dozen different ways (int register moves, utilizing vectors of various sizes, nontemporal, rep movXX, etc) to implement it, and depending on processor, memory subsystem, alignment, and transfer size there can be significant perf diffrences when picking one alternative over another even before considering whether to try prefetch hints, strip mining, or any of the other things that can made a difference. Bottom line, just like playing with differing compilers, and compiler options can easily provide a 2-5x uplift its likely that an expert assembly programmer can gain that much or sometimes significantly more (because they can fundamentally change the algorithm) against a compilers best output, there remain a fair number of things that can be done with hand tuning that compilers simply aren't yet capable of. Since your using SIMD the compiler could be beating it simply because its utilizing one of the wider vector instruction sets vs the original code. Although, for a software package where you don't know the final machine much of this becomes more difficult unless your willing to have a half dozen optimization targets selected at runtime. Bottom, line if it matters that much, there are still people who can take the best code you get out of a C/C++ compiler and generally provide an uplift. Whether its worth the effort, that is another question.
        • ajb 4y ago
          So, I used to do this for a living. The main reasons assembler worked better were: - The compiler had to make conservative assumptions. Less true now you have things like restrict pointers - The compiler didn't know how to do SIMD. Now it can with intrinsics. - The compiler didn't know how to do the necessary transforms to make use of in-order cores. out-of-order makes the cpu do this itself, and is making its way down to smaller processors.
    • salawat 4y ago
      Isn't this mo ponger an issue with things like Godbolt? When you can actually plug in and see what you get out to vet for correctness, I'd think there shouldn't be as much need to per se ignore the compiler.
    • sylware 4y ago
      Indeed, usually it would be appropriate only in very specific places, and if it _really_ needs to be chip implementation specific, you could install specific machine code for those implementations. This is not perfect, but in all cases, it is much less worse than to depend on compilers like gcc/clang.
• eismcc 4y ago
  I’ve not used this but looks promising http://flatassembler.net/ http://flatassembler.net/
• Koshkin 4y ago
  Perhaps somewhat surprisingly, assembly (when it is a direct representation of the machine code) is indispensable in detailed analysis of algorithms, which is why Knuth uses it in his treatise (instead of, say, Algol or Fortran).
• barbegal 4y ago
  From 2007 but most of the contents of the article are still true today.
  • zokier 4y ago
    In the past 15 years ARM has continued to steamroll the embedded field making those weird/small architectures discussed in the article more and more obscure and niche. Using C instead of asm is pretty much the norm on ARM For reference, STM32 series, launched in 2007, were one of the earliest Cortex-M MCUs.
• PartiallyTyped 4y ago
  There are few things as satisfying as beating GCC through pipelining, tail call recursion, and other absurd hacks as a 2nd year student who just learned to write hello world in assembly. I feel the desire to actually learn it again and build bigger stuff.
  • salawat 4y ago
    How about updating GCC to do your optimizations? I mean, let's be real: a needle and a steady hand hasn't been the key to getting the little man in the box to do your bidding for a while!
    • PartiallyTyped 4y ago
      The optimizations were very domain specific for them to work on anything other than that particular problem, and I certainly don't know enough to contribute to projects like LLVM or GCC.
• ssl232 4y ago
  Transport Tycoon Deluxe and Rollercoaster Tycoon were famously programmed in assembly by Chris Sawyer, essentially on his own. I recall they worked on my Pentium 166 practically without issue, even with large maps; perhaps only a tiny bit of lag when zooming out to view the whole thing. They've since been unofficially rewritten in C++ [1, 2]. [1] https://www.openttd.org/ https://www.openttd.org/ [2] https://openrct2.org/ https://openrct2.org/
  • kwertyoowiyop 4y ago
    Gotta say that was a bad choice even then.
    • tete 4y ago
      By what measure? It's a great game, that people still talk about, ran more smoothly than a lot of current title. And it sounds like he knew the language. So how was this a bad choice?
      • kwertyoowiyop 4y ago
        He could’ve gotten essentially equivalent performance writing it mostly in C, with only the time-critical parts in assembly. Assuming equivalent knowledge of C, it would’ve been quicker to write, easier to update and port, and easier for others to work with the code.
        • tete 4y ago
          Not to sound rude, but this mostly seem like "random" assumptions, even on the goals side. Was there others to work on the code? Was portability a goal? Would it matter if the interface is a C for DirectX anyways?
          • kwertyoowiyop 4y ago
            You don’t sound rude. These assumptions are common for games in general, but who knows what the assumptions were for this game in particular? Or whether this programmer knew C well at the time? Or if Microsoft was likely to ask for ports or updates?
• brightball 4y ago
  There is a company named WorldSpan in Atlanta that wrote all of Delta’s flight reservation software in Assembly.
  • chrisseaton 4y ago
    How come?
    • tiborsaas 4y ago
      Vendor lock-in, I guess :)
    • FPGAhacker 4y ago
      Vendor lock in.
    • Avshalom 4y ago
      with out knowing anything my guess would be it was using some ibm mainframe. AIUI the z/architecture's assembly is fairly high level (by assembly standards)
      • the_only_law 4y ago
        I’ve been kinda wanting to look into z/Arch machinery, ofc I don’t have a multimillion dollar mainframe unfortunately. Hercules can do S/390 which is close enough I suppose.
    • tomhoward 4y ago
      Those airline reservation systems were built in the 70s and 80s, and had to be extremely efficient, so, evidently they felt assembly was a better option than any of the higher level languages available around that time.
      • bluGill 4y ago
        Back then it was the better choice. Not only where CPUs much slower, but optimizing compilers were not nearly as good (if they existed - often they didn't).
• tomhoward 4y ago
  My father still uses assembly language, on 8-bit Motorola (now NXP via Freescale) microprocessors. He's ben doing it since the early 80s, for data monitoring and control devices for various applications in agriculture, industry, academia and other sectors. I've been working with him for the past few years to modernise his products and give them a future beyond his retirement, which is finally happening now (he's 74). The device we've been working is an agricultural data monitor that reads from sensors in the soil and atmosphere (measuring impedance, voltage, pulse and digital signals), stores it in local flash memory then periodically uploads it via to my web app via a U-Blox cellular/IoT modem. It's amazing what he's been able to make it do, and how simple/cheap the componentry is and how low the power consumption is. And whilst the coding and debugging is pretty slow and laborious, once it works, it's incredibly reliable and stable. Now he's retiring, if the business is to continue we'll basically have to find someone who can migrate it to higher level platforms and languages. There aren't many (any?) people around willing/able to work with this kind of assembly code these days. It feels like a shame. Other players doing this kind of work use higher-level platforms, which may be faster to develop for and debug but are more costly to manufacture, use more power and are less reliable. I'm hoping we can find a balance between the easier/faster development cycle of newer platforms, whilst retaining at least some of the simplicity and elegance of my father's approach.
  • MrYellowP 4y ago
    Mate, how does this "migration" look like (I have no idea how to imagine it) and what platforms are you writing of?
  • SnowHill9902 4y ago
    Why do you have to “migrate to higher level platforms and languages”? Assembly is perfectly valid for this application.
    • tomhoward 4y ago
      If we could find developers willing/able to do it, I'd happily stick with it. Such people are hard to find, but anyone reading this who is interested, feel free to get in touch (email address in profile).
• patentatt 4y ago
  Can anyone recommend an x86 assembler to use in 2022? Is NASM still the default choice? Also, what about a modern x86 reference, most of what I have and pretty much stops at the pentium era. Any source for an authoritative reference that covers x86-64, all the varying SIMD flavors, and any other new and interesting developments in the ISA in the last ~20 years?
  • jcranmer 4y ago
    For a standalone assembler, I think YASM is a little more the default nowadays than NASM, although honestly the two are probably very interchangeable. Another major option is to use your C compiler's assembler (gas, clang -cc1as, or masm), or suck it up and use inline assembly directly.
  • Okx 4y ago
    Here is the AMD64 reference manual https://www.amd.com/system/files/TechDocs/40332.pdf https://www.amd.com/system/files/TechDocs/40332.pdf The stuff you will need most is in Volume 3.
  • sylware 4y ago
    fasmg: https://flatassembler.net/ https://flatassembler.net/ it is written in x86_64 assembly (namely bootstrapping is sane not like gcc/clang/etc). x86/x86_64 intel syntax. It is actually the most powerful macro processor I know of, then be careful not to lose yourself in there and not to forget to write assembly. It has experimental support for other ISAs like arm (maybe risc-v in the future). The best way to see it, is as a macro language specification which targets writting assembler languages, with a x86/x86_64 reference implementation. nasm: x86/x86_64 intel syntax used by ffmpeg. Main issue: its SDK is horrible with disgusting code generators and so on. It has also a powerfull macro processor, then carefull not to abuse it. gas: from GNU binutils, tons of ISAs, but for x86/x86_64 you should switch it from its default, AT&T syntax, to intel syntax. If some definitions have to be shared with C, I would recommend to combine their usage with a C preprocessor (gas is made to be friendly to a C pre-processor).
    • anta40 4y ago
• ThomasBHickey 4y ago
  Having done some production assembler coding in the late 70's, I expect most new assembler work is now done more for fun than by necessity. Unless the code is well commented and laid out, working with existing assembler code can be very difficult. That said, I've been experimenting using the m4 macro language to make Web Assembly (WASM) a little easier to use. WASM is a well thought out language and a number of people are doing some hand coding in it.
• lbriner 4y ago
  It is still widely used in microcontroller programming. Although general purpose programming is often easier in C or similar, if timing is critical, you either have to start with C and tweak the assembly or just do assembly from the beginning.
• PaulHoule 4y ago
  Today lack of portability is the main problem I see with assembly. I absolutely love AVR8 assembly but the AVR8 is a dead end in terms of performance (other than maybe "build a soft AVR8 inside an FPGA and delegate tasks to the gate away") The fact that I can recompile C to ARM keeps we writing code in C even though I hate it.
  • AnIdiotOnTheNet 4y ago
    I think people overestimate the value of 'portable' code. Even with C or other higher level languages you often have to code around platform specific problems or jump through hoops for platform specific optimizations. Regardless, if you understand what the code is doing then re-writing it for a different platform is pretty trivial, and isn't rewriting code the favorite sport of programmers anyway? Granted it is not a modern-style piece of software, but look at David Murray's Attack of the PETSCII Robots: originally hand-written in 6502 assembly for the Commodore PET and since ported to something like 20 different platforms, many of which have wildly different video and audio hardware and several of which use a completely different processor.
    • rahen 4y ago
      This exactly. In the 80s, it was common practice to write in macro assembler, which would then be translated to the target ISA. Microsoft wrote BASIC and others significant software in such a way. https://devblogs.microsoft.com/commandline/microsoft-open-sources-gw-basic/comment-page-3/ https://devblogs.microsoft.com/commandline/microsoft-open-so... Also compilers are hungry, wasteful, complex piece of codes fairly unsuited for 8 bits and 16 bits machines. DOS games started being written in C only when the 386 got commonplace. Heck, even on 32 bits machines of the times (VAX), most things were written in pure assembly. That includes VMS.
      • PaulHoule 4y ago
        Turbo Pascal wasn't bad at all for the 8088.
• ddanv 4y ago
  Example of modern assembly in dav1d decoder implementation https://code.videolan.org/videolan/dav1d/-/tree/master/src/x86 https://code.videolan.org/videolan/dav1d/-/tree/master/src/x...
• dimitrios1 4y ago
  ctrl+f=rust: 0/0 I am shocked.
• ptrik 4y ago
  We've got https://github.com/SnellerInc/sneller https://github.com/SnellerInc/sneller which is a query engine for JSON based on AVX-512 assembly
• vnorilo 4y ago
  There are degrees to "assembly". There's .s source files. There is inline assembly with varying degrees of compiler plumbing/spilling/automation. There are intrinsics where you delegate register allocation to the compiler and allow it to optimize if it can. Then, sometimes you write specific C idioms that you know LLVM is going to turn into certain instructions. For highest performance, you will always think in assembly, and in fact in the internals of your target CPU (as far as they are known), even if you have various layers of software to produce the bitstream in your object files.
• psyc 4y ago
  I love assembly language and I'm sad that I haven't used it for work since ~2005. I had just discovered SIMD... I have finished Shenzhen IO and Exapunks (and some TIS-100) in recent years, but they're not really comparable to x86/64. Timely? https://i.ibb.co/tZZdMH7/hn.png https://i.ibb.co/tZZdMH7/hn.png
• cdelsolar 4y ago
  At my first job I wrote a bunch of AVR assembly because C was too slow for what I needed it to do. I believe the application was having the microcontroller do some measurements of sound propagation through a medium that was much denser than air, and thus it needed to wake up nearly immediately after the sound happened. By the time whatever initialization the C code did was done, it was too late. Assembly did the job superbly. This was not that long ago, around 15 years ago. I really enjoyed AVR assembly. Are these microcontrollers still in use nowadays?
  • the_only_law 4y ago
    Pretty sure one of the biggest educational/hobbyist dev boards of all time is uses an AVR: https://en.m.wikipedia.org/wiki/Arduino https://en.m.wikipedia.org/wiki/Arduino
• dmos62 4y ago
  Funny thing is that you can do web development in assembly now: https://webassembly.org/ https://webassembly.org/ I feel like we've gone full circle.
  • manjana 4y ago
    Isn't everything just compiled to wasm?
    • ThomasBHickey 4y ago
      Well, normally, but you can write it directly in the text format (.wat). It's doable.
• tyingq 4y ago
  TLS libraries also typically still have a fair amount of ASM. I remember when it was pretty much mandatory to have an SSL accelerator board to run a largish website. The optimised ASM in TLS libs + newer gen processors finally killed that off. Of course, generally, lots of crypto libraries have ASM, but the TLS example is interesting because it's everywhere.
• sylware 4y ago
  If RISC-V becomes a de-facto standard (I wish), very probably a LOT of software will go back to assembly:much less planned obsolescence that you usually get with c11/c17/c23/c7893743984798, a new gcc builtin/extension used in the core of linux each weak (irony), etc.
• anta40 4y ago
  Yes, for writing good old NES, Atari, GameBoy etc games: https://www.assemblytutorial.com/ https://www.assemblytutorial.com/ I mostly write mobile app codes (Java/Kotlin), and there's no way I'll use assembly for work. But for fun? Heh why not? :)
• ivanmontillam 4y ago
  There's this misconception that Assembly language is old and obsolete, and there is nothing further from the truth, and I consider it the ever-present programming language. Sometimes, when you do the performance profiling of your software, you can find bottlenecks for which your programming language could be the issue. I'm particularly a fan of the ctypes Python library, libffi and similar. Android NDK is a brilliant piece of SDK to get closer to the metal in terms of performance. Assembly language is not old; it just evolves with micro-architecture.
• mud_dauber 4y ago
  My first dev job used Forth (with inline assembly) on Z80-class CPUs for SCADA applications. I'd claw my eyes out if I had to write entire applications in assembly.
• CM30 4y ago
  Slightly late, but assembly is still used fairly often in the modding scene for older video games, as well as for creating homebrew titles for said systems. The resources used for your average Super Mario Bros 1/3/World hack are used written directly in assembly language, as are quite a few standalone games. It's because the systems are underpowered enough that using a higher level language wouldn't get very good results, and because access to the original source code is basically nonexistent. For those titles which have been entirely disassembled (like say, Super Mario 64), the average mod now seems to be made in a language like C instead.
• mid-kid 4y ago
  Does anyone here know of any good assemblers for ARM? Aside from binutils/gas, I mean. It feels like that architecture has never gotten as many assemblers written for it as other architectures.
• mbrodersen 4y ago
  Years ago I wrote a Space Invaders clone in Motorola 68000 assembly on the Commodore Amiga. That was a fun project! I recently found a printout of the assembly source code and I was surprised how easy it was to read and understand. I felt ready to jump in and continue working on it. It was much easier to read and understand than most “higher level language” code I have seen in my career. I suspect that the lack of higher level language features kinda forces you to write simple clear code.
  • _the_inflator 4y ago
    I don't agree here. What is "simple clear code"? Space Invaders is no benchmark for me. I myself do demo coding on Amiga 68000 and debugging consumes a lot of time with the infamous Gurus. Compare this to a breakpoint in your code on modern machines. Rebooting takes time etc. Workflow is also tough. Corrupt diskettes - and there goes your source code. Also on a machine code level you have to deal with everything yourself. How to represent floating point math? Fast division? Large datasets? Clipping to deal with 3d vertices? Blitter settings sometimes feel like magic not science. Small projects are indeed fun, however larger one in my opinion not really.
    • mbrodersen 4y ago
      Yep I agree with the Blitter. I never fully understood how it worked :)
• Johnythree 4y ago
  I think there's another point here: To be fluent in Assembler you must understand the hardware in detail. However once you move to a high level language, the hardware becomes relatively invisible. I started out with calculator chips in the '70s, then moved to the 6502, the 8051, and then to the PIC series. I absolutely love the larger PICs. But then the Arduino came along and suddenly the hardware became invisible. For that reason I've always disliked programming in C, python, etc, and absolutely detest C++ I reckon that many millenial programmers tend to avoid Assembler because they simply don't understand the hardware.
• MrYellowP 4y ago
  Yes! The only language that comes to a distant second place in terms of ease of use and readability is python. Mixing python directly with assembly code is fucking amazing!
• kwertyoowiyop 4y ago
  If anyone needs a 6502 programmer, I’m available and cheap! :-)
• retrocryptid 4y ago
  Oh man. The 9900 architecture was awesome. Designed at a time when bipolar memory was faster than TTL logic, it put the register file in main memory. Only the PC, STATUS register and "WORKSPACE POINTER" were on the CPU. The general purpose registers were in memory, pointed to by the WP. It was trivial to implement threads on that machine, just execute a BLWP (branch and load workspace pointer) when jumping between threads.