Assembly is used for?

[KalebG]

I've been searching around the site, looking at the different types of coding, and come accross Assembly. This is one of the most complicating code ive seen yet and was just wondering what is it's most common use?

[pty]

I've been searching around the site, looking at the different types of coding, and come accross Assembly. This is one of the most complicating code ive seen yet and was just wondering what is it's most common use?

Assembly language is a very low level language.

It is very fast but very complex (therefore generally takes longer to write) and these days tends to be used where massive optimisation is required (a number-crunching algorithm) or in drivers and stuff where it has to interact directly with hardware.

[KalebG]

Assembly language is a very low level language.

It is very fast but very complex (therefore generally takes longer to write) and these days tends to be used where massive optimisation is required (a number-crunching algorithm) or in drivers and stuff where it has to interact directly with hardware.

Ah, ok thanks.

[akyprian]

This is completely wrong! Assembly language is very easy ;) and can be used to develop any kind of application. Have a look at this article and visit the WinAsm Studio site for a lot of free open source tools written in Assembly.

Regards,

Antonis Kyprianou

[Purple Avenger]

The Space Shuttle's cockpit displays/keypad processors (an IBM SP0) were programmed in assembler as was its Heads Up Display(HUD) symbology processor (Hughs A10INS processor)

All of the kernel (and the vast majority of stock drivers and TSR's) for plain old DOS were written in assembler too.

[mathematician]

True, it can be used to develop any kind of application, but what would be the point when a high or middle level language can do the job just as well (and more quickly)?

[akyprian]

Assembly Language can produce small and very fast applications, no bloat, no dependencies (huge dll's), VERY easy to develop and above all, I can do anything I want without facing any HLL limitations.

Microsoft Macro Assembler (MASM), for example, looks VERY similar to C code and is no harder to learn. I would say that it is easier.

Regards,

Antonis

[mathematician]

Assembly Language can produce small and very fast applications, no bloat, no dependencies (huge dll's), VERY easy to develop and above all, I can do anything I want without facing any HLL limitations.

Microsoft Macro Assembler (MASM), for example, looks VERY similar to C code and is no harder to learn. I would say that it is easier.

Regards,

Antonis

There is nothing wrong with the speed of today's optimising compilers. Entire operating systems are written in C, including both Windows and Linux - 95% of the source code anyway. What are the HLL limitations nowadays? Operating system API's are written with C in mind, and directly programming the hardware is out of the question in multi-tasking environments such as Windows and Linux.

[jbennet]

Assembly is very fast. common uses are bootloaders, compilers, embedded systems

[akyprian]

There is nothing wrong with the speed of today's optimising compilers.

No compiler can produce faster binaries than what assembly can do (written correctly offcourse)

Entire operating systems are written in C, including both Windows and Linux - 95% of the source code anyway.

still remains a 5%. why should I use C and assembly while I can be equally productive using assembly only.

What are the HLL limitations nowadays?

Try to write a multithreaded application in VB6 or lower (I don't know about other versions, I never touched any), or a debugger, a large file edit control or ... You 'll fail. Try to use pointers with VB. You 'll be wasting your time (although it is possible).

Operating system API's are written with C in mind

You can call equally easily these API's with Assembly (and written correctly, the binary WILL be faster)

and directly programming the hardware is out of the question in multi-tasking environments such as Windows and Linux.

Although I don't usually do this kind of stuff, why not?

Regards,

Antonis

[pty]

This is completely wrong! Assembly language is very easy ;) and can be used to develop any kind of application. Have a look at this article and visit the WinAsm Studio site for a lot of free open source tools written in Assembly.

Regards,

Antonis Kyprianou

Assembly is very useful in some cases but writing large complex applications in it is crazy. It takes longer and is more difficult to write and is harder to debug than higher level languages and apart from in places that need a lot of optimisation it doesn't offset the extra time spent in development.

[mathematician]

Although I don't usually do this kind of stuff, why not?

Because between them the operating system and the processor's protection mechanisms will stop you. If you did try, your program would most likely get itself closed down. You cannot have two or more apps fighting for direct control of one and the same printer (for example).

[Purple Avenger]

True, it can be used to develop any kind of application, but what would be the point when a high or middle level language can do the job just as well (and more quickly)?

More quickly? Perhaps.

As well? No. I can beat any compiler on speed or space optimizations. One of the biggest problems with compilers is they must implement the semantics of the language. Those semantics never map optimally to any particular architecture.

ex. on x86 I've never seen a compiler pass a bool flag to a function using the carry flag. They all waste time pushing a stack var, or blow a register.

None of them know how to do extreme space optimizations.

[akyprian]

@pty:

Assembly is very useful in some cases but writing large complex applications in it is crazy.

Who told you so? Having the right tools it is easier. Do yourself a favor get the right tools and try 32-bit assembly for a couple of days.

It takes longer and is more difficult to write and is harder to debug than higher level languages and apart from in places that need a lot of optimisation it doesn't offset the extra time spent in development.

I insist. Just try it for a while. With assembly, you debug what you write and not what the HLL (such as VB) wants!

@mathematician:

Because between them the operating system and the processor's protection mechanisms will stop you. If you did try, your program would most likely get itself closed down. You cannot have two or more apps fighting for direct control of one and the same printer (for example).

There is a misunderstanding here; I would write a driver in Assembly to do this.

Purple Avenger you are right for all but, believe me, having the right tools, you can write assembly code quickly. For example, intellisense of both VB, Visual Studio etc IDE's are well behind intellisense of some Assembly IDE's I know of.

Regards,

Antonis

[pty]

@pty:

Who told you so?

Me. I did it for a couple of modules at uni. It was fun to learn and create simple programs but thats it.

Obviously you will blow the trumpet of it as you are linked to some IDE. I'm not saying its a bad thing. In some cases (as I've mentioned before) its very good and fast, but for every day development it just isn't productive.

[akyprian]

Yes I 've developed the free IDE because I had believed in Assembly and not the other way round! Please bear in mind that I 've programmed with some HLL's for years before that. And yes, I was not productive with every language I tried.

Regards,

Antonis

[jbennet]

im learning assembly next year at college so its obviously still a good language

[hollystyles]

unfortunately developers don't invest in technology, business does and business is interested in return on investment. Don't be fooled by open source it's no different, open source is an attempt by business to commoditize software, so it can sell more hardware not satisfy selfless moral ethics. Developers tend to be ethical purists, but purism isn't economic. A developer should be productive in any language, if you understand the theory of computation you're good to go that's the skill, syntax and libraries are just semantics. It doesn't matter what you say, if you build up from assembly, or bolt together with the highest level languages the result is a huge upside down pyramid of extrapalation before you get to anything saleable that invariably falls over..a lot! an individual part built low level maybe perfect - such as a driver - but on it's own without a monolithic OS to serve it's economically a dead duck. The whole thing is pretty shaky if you ask me and we rely on it in every facet of daily life...role on the quantum CPU Then we'll be cooking on gas!

[mathematician]

More quickly? Perhaps.

As well? No. I can beat any compiler on speed or space optimizations. One of the biggest problems with compilers is they must implement the semantics of the language. Those semantics never map optimally to any particular architecture.

ex. on x86 I've never seen a compiler pass a bool flag to a function using the carry flag. They all waste time pushing a stack var, or blow a register.

None of them know how to do extreme space optimizations.

Anybody who writes a memory resident debugger, which can randomly interrupt the execution of a program at any point, will soon discover that the average app spends about 90% of its time executing operating system code. Therefore it can be as fast as the OS, and no faster.

[jbennet]

have u guys tried menuetn os?

a whole os in assembly. its got a GUI and is under 5 meg

[mathematician]

have u guys tried menuetn os?

a whole os in assembly. its got a GUI and is under 5 meg

No, but then there are more OS's out there than you can shake a stick at.

[Purple Avenger]

Anybody who writes a memory resident debugger, which can randomly interrupt the execution of a program at any point, will soon discover that the average app spends about 90% of its time executing operating system code. Therefore it can be as fast as the OS, and no faster.

Its a very bold (and 100% wrong) assumption that all computer systems have an OS or one that they're CPU bound upon.

You seem to be a very GUI/desktop centric person. I assure you, there's a whole world out there you've never seen.

You seem to hold the guts of an OS as some sort of impenetrable black box who's will we a simply subject to. Having spect a significant portion of my career in the guts of OS's and drivers, I can state this is not the case, and the cure for performance issues in OS's is often assembler code. In fact the guts of the OS/2 kernel were virtually all assembler with few exceptions (HPFS was mostly C). Run OS/2 on anything and compare it to Windows or Linux in terms of speed and responsivness. There is no comparason. All that assembler code beats the crap out of the C code systems.

[Purple Avenger]

have u guys tried menuetn os?

a whole os in assembly. its got a GUI and is under 5 meg

OS/2 1.3 would run on a machine with well under 3M of memory, and the whole system shipped on about 8 or 9 1.44M diskettes (including display/printer drivers).

[Colin Mac]

Electronic Engineers use Assembly to program microcontrollers, used in just about everything like cars, microwaves, washing machines etc.

[akyprian]

Anybody who writes a memory resident debugger, which can randomly interrupt the execution of a program at any point, will soon discover that the average app spends about 90% of its time executing operating system code. Therefore it can be as fast as the OS, and no faster.

And YOUR conclusion is: no matter what language you use or what code you write, final binaries will have the same speed ...

My conclusion: Assembly language can produce by far the fastest and smallest binaries, it is as easy (or difficult) as any other programming language. One can be AT LEAST as productive as can be with any other language because he/she will not be fighting with the HLL's limitations.

Antonis

[mathematician]

Its a very bold (and 100% wrong) assumption that all computer systems have an OS or one that they're CPU bound upon.

You seem to be a very GUI/desktop centric person. I assure you, there's a whole world out there you've never seen.

You seem to hold the guts of an OS as some sort of impenetrable black box who's will we a simply subject to. Having spect a significant portion of my career in the guts of OS's and drivers, I can state this is not the case, and the cure for performance issues in OS's is often assembler code. In fact the guts of the OS/2 kernel were virtually all assembler with few exceptions (HPFS was mostly C). Run OS/2 on anything and compare it to Windows or Linux in terms of speed and responsivness. There is no comparason. All that assembler code beats the crap out of the C code systems.

Most people aren't involved in writing operating systems - they are involved in writing apps. As it happens, the operating system I was referring to, with apps spending 90% of their time inside it, wasn't a GUI system.

Personally, I hadn't noticed Windows graphics being particularly slow; we are no longer in the age of 4.77MHz PC's, where every last clock cycle counted.

[Purple Avenger]

we are no longer in the age of 4.77MHz PC's, where every last clock cycle counted.

That's why I'm reading Vista's hardware requirements are massive right?

I have more respect for your time than you do.

[Ancient Dragon]

And YOUR conclusion is: no matter what language you use or what code you write, final binaries will have the same speed ...

Not so -- bad compilers or unoptimized code will produce slower binaries. Different compilers will produce very different binaries (*.exe) even with the same source code. That is one of the bench mark test that many companies perform on compilers.

My conclusion: Assembly language can produce by far the fastest and smallest binaries

Yes it could, but whether it does not not is highly dependent on the skills of the programmer.

One can be AT LEAST as productive as can be with any other language because he/she will not be fighting with the HLL's limitations.

Totally agree with that statement. Assembly language is the LEAST productive of all languages (except machine language of course). Which is why no one writes anything but trivial programs in assembly language. Assembly is nice to know for all programmers, but not very useful for anyone other than those who design write compilers or operating systems.

[Purple Avenger]

why no one writes anything but trivial programs in assembly language.

I assure you the OS/2 kernel, KBD, MOU, VIO, and base drivers code was non-trivial. It was all done in assembler.

In the 1.X and GA 2.0 version the PM graphics engine was assembler as well. The VGA and 8514 drivers was all assembler and large chunks of the XGA driver were assembler.

Gibson claims everything he does is assembler. don't know if that's true or not, but its what he claims.

I've got a 100,000 LOC test suite for the DOS Int 21 API that's done all in assembler.

[akyprian]

Not so -- bad compilers or unoptimized code will produce slower binaries. Different compilers will produce very different binaries (*.exe) even with the same source code. That is one of the bench mark test that many companies perform on compilers.

Fully agree. This is why I use Assembly for all my programming needs. What I write is what my final binary will be. It 's only up to me to write good or bad code.

Yes it could, but whether it does not not is highly dependent on the skills of the programmer.

other things being equal, Assembly binaries are by far faster and smaller.

Assembly language is the LEAST productive of all languages

If one writes 'real' applications and not toys is sure that it is the other way round. I am wondering, what kind of applications we are talking about.

not very useful for anyone other than those who design write compilers or operating systems

speak for your self! I write mainly 32-bit applications for windows and I am VERY productive.

I am really wondering why one spends his time in an Assembly forum trying to persuade people that they are not productive! I hope it doesn't sound like and ad, my site (and many others) is a proof of what I am saying.

Antonis