Author Topic: NASM versus High-level programming  (Read 7509 times)

Offline joddys

  • New Member
  • Posts: 1
NASM versus High-level programming
« on: March 28, 2015, 12:08:40 PM »
I'd like to know what's possible to do with NASM that not possible with C or other HL language?

Offline shaynox

  • Full Member
  • **
  • Posts: 118
  • Country: gr
Re: NASM versus High-level programming
« Reply #1 on: March 28, 2015, 03:21:00 PM »
Please, add the word: troll, in your title.

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: NASM versus High-level programming
« Reply #2 on: March 28, 2015, 06:44:19 PM »
Hi Joddys,

Thanks for joining us. Don't mind the Bunny - he can't help it.

Nasm, like other assemblers, processes a language which represents, as nearly as possible, the actual machine language of the processor. C and the other HLLs generally avoid anything specific to the processor. Their compilers produce the same machine code - it's the only thing a processor will execute - but they do not attempt to represent it directly.

If you're asking what you "need" Nasm for, if you don't know, you probably don't. Yet... here we are.

Best,
Frank


Offline nasm32

  • Jr. Member
  • *
  • Posts: 25
Re: NASM versus High-level programming
« Reply #3 on: March 31, 2015, 09:12:20 PM »
Whats possible in asm vs HLL, I can think of a few things:

1. You can specialize your code at the instruction level

That really sums up the remaining points I was about to type.

On second thoughts, maybe I can finish the remaining points:

2. You have the chance to write programs at the smallest level, meaning, the absolute smallest level possible.
3. Self modifying code that evaluates instructions as it progresses, not possible in hll.
4. Instruction level optimization in a different way than normal (Optimization in a bizarre way I can't talk about now)
5. Customizing your executable in a more technical way than possible in hll
6. Customizable stack frames beyond the known calling conventions
7. Ability to feed the processor instructions in an order to maximize parallel execution (Between the V and U pipe for example, not possible in hll, only in a very general way)
8. Ability to align code and data in any way using nop or any other byte. In HLL this is somewhat limited.
9. Ability to go outside standards of structure definitions, constants (You can perform instruction level bit tricks on operating system constants to optimize, which depends on the actual instructions being used, not solely on the bits)
10. You get the ability to write a true computer program. A hll language is just a human language, it's not a computer language.
11. You can mix fpu and x86 instructions in a way not possible in hll. Sometimes it doesn't pay off to use pure fpu.
12. You can go beyond the data type "rules" of a hll language and put floating point values inside integer variables and treat that variable as any type you want, which can be beneficial because sometimes you can reuse a variable for other purposes, in a hll language you have to declare a new variable for that, in assembly you can reuse "free" variables for other data types.
13. You can perform arithmetic on an integer and a float at the very same time without "signalling" the compiler to treat it in a fpu register, if you know how floats are made up you can mix it up.
14. You can mess with return values on the stack the way you want to.
15. If a procedure have no locals, you can omit the stack frame, saving at least 8 memory writes every call.
16. In assembly you can write programs for future processors and ship the program before that cpu is on the market.
17. Similarly, in assembly, you can immediately take advantage of future cpu technology that isn't on the market yet.
18. In assembly you will be able to do errors without being corrected by the compiler. There are no annoying parents. Except for your uncle, and he seldom complain about anything but some rare syntax problems, a missing square bracket for example.
19. HLL is absolutely dependent on programs that are compartmented into functions and objects. In assembly, you can code the entire program as one very large and compact "string" and it will still run. (Some may say you can do that in c++ too, but in practice, you can't do that)
20. HLL languages makes you technically blind after awhile. When you look at your data definitions in a hll language, you'll eventually believe that data types actually exist, because you've been staring at it for so long. In assembly you'll learn that data types are just instruction choice. There are no data types, just instructions.
21. In assembly you don't really need a ton of reference, in c++ you live and feed on help files and documents. You eat them for dinner.

It is better understood when you get to understand what C++ actually is. C++ is a very advanced macro system on top of an assembler. When you realize that, you also realize that c++ is a just a very complex macro assembler. nasm is a somewhat complex macro assembler, but not very complex. So anything you can do one layer above, is also possible at one layer below. Anything you can do in a very complex macro system, you can also do on the basis that forms up that macro system, which is the assembler. But vice versa isn't necessarily true.

I almost forgot: And another thing you can do in assembly is to produce much faster code and the reason is usually very understandable; compiling a hll language program and expecting it to become faster than an equivalent assembly program, is like trying to put chinese text into google translate and then expect the end result to become perfect english. It can't become perfect, and that is why we need an assembler, we need it to get perfect translation between chinese and english.

In almost every case I read about why hll language programmers prefer c++, the reasons can be narrowed down to "time being saved" which basically means he makes more money every day than he would if he used assembly.

But that is not an argument in support of claiming that hll is better than assembly. Money-wise, if you're after making money, c++ is better. If you are a technical guy, a programmer, assembly is better. Saying that c++ is better because it makes you code faster is a bad reason. If you are a business man, c++ is better, if you are a programmer, assembly is better. It's just that easy.

It can be better understood if you consider any other fields than programming. If you're a marathon runner and you discover than you'll reach the finish line much faster if you use your car rather than running. Sure, you'll reach the end line faster, but you aren't a marathon runner if you do, and so there are no arguments in the field of marathon. Similarly, using the phrase "money saved" isn't an argument in favor of programming. It has nothing to do with programming.

I could give an example in a case where assembly outperforms hll. Consider nasm and fasm (netwide assembler) and (flat assembler). Nasm is written in HLL and fasm is written in assembly. Nasm's %rep preprocessor performs 100 times slower than fasm's equivalent rep preprocessor directive. Fasm completes a million repetitions in the same time that nasm does 10,000 repetitions. Fasm outperform Nasm by 100 times in their respective preprocessor rep directives.

I don't even have to look at nasm's source code, I know why it produce so much slower code without even looking at it. Because I'm so familiar with computers from my assembly experience, I can pinpoint the problem without even looking at the source code. Let me know and I will tell you why it is slower. (If you're interested)
« Last Edit: April 01, 2015, 01:08:07 PM by nasm32 »

Offline nasm32

  • Jr. Member
  • *
  • Posts: 25
Re: NASM versus High-level programming
« Reply #4 on: April 02, 2015, 10:25:19 PM »
Recently I made a module to add thousand (comma) separators to numeric strings. I can do this in assembly:

1. Add comma separators to a 10 digit long numeric string (Shorter is faster, longer is slower)
2. Calculate the length of the string
3. Write the comma separators numeric string to a new string (not back to the old string)

All these three steps is complete in 7 nano seconds.

And I haven't optimized it fully yet. It would be interesting to see how much faster an equivalent c++ program can do it. If you do, report back to me. No simd operations and 32-bit.

Offline Logman

  • Jr. Member
  • *
  • Posts: 16
  • Country: us
Re: NASM versus High-level programming
« Reply #5 on: May 16, 2015, 03:52:11 PM »
Nasm32,

I just read your post on assembly language. I've never timed nasm vs fasm and didn't realize there was such a speed differential. Does fasm compile faster or is the actual code faster?

Logman
« Last Edit: May 16, 2015, 03:53:55 PM by Logman »