Assembler is HOT!

[Bob Zale]

Welcome to the new Inline Assembler forum! We'll do our best to get you lots of important information on the ultimate optimization tool.

New to assembler? This is the place to ask! A PRO, but need a little advice or explanation? This is the place. I have a few years experience here, and I'd love to share whatever i can. Let's hear from you!

Bob Zale
PowerBASIC Inc.

[Bern Ertl]

Thanks. I have some experience with assembler, but I use it so infrequently, that I tend to forget a lot and sometimes need to ask very basic questions. This forum is a better venue for that than sending PMs/emails directly to the forum members who I know could answer them and waiting/hoping that they have the time to answer.

[Nick Luick]

This is the place. I have a few years experience here,

Lets see shall I raise a few op codes or call your bluff. Naw I fold

[Michael Mattias]

Let me share all my expertise in inline assembler ...

ASM print 'Hello World'

[Roberto Valois]

PowerBASIC for Windows
PB/Win Version 9.01
Copyright (c) 1996-2009 PowerBasic Inc.
Venice, Florida USA
All Rights Reserved

Error 497 in C:\PBWin90\Samples\teste.bas(6:001): Assembler syntax error
Line 6: ASM print 'Hello World'
==============================
Compile failed at 14:20:01 on 20/06/2009

[Bob Zale]

Maybe you should try it in UniCode?

[John Petty]

Bob
I don't know how you manage to keep up with all the changes. My Intel documentation was some years old so did an update.
One of the big surprises was that ADD 1 is now faster INCR (if I read it correctly). As I prefer AMD I guess I need to update their documentation as well.
John

[Roberto Valois]

Error 497 in C:\PBWin90\Samples\teste.bas(8:001): Assembler syntax error
Line 8: ASM printW 'Hello World'

[Bob Zale]

Bob
I don't know how you manage to keep up with all the changes. My Intel documentation was some years old so did an update.
One of the big surprises was that ADD 1 is now faster INCR (if I read it correctly). As I prefer AMD I guess I need to update their documentation as well.

The truth is I concentrate much more on the algorithm than taking apart the opcodes. Seems to work best for me.

Bob

[Michael Mattias]

>The truth is I concentrate much more on the algorithm than taking apart the opcodes

Excellent advice for all; and applicable to ALL programming, not just assembly language.

[George Deluca]

Getting started

OK, I'm retired but spent 95% of my career coding assembler (IBM 360/370 etc.) but I've never so much as looked at Intel/PC assembler.

Anyone have pointers to a good place to get started learning. Maybe being able to do fragments here and there might come easier than tackling a complete program.

Or am I better learning with a normal assembler/linker package?

BTW, what does DEBUG do for a program with embedded ASM code? Is the block sort of 'skipped' over as far as debugging goes?

George

[Barry Marks]

>The truth is I concentrate much more on the algorithm than taking apart the opcodes

Excellent advice for all; and applicable to ALL programming, not just assembly language.

When you have the time, doing both is lots more fun.

Barry

[Bern Ertl]

Anyone have pointers to a good place to get started learning. Maybe being able to do fragments here and there might come easier than tackling a complete program.

There are lots of code samples for functions posted in the source code forum. You might try searching the forum for some opcodes and see what turns up.

[John Petty]

The truth is I concentrate much more on the algorithm than taking apart the opcodes. Seems to work best for me.
Bob

I have no complaints about the speed of the code you produce but am not sure what you mean by algorithm as this applies at different levels. Counting clock cycles as we did in the old days is now pointless. With the advent of out of order instruction processing, branch prediction etc and keeping code segments to less than the length of the trace cache have become more important so as to not cause a "stall". Is that what you were refering to?
I now have trouble reading it forget understanding it
John

[John Petty]

>The truth is I concentrate much more on the algorithm than taking apart the opcodes

Excellent advice for all; and applicable to ALL programming, not just assembly language.

Of course and no different to the DDT, SDK argument most like to leave it to the experts who produce easy to use and write code that handles common situations, thats why we buy high level compilers. I have never found a situation that DDT could not handle adequately for me in GUI but that relates to the type of application I write. Similarly what I write is very speed critical (programs that run for several days to get a result) so will sometimes attempt to improve by writing some sections in assembler. I must admit it is getting harder to improve on the speeds I am getting from using standard PB instructions.

[John Gleason]

Anyone have pointers to a good place to get started learning. Maybe being able to do fragments here and there might come easier than tackling a complete program.

Or am I better learning with a normal assembler/linker package?

BTW, what does DEBUG do for a program with embedded ASM code? Is the block sort of 'skipped' over as far as debugging goes?

George

You might start with The Inline Assembler section of PB documentation. It's got a lot of information there.

I'd imagine PB asm would be easier to learn than a normal assembler/linker package. You can concentrate on the inner loops with asm and leave the rest to PB. Now all the opcodes are supported too, so it's complete.

The debugger steps thru asm statements just like basic statements, so you can watch the code as you go.