When To Use Assembly Language

[Gary Beene]

My posted on the Hi/Lo function got somewhat highjacked, but it turned into a topic of interest to me so I wanted to start a new thread on it.

MCM's last remark - are there examples of where PowerBASIC compiled code does not result in performance as good as most assembly language programmers might provide - is a good question. I think that question specifically referred to the use of assembly language where PowerBASIC statements already exist to do the job.

The other question would be if there things assembly language could do, that can't be done via PowerBASIC statements.

I'm not an assembly language programmer but have wondered when would I use it, even if I could? The two question above are at the core of the issue, and would help me decide if I wanted to take the time to learn more about assembly language.

I know that in an earlier post of mine, where speed was an issue, pointers and assembly language were very fast - comparably so. I walked away thinking that a clever PowerBASIC programmer generally need not turn to assembly language.

But, the door is open - when should a PowerBASIC programmer turn to assembly language? Is there a class of problems for which the PowerBASIC language needs a boost, or where assembly language is a natural, unique solution? It's a PowerBASIC feature, so somebody must think so!

I'd guess the answer is that the need is there, but generally under rare circumstances. But that seems counter to the number of times that assembly language solutions have popped up in the forums, so I guess it's time for me to ask the question.

[Paul Dixon]

Gary,
ASM is just a tool to be used whenever you see fit.
The obvious time to use it is when you need speed. If BASIC isn't fast enough then ASM will always be faster (except for really trivial things) although it may still not be fast enough.
Often ASM makes source code more difficult to follow or maintain but sometimes it makes it easier, especially when doing low level stuff like handling bits and bytes and doing certain jobs that the CPU happens to have built in functions for which aren't repeated in BASIC.


Paul.

[Barry Marks]

I'm not an assembly language programmer but have wondered when would I use it, even if I could? The two question above are at the core of the issue, and would help me decide if I wanted to take the time to learn more about assembly language.

My guess, and it's only that, is that these days you'll rarely need to use assembly in a program unless you're doing something specialized like making a high-performance game. If you don't already feel a need for it in the programming you do you probably don't have a need to use it.

However, there's another very good reason to learn assembly. Assembly is about how the computer works. You can't really understand how things happen in a computer until you know how the CPU works and that's what you learn when you learn assembly. It makes you a better programmer in any language you happen to be using.

In a number of jobs I was the only programmer who knew assembly and overall I was rarely the best or smartest programmer. But I was always the one they came to when they couldn't figure out why something worked the way it did because I knew how to find the answers they couldn't. That was because of my assembly experience.

So my suggestion is that if you're the least bit inclined to learn assembly, learn it. You'll be glad you did. If you don't want to, don't. A lot of good programmers don't know anything about assembly. Frankly that always puzzles me a little, but I've seen it enough to know it's true.

Barry

[Brice Manuel]

Gary, I deal with platforms daily, where ASM is the only choice for programming.

[Gösta H. Lovgren-2]

Gary,If you want to learn assembler, here's a very good place to start: http://www.masm32.com/board/index.php?

======================
Bad literature …
is a form of treason.
Joseph Brodsky
======================

[Gary Beene]

Paul's two comments are at the core of my question.

ASM is just a tool to be used whenever you see fit.
The obvious time to use it is when you need speed.

Since I don't program in assembly language, I'm asking when other programmers "see fit".

Speed is often quoted as when "see fit" applies - but what I haven't seen is a consensus that the PowerBASIC compiler falls short of optimizing code, to the extent that assembly language would routinely/obviously provide better speed.

If it is true, that's fine with me, I'm just trying to understand what programmers have actually seen in the way of results. I've seen comments that the PowerBASIC compiler is very efficient, providing assembly language speed. And I've seen posts suggesting just the opposite.

I don't really expect any kind of consensus from forum posters. All of the comments are appreciated to the extent that they provide coverage of the various issues to shed some light on the topic.

Based on what I see in the forums, the simple fact that most answers to questions have no assembly language content tells me two things. One, that assembly language is an occasionally used tool for the vast majority of programmers. Two, that most programming solutions don't need the speed or any other assembly language benefit.

Hmmm.... now that I say it that way, it pretty much forces me to restate the question more along the lines of "What unusual problems does assembly langauge lend itself to solving, in a way preferable to the use of PowerBASIC statements.

I'm likely to go ahead and start learning assembly language - in part because I enjoy the learning process, in part because (as Barry said) it is an additional level of learning about computers, and finally in part because I'd like to know enough to be able to apply assembly language whenever I "see fit".

So, everyone, thanks for the responses. I'm off Gosta's suggested site for a starting look. If anyone has a suggestion on another site, or appropriate introductory text, please let me know. Links abound in Google, but personal recommendations from peers are always a good place to start.

[colin glenn]

For playing around in Assembly you may want to try playing with an emulator.
This one here is really retro: 6502

[Brice Manuel]

Since I don't program in assembly language, I'm asking when other programmers "see fit"... but what I haven't seen is a consensus that the PowerBASIC compiler falls short of optimizing code, to the extent that assembly language would routinely/obviously provide better speed...

Where I see fit:

1. Some platforms are assembly only if you want to program for them. There is no other option.

2. PB specific, lets look at a recent thread on sprites and alphablending. James posted some alpha routines that are usable in a very simple game.

What if your game is more complex? This is where we get into the realm of directly accessing specific processor features that may not necessarily be accessible via PB's native commands.

MMX instructions. Back in the days when all CPUs were 32-bit only, MMX provided eight 64-bit registers to play with. Each 64-bit register could be used for a 64-bit integer, two 32-bit integers, four 16-bit integers or eight 8-bit integers. Only capable of integer math. Perfect for 2D and 3D games.

Nice article here on using MMX instructions for alphablending. This article is written by the man who wrote the alphablending for the CDX 2D engine. This is an open source engine and is the same 2D engine Paul Turley uses for his languages. This MMX method makes alphablending usable in realtime for midlevel complex games.

SSE, SSE2, SSE3 and SSE4 instructions are also very handy for certain aspects of gaming.

I seem to remember Bob saying in the old radio interview that some people use PB only for ASM programming (he said something to that effect). With the improved ASM capabilities of 9.0, I would do the same myself.

[Paul Dixon]

The choice is down to the programmer and depends on what you're trying to do and what you're familiar with.
Why choose to use WHILE-WEND rather than FOR-NEXT or DO-UNTIL or even an IF-THEN GOTO? Why use a regular expression rather than standard string functions? And why use ASM rather than BASIC?

The main difference that influences your choice between ASM and BASIC is that ASM tends to take longer to write than BASIC to achieve the same thing but is always faster to run so if execution speed is critical, I always look at using ASM.
Gains for non-trivial code vary widely but 2 to 20 times as fast is usual.


Many Windows programs sit and wait for a user input, do something simple then sit and wait for another input. I wouldn't consider using ASM for that type of program.
But any program requiring intensive CPU use is a candidate for a bit of ASM. Intensive graphics, long maths calculations, scanning long strings of DNA for matches, video processing and more.

I rarely write whole programs in ASM, it's just not necessary. Instead, I use the compiler to handle the bulk of the code and then just target the sections that could benefit most to rewrite in ASM. A few lines of ASM can make a big difference to the overall performance.


While speed is by far the main reason to choose ASM over BASIC, there are other times when ASM is the best choice. Some things are just best done in ASM.
If you write interrupt service routines you have no choice:

http://www.powerbasic.com/support/pbforums/showthread.php?t=547

If you want access to the innards of the processor such as the FPU flags and control registers, you have no choice:

http://www.powerbasic.com/support/pbforums/showthread.php?t=19710

If you want to write your own exception handlers, you have no choice:

http://www.powerbasic.com/support/pbforums/showthread.php?t=37821

And there are a few things where you do have a choice but which are easier to do in ASM than in BASIC.
If you want to find the first bit set in an integer:
BSF and BSR (Bit Scan Forward./Reverse) are single opcodes that do it for you.

If you want to convert a number to BCD, it's built in:

!FILD MyIntegerNumber
!FBSTP The18DigitPackedBCDResult

If you want to do a full 4 quadrant ATAN function, it's built in:

http://www.powerbasic.com/support/pbforums/showthread.php?t=8959

If you want to convert little endian to big endian, it's built in:

!BSWAP eax 'swap the bytes around in the EAX register.

I'd recommend everyone learns a bit of ASM. It's too useful to ignore.

Paul.

[Michael Mattias]

There's always the obvious uses:
1. You already have a complex routine written in assembly language which you want to migrate to your BASIC program, but you don't want to re-invent the wheel

2. You are a better assembly-language programmer than BASIC programmer.

[Paul Dixon]

Gary,

are there examples of where PowerBASIC compiled code does not result in performance as good as most assembly language programmers might provide

Yes. There are various reasons why a good ASM programmer can beat compiled code.
First, the compiled code is the result of someone programming in ASM and there are lots of ways to do it. Sometimes the compiler may not have the best choice of code, other times it might. e.g:

http://www.powerbasic.com/support/pbforums/showthread.php?t=19280

Second, unless you want the language to become very complex and handle every possible situation then, the compiler needs to be written to handle general situations which can always be outperformed by writing an ASM routine to handle a specific case. One example which crops up here from time to time is converting numbers to strings and strings to numbers:

http://www.powerbasic.com/support/pbforums/showthread.php?t=14373

http://www.powerbasic.com/support/pbforums/showthread.php?t=9589

The code posted is much faster than the built in VAL/FORMAT$/STR$ functions but only targets a specific type of input whereas the the built in functions are more general.


Third, hand written ASM is going to beat compiled code because the ASM programmer can make decisions that the compiler can't. e.g. in BASIC you can choose 2 CPU and 4 FPU register variables, In ASM you can have 6 CPU and 8 FPU register variables and vary which variables are in registers throughout the code. In BASIC each part of a long calculation will tend to be stored and reloaded, in ASM you can see which intemediate values are likely to be needed soon and keep them in registers. In BASIC you can't target certain features of the CPU, in ASM you can, such as PREFETCHing data, unrolling tight loops efficiently, avoiding cache polution and using MMX/SSE instructions to access data in parallel.

Paul.

[John Petty]

I agree with all of Paul's statements. That being said, PB produces very efficient code, but here is a real situation that I had to revert to using ASM.
I need to sort UDT's or binary searches in them (millions) when they might need to be sorted by say 5 fields, the first being a long ascending, second a string ascending, third being a double descending, fourth a single ascending and fifth an interger descending. It is possible to convert that combination such that the sort/search functions only need to compare a group of DWORDS thus making it much faster. (caveat, I have not tried the latest complex sort of PB 9 though it still would not help in binary searches)

[Gary Beene]

Thanks everyone. These latest posts have some real meat on which to chew - some very specific examples that help clarify/justify earlier statements.

[Michael Mattias]

(caveat, I have not tried the latest complex sort of PB 9...

If you mean the new ARRAY SORT "USING function" thing, I was excited about it and yes it would enable you to do that multi-key sort fairly easily.

I was disappointed the callback function did not offer an "lparam" value you could pass when you call the sort and receive in each callback, so I sent in a NFS for that.

>though it [new ARRAY SORT assumed] still would not help in binary searches

Huh? Sorting is not the same as searching.

Since a binary search can only be done when the key as a whole is sorted, you could never could search *directly* on your key using a conventional 'binary search.'

However, you could create an additional index sorting your KEY as a whole and use a binary search technique to find things there.. and once you have the key, you have the data.

This actually sounds like kind of a fun project .. but only if you add a restriction that "you can't store the data in any DBMS costing more than three dollars" because I cannot think of one of those which would not handle your key conditions as either an index or in an ORDER BY clause of an SQL SELECT statement.

OR.... you could always effect a modification of a "Golder Oldie" ....String Signed Binary (SSB) Functions for PB-DOS .... to change the string to reflect 'descending' sort...


MCM

[John Petty]

Michael
You are basically correct assuming one uses a slow major commercial data base engine in which case resorting to ASM would be a waste of time. For those of us who write data base engines these things are important.
PS you will understand if I don't waste my time reading your "golden oldie", I have been studieing this and writing it for over 25 years.

[John Petty]

Michael
My last reply was a little quick as I was thinking about a real problem. Of course the data must be sorted or in some form of tree or other stucture before a binary search etc can be done. The issue is how is the data stored so for the example given it requires non stndard data types that have been known since early days of DBF formats (looking at them a byte at a time as you suggest would have sent suzie operators to sleep).
Yes it is a fun project, just how many free years do you have to understand how your simple usually interpeted SQL statements are actually resolved by the data base engine.
So much for useless post 23,762.

[Michael Mattias]

..just how many free years do you have to understand how your simple usually interpeted SQL statements are actually resolved by the data base engine.

I don't care HOW. I care THAT.

After all, it solves the problem.