Granted, you wouldn't write a word processing suite in assembler,
Shhhh! Don't tell that to these guys:
In October 1978 [...] Barnaby began coding
WordStar. In four months, Barnaby wrote 137,000 lines of bullet-proof
assembly-language code. Rubenstein later checked with some friends from IBM
who calculated that Barnaby's output was equal to 42 man years. [link]
...or...
For the past three years, [Jeff Wilson] has been employed by WordPerfect Corporation as a software engineer. While there, he participated in development of WordPerfect for the Apple IIe/IIc computer line. He is currently managing development of WordPerfect for the Atari ST, which should be available shortly after you read this. He programs exclusively in assembly language, and enjoys it! [link]
Also, from what I understood, the WordPerfect Corporation actually required that all programs
be written in assembler. BTW, some
more interesing WP history.
Oh, you mean, you wouldn't use assembler to write a word processing suite nowadays. Ok, I getcha. Yeah, I think you're right. After all, WordPerfect Corp has been out of business for how long? (Well technically, bought out and resold, and resold... They're just a name now.)
Admit it: You've never done any significant calculations in hexadecimal on that calculator,
have you?
I say this as an owner of an HP48SX and HP48GX, and a former owner of a Casio w/ dedicated A-F buttons: The HP sucks at the tasks the poster asked about.
Not only do you have to hit alpha-lock to get the A-F on the HP (every time you enter a hex number), but you also have to remember to provide the correct prefix. Further, "integers" won't mix at all with "regular numbers" without going through that annoying "B->R" and "R->B" crap.
Do NOT get an HP48 for the tasks the original article was asking about. And I say this as a happy HP48 owner who loves RPN. You get used to the quirks,
maybe, but they're frustrating. I'd rather use 'bc'.
Still, you wouldn't know why the compiler is better than you are without understanding the principles behind the eventual assembly language.
Compilers do many tricks, but often times they need help from the programmer to know it's safe to do them. For instance, knowing minimum trip counts, pointer alignment, pointer aliasing information and so on can help a compiler dramatically, especially if such information is not immediately obvious from the code but is necessary to enable a class of optimizations.
Another factor is the type of architecture involved, and the delta you're willing to live with. I estimate that on most compute-intensive
loops, GCC for x86 is off from my most-optimal
hand code by as much as 50% (meaning, it runs half as fast, or takes twice as long as my code). For nearly anything I write on x86, that's perfectly acceptible and I don't write a single line of x86 assembly. In contrast, in DSP space, where cycle counting is a way of life, our compiler gets to 80% to 90% of hand-code performance on most of those compute-intensive codes, but we still hand-code. Why? Because those inner loops are 80% to 90% of the total run time and it can make the difference between 90 channels and 100, and that translates into $$. (Alternately, it can mean the difference between making a realtime deadline or not, which is even more important.)
Elsewhere, you said: "Claiming that you can do better on a small domain of the problem is a misleading anecdote." I don't think it's particularly misleading. I know better than to spend my time coding large stretches of branchy control code, but I also know that I could easily beat the compiler if I chose to do so. Only, it could take me days or weeks to get something that runs well as compared to minutes with the compiler. And that's why we have the compiler.:-)
Assembly is for the hotspots. You need to understand assembly to understand why the hotspots are hot and what to do to cool them off a bit.
I find that such students tend to reach a plateau in terms of accomplishments fairly quickly. Of course, it all depends on the nature of your job as to whether that really matters.
<cynic> At the very least, vo-tech kids are cheaper, and will probably want to leave for a different job in a few years, so the labor cost is lower. </cynic>
I was clarifying where I think the perspectives themselves originate. One's perspective at a college should be towards getting broad, adaptable skill sets. One's perspective at a vo-tech school should be towards getting an immediate means to an immediate end.
Students who go into college just looking for "vo-tech on steriods" often don't like where they end up, since what they really get is at most "really expensive vo-tech school."
(And when I say "vo-tech" I include places like DeVry and ITT Tech and most junior colleges.)
Funny you should mention VLIWs, since the DSPs I program (the TMS320C6000
family) are VLIW. They're actually much closer to traditional VLIW than Intel's IA-64.
Compilers can produce much more "pretty good" code than any human could (without going insane, at least), in a much, much shorter period of time. But I've never yet had the compiler beat me on size and speed simultaneously on any individual calculation-intensive function I've coded by hand. (It'll beat me very occasionally by a couple cycles at a large cost in size.) This is not because the compiler's bad at what it does. TI actually has one of the better optimizing C compilers out there, at least in the embedded space. (Disclaimer: I work for TI.)
The real difference, I think, comes from the assumptions the compiler can't make but that the programmer can. The semantics of the C language get in the way of performance sometimes. Pointer rules cause dependences where you don't expect them, alignment issues frustrate SIMD optimization, etc. When you code in assembly language, What You See Is What You Get, exactly.
One thing I've noticed in the comments attached to this article is the repeated question: "Is assembly still relevant?" As someone who codes assembly on a regular basis, I must shout an unequivocal YES.
It's relevant on many levels. First, as another posted has pointed out, learning assembly is very similar to an EE learning circuit theory: To really understand the aggregate effects, you sometimes need to understand the details. Now, one could counter "But Physics isn't taught that way!" You're right, but then Physics 1 (kinematics) and to a large extent, Physics 2 (electricity and magnetism) is much more concrete than anything you'll ever learn programming-wise.
Also, the "approximations" provided by Newtonian mechanics fairly accurately describe nearly all of what most of us will ever interact with. The rest of us take one or more Modern Physics courses that cover quantum mechanics and all the other nitty-gritty.
On another level, it truly does allow you to get away from the noise of the language and concentrate on what the machine really does. I've seen so many people that are so out-of-touch with their code, it's unreal. Even in C, it's easy to write code with way-too-much hidden complexity. If you understand assembler, though, you're more likely to think about the true cost of each action. At the very least, you're much more likely to be able to compile to assembly output and actually understand what you're looking at.
I work in embedded systems, and in that space, assembly language hasn't died. I program DSPs for a living. While high-level languages are continuing to absorb ever larger chunks of code in this space, it seems as though assembly will still always rule the tight loop. If nothing else, it's an invaluable measuring stick for knowing just how close or how far from ideal you really are.
So in summary, assembly language is still relevant. It's the only way to truly be demystified about how your code actually gets executed. And it's a great way to get programmers thinking about all the levels of abstraction when the time comes.
Another perspective on that is if I were just starting schooling now, do I want to waste a year learning archaic languages? In this industry a year is a LONG time to be sitting around not learning what will get you jobs.
Are you at a college or a vo-tech school? If you learn the principles of programming, then the language doesn't matter so much after awhile. You need to learn different programming paradigms, but once you do, then the specifics of syntax aren't as big a deal.
At a vo-tech type of school, you're there to pick up specific skills to allow you to target a narrow range of jobs.
At a college, you're there to pick up general skill sets and ways of thinking about problems that can be adapted to many jobs.
I consider understanding assembly language to be one of the basic fundamental concepts that helps unify all the abstractions we heap on top of it. If programming languages always just seem like magic to you, you'll never truly understand what you're doing. Good luck generalizing what you learn if you don't know what your code looks like on a couple different levels of abstraction.
Tell that to the now-defunct WordPerfect Corporation that couldn't make the jump to Windows cleanly because of the mandatory "everything in assembly language for speed and size" coding rules there.
And I say this as a former die-hard WordPerfect 5.1 user.
High-level language has its place, and when coded well, can perform as well as you need it to.
This is security by obscurity in the same way that chaff released to confuse a radar system is. You obscure a target so that attacking it with your primary mode of attack is no longer profitable.
In other words, as many others have said, it's another layer of protection. I certainly wouldn't leave my network unsecured behind such a fuzz curtain.
Just think of this as a form of radar jammer. It doesn't stop you from looking for the target. It just makes one of the easier ways of doing so hard.
It works with the binary representations, but on
many (most?) contemporary architectures (such as x86 and I &think* PPC, MIPS, Sparc and Alpha), the FP and integer register files are separate. Integer ops won't operate on values held in the FP register file. As a result, you actually have to store/reload the value through memory or issue a special move before you can apply the XOR.
Once you start issuing moves just to be able to do the XOR, the whole point is lost.:-) Unless, of course, all the values are in memory already anyway, in which case, you can
use the moral equivalent of an unsigned * to do your dirty work.
Of course, the three-variable version (the one
that uses a temp variable) is probably faster on modern machines, as the three-XOR version has a serial dependence that forces it to take 3 cycles.
The temp-variable version can go as fast as 2 cycles on a multiple-issue machine, or on an explicitly parallel machine, 1
cycle if the compiler realizes it can optimize one of the moves away in one of the later scheduling
passes.
I'm thinking along the lines of the following sequence being executed on a multi-issue machine. (The '||' indicates instructions issued in parallel.)
MV A, T MV T, B || MV B, A
And in the case where the compiler can allocate 'T' and 'A' to the same register on an explicitly-scheduled machine, the sequence
becomes simply:
Personally, I find the terms "young man" and "young lady" much more demeaning, because they're usually used in the same context where your folks would call you by your full given name: When you're in trouble and are getting a talking to by your superiors.
I'd rather be called "just one of the boys" than
"just one of the young men." Ick.:-P
You might try generating assembler dumps from
the compiler. (With GCC, use -S to specify
assembly output rather than object code output.)
Then you can do a textual diff to see where the
differences are.
Another possibility (grasping at straws here) is that
the various symbols in the file were inserted into
the memory map in symbol table order, and the
symbol table's structure may be slightly different
if the file's name changes. For instance,
the symbol table is some self-balancing structure like an AVL tree, but the dump order is by level or pre-order, or something, and so the insertion
order and exact list of symbols can make a
difference in the ordering, even if some symbols
don't generate entries in BSS or on the stack.
Really, for repeatability, you want something
that's static with respect to the number.
That is, I can always look at the number and
tell you how it will be rounded, with no external
memory biasing the decision. Otherwise, it
becomes impossible to programmatically compensate
for the bias in the places where it matters.
Link order may depend on the alphabetical ordering of files, so you may end up with some initialization-time weirdnesses.
I seem to recall the way the Linux kernel walks through driver initializers is link-order dependent, so your driver might be dependent on some other driver whose name comes after kybd but before pskybd.
Having the binary files differ means nothing -- some of the metadata in the object file will include the source filename, and the two source files names differ. Also, if any macros you
used have a reference to __FILE__,
you could get some differences there too.
--Joe
Re:Round to even is not expensive
on
Pet Bugs?
·
· Score: 1
Ack! Damn small text-box. I missplaced a paren
in the "round-to-even" code:
It's little question in my mind which one is
the most expensive, at least in software.:-) Also, as hardware is unlikely to actually use a lookup table, I'd imagine the hardware cost is similar as well.
As an aside, when I have performance-critical code which needs to do a lot of rounding, and the slight bias of "round up" gets in the way, I've sometimes eliminated the bias by setting half
my rounding terms to "1 << (N - 1)" and
half to "(1 << (N - 1)) - 1", effectively making half my rounds "round 0.5 up" and half "round 0.5 down." My IEEE-1188 compliant IDCT implementation does this -- the
IEEE-1188 spec is sensitive enough to pick up the slight bias.
It's a problem in base-2 also. Base-5 wouldn't
have the problem, though.
Base-3 for computers would solve the problem. Apparently, in the very early days of computing
there was some
interest in base-3, although it never
took off.
You could represent base-3 with -1, 0, 1. This
is called balanced ternary notation.Quantum computers may end up using
that variant of base-3. (I wish I could find a better quantum computing link. One of my former coworkers was doing his PhD on this stuff, and it was really quite fascinating.)
Slashdot Mirror
Shhhh! Don't tell that to these guys:
...or...
Also, from what I understood, the WordPerfect Corporation actually required that all programs be written in assembler. BTW, some more interesing WP history.
Oh, you mean, you wouldn't use assembler to write a word processing suite nowadays. Ok, I getcha. Yeah, I think you're right. After all, WordPerfect Corp has been out of business for how long? (Well technically, bought out and resold, and resold... They're just a name now.)
--JoeAdmit it: You've never done any significant calculations in hexadecimal on that calculator, have you?
I say this as an owner of an HP48SX and HP48GX, and a former owner of a Casio w/ dedicated A-F buttons: The HP sucks at the tasks the poster asked about. Not only do you have to hit alpha-lock to get the A-F on the HP (every time you enter a hex number), but you also have to remember to provide the correct prefix. Further, "integers" won't mix at all with "regular numbers" without going through that annoying "B->R" and "R->B" crap.
Do NOT get an HP48 for the tasks the original article was asking about. And I say this as a happy HP48 owner who loves RPN. You get used to the quirks, maybe, but they're frustrating. I'd rather use 'bc'.
--JoeStill, you wouldn't know why the compiler is better than you are without understanding the principles behind the eventual assembly language.
Compilers do many tricks, but often times they need help from the programmer to know it's safe to do them. For instance, knowing minimum trip counts, pointer alignment, pointer aliasing information and so on can help a compiler dramatically, especially if such information is not immediately obvious from the code but is necessary to enable a class of optimizations.
Another factor is the type of architecture involved, and the delta you're willing to live with. I estimate that on most compute-intensive loops, GCC for x86 is off from my most-optimal hand code by as much as 50% (meaning, it runs half as fast, or takes twice as long as my code). For nearly anything I write on x86, that's perfectly acceptible and I don't write a single line of x86 assembly. In contrast, in DSP space, where cycle counting is a way of life, our compiler gets to 80% to 90% of hand-code performance on most of those compute-intensive codes, but we still hand-code. Why? Because those inner loops are 80% to 90% of the total run time and it can make the difference between 90 channels and 100, and that translates into $$. (Alternately, it can mean the difference between making a realtime deadline or not, which is even more important.)
Elsewhere, you said: "Claiming that you can do better on a small domain of the problem is a misleading anecdote." I don't think it's particularly misleading. I know better than to spend my time coding large stretches of branchy control code, but I also know that I could easily beat the compiler if I chose to do so. Only, it could take me days or weeks to get something that runs well as compared to minutes with the compiler. And that's why we have the compiler. :-)
Assembly is for the hotspots. You need to understand assembly to understand why the hotspots are hot and what to do to cool them off a bit.
--JoeI find that such students tend to reach a plateau in terms of accomplishments fairly quickly. Of course, it all depends on the nature of your job as to whether that really matters.
<cynic> At the very least, vo-tech kids are cheaper, and will probably want to leave for a different job in a few years, so the labor cost is lower. </cynic>
--JoeI was clarifying where I think the perspectives themselves originate. One's perspective at a college should be towards getting broad, adaptable skill sets. One's perspective at a vo-tech school should be towards getting an immediate means to an immediate end.
Students who go into college just looking for "vo-tech on steriods" often don't like where they end up, since what they really get is at most "really expensive vo-tech school."
(And when I say "vo-tech" I include places like DeVry and ITT Tech and most junior colleges.)
--JoeFunny you should mention VLIWs, since the DSPs I program (the TMS320C6000 family) are VLIW. They're actually much closer to traditional VLIW than Intel's IA-64.
Compilers can produce much more "pretty good" code than any human could (without going insane, at least), in a much, much shorter period of time. But I've never yet had the compiler beat me on size and speed simultaneously on any individual calculation-intensive function I've coded by hand. (It'll beat me very occasionally by a couple cycles at a large cost in size.) This is not because the compiler's bad at what it does. TI actually has one of the better optimizing C compilers out there, at least in the embedded space. (Disclaimer: I work for TI.)
The real difference, I think, comes from the assumptions the compiler can't make but that the programmer can. The semantics of the C language get in the way of performance sometimes. Pointer rules cause dependences where you don't expect them, alignment issues frustrate SIMD optimization, etc. When you code in assembly language, What You See Is What You Get, exactly.
--JoeOne thing I've noticed in the comments attached to this article is the repeated question: "Is assembly still relevant?" As someone who codes assembly on a regular basis, I must shout an unequivocal YES.
It's relevant on many levels. First, as another posted has pointed out, learning assembly is very similar to an EE learning circuit theory: To really understand the aggregate effects, you sometimes need to understand the details. Now, one could counter "But Physics isn't taught that way!" You're right, but then Physics 1 (kinematics) and to a large extent, Physics 2 (electricity and magnetism) is much more concrete than anything you'll ever learn programming-wise. Also, the "approximations" provided by Newtonian mechanics fairly accurately describe nearly all of what most of us will ever interact with. The rest of us take one or more Modern Physics courses that cover quantum mechanics and all the other nitty-gritty.
On another level, it truly does allow you to get away from the noise of the language and concentrate on what the machine really does. I've seen so many people that are so out-of-touch with their code, it's unreal. Even in C, it's easy to write code with way-too-much hidden complexity. If you understand assembler, though, you're more likely to think about the true cost of each action. At the very least, you're much more likely to be able to compile to assembly output and actually understand what you're looking at.
I work in embedded systems, and in that space, assembly language hasn't died. I program DSPs for a living. While high-level languages are continuing to absorb ever larger chunks of code in this space, it seems as though assembly will still always rule the tight loop. If nothing else, it's an invaluable measuring stick for knowing just how close or how far from ideal you really are.
So in summary, assembly language is still relevant. It's the only way to truly be demystified about how your code actually gets executed. And it's a great way to get programmers thinking about all the levels of abstraction when the time comes.
--JoeAre you at a college or a vo-tech school? If you learn the principles of programming, then the language doesn't matter so much after awhile. You need to learn different programming paradigms, but once you do, then the specifics of syntax aren't as big a deal.
At a vo-tech type of school, you're there to pick up specific skills to allow you to target a narrow range of jobs. At a college, you're there to pick up general skill sets and ways of thinking about problems that can be adapted to many jobs.
I consider understanding assembly language to be one of the basic fundamental concepts that helps unify all the abstractions we heap on top of it. If programming languages always just seem like magic to you, you'll never truly understand what you're doing. Good luck generalizing what you learn if you don't know what your code looks like on a couple different levels of abstraction.
--JoeTell that to the now-defunct WordPerfect Corporation that couldn't make the jump to Windows cleanly because of the mandatory "everything in assembly language for speed and size" coding rules there.
And I say this as a former die-hard WordPerfect 5.1 user.
High-level language has its place, and when coded well, can perform as well as you need it to.
--JoeThis is security by obscurity in the same way that chaff released to confuse a radar system is. You obscure a target so that attacking it with your primary mode of attack is no longer profitable.
In other words, as many others have said, it's another layer of protection. I certainly wouldn't leave my network unsecured behind such a fuzz curtain.
Just think of this as a form of radar jammer. It doesn't stop you from looking for the target. It just makes one of the easier ways of doing so hard.
--JoeIt works with the binary representations, but on many (most?) contemporary architectures (such as x86 and I &think* PPC, MIPS, Sparc and Alpha), the FP and integer register files are separate. Integer ops won't operate on values held in the FP register file. As a result, you actually have to store/reload the value through memory or issue a special move before you can apply the XOR.
Once you start issuing moves just to be able to do the XOR, the whole point is lost. :-) Unless, of course, all the values are in memory already anyway, in which case, you can
use the moral equivalent of an unsigned * to do your dirty work.
--JoeNot on modern 2s complement machines with well defined wraparound on overflow. The overflow will be followed by compensating underflow.
--JoeGo try it with float or double from C and tell me how well it works. :-)
No fair cheating and using a union to do it either.
--JoeOf course, the three-variable version (the one that uses a temp variable) is probably faster on modern machines, as the three-XOR version has a serial dependence that forces it to take 3 cycles. The temp-variable version can go as fast as 2 cycles on a multiple-issue machine, or on an explicitly parallel machine, 1 cycle if the compiler realizes it can optimize one of the moves away in one of the later scheduling passes.
I'm thinking along the lines of the following sequence being executed on a multi-issue machine. (The '||' indicates instructions issued in parallel.)
And in the case where the compiler can allocate 'T' and 'A' to the same register on an explicitly-scheduled machine, the sequence becomes simply:
Can't do that with the three-XOR version.
--JoePrecisely. And xfig even makes it easy! (Hint, use 'update' on a compound object.)
Or, if you're boring and code-inclined:
curr = head;
while (curr)
{
-
next = curr->next;
}curr->next = prev;
prev = curr;
curr = next;
head = prev;
Does that look right?
--JoePersonally, I find the terms "young man" and "young lady" much more demeaning, because they're usually used in the same context where your folks would call you by your full given name: When you're in trouble and are getting a talking to by your superiors.
I'd rather be called "just one of the boys" than "just one of the young men." Ick. :-P
--JoeAnd what happens when you have English and Hebrew text on the same page? Or vertically oriented Asian text? Do I get scroll bars on every edge? :-)
--JoeDoesn't it default to ,1,0?
And yes, I think ",8,1" leading to "PRESS PLAY ON TAPE" is just a bit odd...
--JoeYou might try generating assembler dumps from the compiler. (With GCC, use -S to specify assembly output rather than object code output.) Then you can do a textual diff to see where the differences are.
Another possibility (grasping at straws here) is that the various symbols in the file were inserted into the memory map in symbol table order, and the symbol table's structure may be slightly different if the file's name changes. For instance, the symbol table is some self-balancing structure like an AVL tree, but the dump order is by level or pre-order, or something, and so the insertion order and exact list of symbols can make a difference in the ordering, even if some symbols don't generate entries in BSS or on the stack.
--JoeReally, for repeatability, you want something that's static with respect to the number. That is, I can always look at the number and tell you how it will be rounded, with no external memory biasing the decision. Otherwise, it becomes impossible to programmatically compensate for the bias in the places where it matters.
--JoeLink order may depend on the alphabetical ordering of files, so you may end up with some initialization-time weirdnesses. I seem to recall the way the Linux kernel walks through driver initializers is link-order dependent, so your driver might be dependent on some other driver whose name comes after kybd but before pskybd.
Having the binary files differ means nothing -- some of the metadata in the object file will include the source filename, and the two source files names differ. Also, if any macros you used have a reference to __FILE__, you could get some differences there too.
--JoeAck! Damn small text-box. I missplaced a paren in the "round-to-even" code:
Also, the unbiased rounding should be either:
Or
Talk about a brain-fart. I had mentally combined the two, giving "extra biased rounding".
--JoeThe main place I come across it is in fixed-point computations. Suppose I'm rounding away N bits of a number. Pure truncation is simply:
Traditional rounding (round 0.5 up) is:
Unbiased rounding is like so:
Round-to-even is:
It's little question in my mind which one is the most expensive, at least in software. :-) Also, as hardware is unlikely to actually use a lookup table, I'd imagine the hardware cost is similar as well.
As an aside, when I have performance-critical code which needs to do a lot of rounding, and the slight bias of "round up" gets in the way, I've sometimes eliminated the bias by setting half my rounding terms to "1 << (N - 1)" and half to "(1 << (N - 1)) - 1", effectively making half my rounds "round 0.5 up" and half "round 0.5 down." My IEEE-1188 compliant IDCT implementation does this -- the IEEE-1188 spec is sensitive enough to pick up the slight bias.
--JoeIt's a problem in base-2 also. Base-5 wouldn't have the problem, though.
Base-3 for computers would solve the problem. Apparently, in the very early days of computing there was some interest in base-3, although it never took off.
You could represent base-3 with -1, 0, 1. This is called balanced ternary notation. Quantum computers may end up using that variant of base-3. (I wish I could find a better quantum computing link. One of my former coworkers was doing his PhD on this stuff, and it was really quite fascinating.)
--JoeThat only works in C++, I'm afraid. C only supports pass-by-value (the first one), and explicit pass-by-reference (the third one).
--Joe