OK, so renaming a file should be: $ mv new-name.txt old-name.txt I defer to the blogger's superior UX expertise!
IMO there shouldn't be a way to run programs without named arguments.
No one should use the AT&T syntax (2021)
41–50 of 112 posts
Re: No one should use the AT&T syntax (2021)
#42As someone who has both written and read a lot of assembly in a professional context, my colleagues who are assembly writers very frequently prefer Intel syntax. The ones who are mostly (exclusively) readers seem to generally prefer AT&T. It is pretty undisputed that AT&T is easier for computers to parse, but it's also generally easier for humans to parse when reading it. * The suffixes give you a lot of easy specifi…
username checks out
Re: No one should use the AT&T syntax (2021)
#43OK, so renaming a file should be: $ mv new-name.txt old-name.txt I defer to the blogger's superior UX expertise!
Hey it works for github pull requests: base Merge the right into the left. Sure, totally intuitive.
Re: No one should use the AT&T syntax (2021)
#44I didn't really read the article, because/but I spent a minute or two playing with the cat. Nice little animation.
It used to be known as Oneko or Xneko, and chase your Windows or X11 desktop cursor. I once used it on both. Forcing it as a high-contrast distraction upon people who just want to read an article seems like it will discourage some of them. Discouraged people who nevertheless want to read the article, while using their pointing device to scroll, could add this to their uBlock Origin "My filters" tab: ||outerproduct.ne…
Alternatively you can enable reduced motion in browser settings and its code won't run.
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Re: No one should use the AT&T syntax (2021)
#45> Putting the destination operand first emphasizes the site of mutation. This doesn't make any more convincing an argument than the "linguistic" and "consistency" arguments he shot down earlier. Why should putting the mutated argument first emphasize it any more than putting it second? If you order things the same way every time, people will implicitly know which one is the mutated argument because that's how the lan…
The actual argument there is that most instructions with explicit, specified output registers have exactly one output register (which is mutated) where as most have multiple, non-mutated input registers. Of the instructions with multiple mutated output registers, most encode 1 or 0 (I am just going by memory here) output registers with the remaining being implicit.
Google C++ guide says to put mutable parameters last, but I've seen other style guides say the opposite.
Re: No one should use the AT&T syntax (2021)
#46OK, so renaming a file should be: $ mv new-name.txt old-name.txt I defer to the blogger's superior UX expertise!
Well consider consistency. In assembly's case. Using to from order makes it consistent with C. Consistent with manuals. And in the case of arithmetic instructions, consistent with the order used in mathematical notation.
On the other hand for shell scripts, using from to makes it more consistent. With what? Pipelines read a from-file process it and then write. from to.
Re: No one should use the AT&T syntax (2021)
#47> ...you should still clean your CPU at least annually: use soap, warm water, and a soft rag to get the gunk out of the transistors. I know the author is just making a joke here, and it is funny. Somehow it reminded me of some actual advice I've seen more than once on /r/thinkpad. I am paraphrasing from memory, but I'm sure I have the gist of it: > When you get a brand new ThinkPad in a factory sealed box, the first…
It's more and more true, though, that the physical condition of your CPU and heatsink affects performance. Because under heavy workloads they're often thermally limited, and every 0.01 K/W of thermal resistance makes a noticeable difference.
Re: No one should use the AT&T syntax (2021)
#48Howant people are writing nee assembly languages such that this matters?
Why would anyone even write in an assembly language instead of a human friendly language that has a simple compiler to to goofy assembly?
Re: No one should use the AT&T syntax (2021)
#49As someone who has both written and read a lot of assembly in a professional context, my colleagues who are assembly writers very frequently prefer Intel syntax. The ones who are mostly (exclusively) readers seem to generally prefer AT&T. It is pretty undisputed that AT&T is easier for computers to parse, but it's also generally easier for humans to parse when reading it. * The suffixes give you a lot of easy specifi…
> Operand order in AT&T is really dumb I always found AT&T order much more intuitive to read. The "what am I doing" and then "where will it go" felt natural to me. But I didn't do much assembler, so my opinion doesn't matter :)
I first learned assembler on Z80, and so the Intel syntax should be more natural to me, but I migrated from that to 68000 which uses destination-last syntax, and never really had any problems with it even though I'd been using Z80 for a few years by then. About a year after learning 68000, I started coding 8086 assembler and felt that Intel syntax was backwards, even though it's the same order as the Z80 I started on. Now it's been almost 2 decades since I wrote 68000 code, and I've drifted back to Intel syntax as the default, although I've always had a particular hatred for the square brackets for memory accesses. I remember being particularly disgusted by the DWORD PTR nonsense that the original MASM insisted on, and back in the day preferred a86 (no, not the Linux one, the old shareware DOS assembler from the late 80s) which had a much more sane syntax.
AT&T syntax also pre-dated Intel syntax by several years, and was based on the PDP-11 assembler which had the destination last. Many UNIX vendors later moved to 68000 which also had the destination last (possibly influenced by AT&T syntax, as all their 8-bit processors embedded the destination in the opcode). Other chips like SPARC, which was developed by a UNIX vendor for a UNIX-like machines followed suit, probably because all their engineers were already using AT&T syntax anyway.
As for the other arguments in the article, I think it's kind of fair to complain about the syntax, but also important to remember that as part of the GCC toolchain, the assembler was never really intended for humans to use, other than for short bits of glue code, but was instead really intended to just have enough functionality to assemble the output from cc1. When GCC was ported to Intel, it almost certainly made sense to keep AT&T syntax in gas because gcc developers were familiar with it, and the cc1 backend would probably have required extensive changes to output in a different order even though it wouldn't really benefit anyone because nobody was actually intended to read the intermediate .S file other than while debugging gcc itself. Obviously nowadays, cc1 directly outputs to .o and the -S flag is more for debug, and sometimes generates code that doesn't always exactly correspond to the generated code in the .o.
But anyway, despite all that defence for why AT&T syntax, I agree, it's ugly and I always hate writing code with it. I almost always use an assembler that uses the chip vendor's preferred syntax on whatever platform I'm using, mostly because it's then easier to refer to documentation.
Re: No one should use the AT&T syntax (2021)
#50> Putting the destination operand first emphasizes the site of mutation. This doesn't make any more convincing an argument than the "linguistic" and "consistency" arguments he shot down earlier. Why should putting the mutated argument first emphasize it any more than putting it second? If you order things the same way every time, people will implicitly know which one is the mutated argument because that's how the lan…
[deleted]