1.Assembler is unportable.
2.Assembler is hard to learn.
3.A compiler can be as fast as assembler.
4.Code is harder to debug within assembler.
5.Assembler does not allow high-level constructs.
6.Assembler requires writing many times more code.
7.Assembler does not support abstraction.
9.You need to know the inner workings of a CPU to write best assembler.
10.Assembler lacks libraries or cannot use foreign interfaces.
9-10 i can maybe see
But how is assembler (other than LLVM 'assembler') portable? I mean you can PORT it, but it's less portable than pretty much anything else.
>>4
The pro-sepples and pro-assembly contingent of the programming world are wrapped in several impenetrable layers of retardation and symptoms of Asperger syndome. This makes them immune to things like logical arguments, sarcasm, irony, metaphor, and other tools most decent folk have at their disposal.
Name:
Anonymous2010-07-13 10:29
>>5
Everything worth of value is written in C/C++ with ASM.
VM, OSes, Games, Compilers, Interpreters,etc.
1. /prog/ is useful.
2. /prog/ is helpful.
3. /prog/ is worth reading.
4. There are programmers in /prog/.
5. /prog/ members had read SICP.
6. /prog/ accept newcomers.
8. /prog/ will solve you're homework.
9. /prog/ will never troll you.
10. I wrote 10 /prog/ myths.
>>7
No it isn't.
∵ We've had this exact thread before.
∴ /prog/ dumbness is constant, increasing as it may be.
∎ Quid ferret pro ipso stat dolorem vectra demonstratorium.
1.Assembler is unportable.
About as unportable as the CPU's standard. It's unportable unless you write for a VM, or someone has a CPU emulator or recompiler. It's still one of the less portable things out there. 2.Assembler is hard to learn.
It's easy to learn, but it may be hard to master (so you can write high-level things in it with ease). 3.A compiler can be as fast as assembler.
Theoretically true, practically not true. It's only as true when using an ideal compiler, which provably doesn't exist. This doesn't mean that giving up some 1-3x times the speed to get a much more manageable language is not worth it. 4.Code is harder to debug within assembler.
It's easy using a good debugger, but it's also more verbose. Certain high-level debugging facilities would be hard, if not impossible to implement. Low-level debugging will be fine. 5.Assembler does not allow high-level constructs.
Macro-assemblers allow you that to some extent, but usually you won't go as far as having them do register allocation for you too. Go too far with macro-assemblers and your code could end up less efficient than compiled code. 6.Assembler requires writing many times more code.
Yes and no, it depends on the programmer. Macro assemblers and proper functional abstraction can reduce the amount of code duplication. 7.Assembler does not support abstraction.
Any language supports it. If it's too tough, you build yourself a better compiler or assembler.
Where's point 8?
9.You need to know the inner workings of a CPU to write best assembler.
A well-written documentation of the CPU's instruction set along with performance characteristics is usually enough. Some CPU companies also offer optimization guides which expose some inner workings where they affect optimization choices. 10.Assembler lacks libraries or cannot use foreign interfaces.
If you know the calling convention, you can call/use anything. When I need to call something with unusual calling conventions I have to write assembly myself. You can use any existing C library as well as most other libraries, if they offer some sort of way to link to them or access them externally.
I'm not even sure where these myths came from OP? I've never heard of some of them. The reason not to use too much assembly is because high-level languages offer much more portable (across CPUs/OSes) ways to do things, their speed is usually acceptable, and their flexibility/features is greater. Using assembly is required for certain things which your language/implementation may not be able to do natively. If you want abstractions, a compiler will be able to optimize your code, while an macro assembler usually won't do it.
tl;dr: Use the right tool for the job.
Name:
Anonymous2010-07-14 6:02
1.Assembler is unportable.
true unless I see asm library from ARMv7 that could be compilerd on my AMD64 out of the box.
2.Assembler is hard to learn.
Never heard such claim. Actually it's easier to learn than C, because pointers are much more natural in it.
>3.A compiler can be as fast as assembler.
Depends on algorithm, CPU, asm coder, seeples coder. Sometimes it can be faster.
>4.Code is harder to debug within assembler.
>5.Assembler does not allow high-level constructs.
Show me debugger that allows debugging of high-level constructs(it is required to run on different platforms of course, see p.1) or remove at least one of these points.
>7.Assembler does not support abstraction.
Buzzwords are buzz.
>9.You need to know the inner workings of a CPU to write best assembler.
>10.Assembler lacks libraries or cannot use foreign interfaces.
Not really.
Name:
Anonymous2010-07-14 6:19
>>1
What the fuck /prog/? It's obvious that you are much more intelligent than /b/, but you still seem to have the same dumb trolling habits of /b/. Whats more pathetic are the asinine posts arguing against him.