Assembly code branching

[DougRaymond]

I have been trying for days to work out how to do conditional jumps, but everything I try gives an error. Can someone tell me how to do it? a sample of the code is in the attached ASM.jpg partial screen print of the editor. Thankyou.

[madref]

This is a lazarus forum....not an assembler forum

[marcov]

Did you enable {$asmmode intel} ?

[engkin]

Declare labels in a Label section.

[BeanzMaster]

Hi just use @ for label

Ex @Loop :
Why don't you use Push and pop for save and restore register ?

[440bx]

Doug,

At first sight, I don't think that assembly code is going to be significantly faster than something you would write in plain Pascal (particularly once optimizations are set "high" (3))

Did you try writing it in Pascal ? 

Once you have it working in assembly, you might want to test it against a pure Pascal implementation.  The performance gain may not be worth using Assembler.

HTH.

[DougRaymond]

Thankyou to all the people that responded to my question. I will reply in order.
madref - Lazarus allows inline assembly code.
marcov - This actually worked. Thankyou. Guess I will never know why my branches in AT&T assembly code would not work, but at least they work in Intel assembly code.
engkin – I don’t know how to do that.
BeanzMaster – That is how it is done in Intel assembly code. It does not work in AT&T. I don’t know why or when I switched from pushing and popping. You are right. It is a better way.
440bx – You are right. There is no particular advantage in writing this procedure in assembly code.

Extra information. I wrote this application in Delphi 5 for Windows 98 last century. It allows scrolling text to be displayed via a data projector in a church or karaoke situation. I am amazed that it still works on Windows 10. Recently people have been nagging me to produce a 64 bit version. I was hoping that I could do this through Lazarus.
My application is mostly written in Pascal. The only bits that require assembly code are the bits that combine the words and background bitmaps to produce the scroll.
If I can get the original to work in Lazarus it will save me a lot of time against starting from scratch again in cpp, which is the only other language that I know that allows inline assembly code.

[marcov]

marcov - This actually worked. Thankyou. Guess I will never know why my branches in AT&T assembly code would not work, but at least they work in Intel assembly code.

Labels start with a dot in AT&T. 

Assembly code usually needs some updates when changing to 64-bit (it is a different architecture, even though related). Not always hard, but requires knowledge which makes it non trivial.
 

[440bx]

... starting from scratch again in cpp, which is the only other language that I know that allows inline assembly code.

Be aware and beware that not all 64bit cpp compilers allow inline assembly,  MSVC among them.

My suggestion, whichever way you end up implementing the application, don't use assembly unless there really is an overriding reason for it.

[marcov]

Afaik delphi doesn't either.

[PascalDragon]

Afaik delphi doesn't either.

You need to have the whole function body as assembly. Inline assembly blocks are not supported.

[Pascal]

My application is mostly written in Pascal. The only bits that require assembly code are the bits that combine the words and background bitmaps to produce the scroll.

I am just playing around with a similar app. Download preview project at
https://www.dropbox.com/sh/lqx33xx38p3c3b0/AADbP3ikJJpwPPTO4TdMRcGra?dl=0
You have to install freetype.dll.

[MathMan]

Hi Doug,

Welcome to the forum btw. I am in line with 440bx regarding the use of assembly. But first of all have a look at the algorithm. From your source it looks like you want to do a "saturated add" on a byte level. You are doing that via compare and branch, which generates data dependent branch mispredictions that will heavily slow down modern processors. A 1:1 translation of this to Pascal will have the same issues. And the added downside of this is that the execution speed of your routine is depending on the image you handle!

With some bit-wizardry you can make that code branch free if you considering the following

 $xx + $yy = carry-bit + $zz => if you do bitwise or of $zz with Carry*255 you get what you want

The above is branch free and probably the Pascal version is already faster than your current asm, even if you handle one byte after the other. However, the branch free variant can be modified to handle all four bytes of a DWORD in parallel (or on a 64 bit machine even 8 bytes of a QWORD) giving a substantial boost.

If you are really craving for speed and willing to restrict to certain processor types, then there are AVX instructions on modern x86-64 processors that handle "saturated adds" and can provide another substantial boost. However I would first start with a Pascal version of the branch-free approach I explained above.

Regards,
MathMan

[DougRaymond]

This has been a most interesting experience. Some of my old mates who love an old application that I wrote, wanted me to upgrade it to 64 bit. I thought Lazarus may be a an easy solution. Unfortunately it isn’t.

I asked for someone to assist me with the syntax of branches. The dot doesn’t work in AT&T either.

I did not ask for an evaluation on my style of programming. I posted a very simple example, that allows the user to make a picture brighter. Whether it takes a nano- second to run or five-seconds is of no importance.

The standard version of Delphi 5 handles in line assembler like a breeze. So does the Visual Studio 2019 C++. I have used both.

For your added amusement, I have added as an attachment, the central procedure which combines the text bitmap with a background picture bitmap and writes it directly to the backbuffer of the graphics card. You can have fun picking that to pieces. Meanwhile I shall return to Visual Studio which actually works

[marcov]

First, don't use images, this makes a quick test too hard.

Second, such things work fine in 32-bit mode in Lazarus too, if you set the right modes.

Lazarus is simply more flexible in that it accepts assembler in more styles. (most notably Microsoft-intel-borland (Intel style) and Unix (AT&T style though after 2010 Intel style is getting more popular there)

Freepascal used an open source assembler as backend that in the early days exclusively supported AT&T style. Which is why it got to be the default.