Why do people use the AT&T syntax for assembly language? It sucks and needs to die [1] [2] [3]. I would support an effort to remove it from the GNU toolchain.
> Why do people use the AT&T syntax for assembly language? It sucks and needs to die [1] [2] [3].
It's just the syntax. Get over it. You get used to it in a few days, and using Intel syntax over AT&T doesn't make your programs any better.
> I would support an effort to remove it from the GNU toolchain.
That would break a lot of existing applications, removing it from the GNU toolchain would be the easy part.
You can still use .intel_syntax directive with the GNU toolchain or use another assembler like NASM or YASM. But in practice it's often easiest to just avoid hassling with assemblers and toolchains and use the AT&T syntax, despite the fact that you might not like it.
Bah. Coming from writing M68k assembly: Intel syntax needs to die. AT&T has some warts, but I still find it vastly more readable. x86 assembly is an evil enough mess without using a syntax seemingly designed to make it even more horrific.
If you're going to be spending time writing/reading assembly there's a good chance you'll need to refer to the architecture manuals and, for Intel, those only use the Intel syntax. Matching the reference material I think should be reason enough to move away from AT&T syntax.
I remember reading the cosmic rays article but did not know it was also written by ksplice, neat! Also, I'm not sure how well HN supports markdown. I was able to use asterisks to get italics, but not square braces followed by parentheses for links. That was following github's cheat-sheet (go to github and press 'm' to see the markdown cheat-sheet).
For a language with a C-like syntax that compiles into minimal x86 executables check out W [1]. It was designed for use in a small, single-executable self-hosting compiler targeting the HP 95LX family of early MS-DOS "calculators"/PDAs [2] and hence has no equivalent of libc; instead it expects you to code your own basic routines in assembly. I once wrote a bootable toy application in it that ran on regular x86 desktops (a command-line interpreter and calculator) and found the experience quite pleasant.
Well, yes. I should have been more clear that it's a "bring your own assembler" kind of deal. You have put the machine code in hexadecimal in the final .W file before it's compiled. Back then I used a free early version of Hiew [1] to assemble the subroutine code for my project but if I did it now I'd either make some kind of a preprocessor to convert in-line assembly to machine code before the source is fed to W.COM (the compiler's executable) or modify the compiler itself to call an external assembler. You can do the latter since the compiler's source code [2] is licensed under the GNU GPL.
Size, ability to have a single executable, requirement to display their copyright, and probably a few technical ones I can't remember anymore; I vaguely recall stuff about DOS4GW being more strict with certain CONFIG.SYS and HIMEM settings, but it was almost 20 years ago. :)
I once had an evening/weekend project to write C++ code on Windows without linking to the C and C++ runtime libraries. It was a lot of fun and it gave me some preparation for a next job that involved even more system-level stuff.
Sorry, I guess it's not "news." But the guidelines don't mention that it has to be. And it's not really necrobumping since I'm not reopening an old thread, just posting an article I read that I found really interesting, regardless of its age.
From the guidelines:
"What to Submit
On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity."
