Well im rather decent at the API, but since im only two weeks or so old to assembly I get to flaunt my ignorance for a moment :tongue:

My main questions (at the moment) involve optimizing code...
For example (ignoring the fact that possibly some of the codes can be combined), if I start with the rules:

1. The first instruction is pairable in the U-pipe and the second instruction is pairable in the V-pipe.
2. The second instruction does not read or write a register which the first instruction writes to.

And I start with the code:

MOV EAX, 1
MOV EAX, 2

(write after write no pair)
And if I understand correctly, this will also cause an AGI stall?

Well at the moment I cannot come up with a decent example of what I am trying to ask so (bare with me) I will attempt it using another method.

Op1 this, that
Op2 this, that <-- does not pair with Op1
Op3 this, that
Op4 this, that <-- does not pair with Op2

Now if you rearrange this as follows

Op1 this, that
Op3 this, that
Op2 this, that
Op4 this, that

It should pair... *but* what happens when say Op2 access the same register as either Op1 or Op3? Will this cause an AGI stall?
Or will the pairing of the instructions automatically negate any such occurance?

My brain is already exploding trying to fit all this in as it is heh. Another quick one which I think I already know the answer to is, if it does create an AGI stall, I am guessing that pairing is so much faster as to negate the effects of the AGI stall assuming you did not optimize it to begin with... :rolleyes:

Thanks in advance!
Posted on 2002-04-09 21:32:28 by Graebel
Assuming your optimizing for a Pentium I, then you are correct - the registers used by Op1/3 can also be used by Op2/4. Newer processors do all kinds of things to drive you insane when your trying to optimise and there are dozens of different types of stalls...
Posted on 2002-04-09 22:58:56 by bitRAKE

MOV EAX, 1
MOV EAX, 2

(write after write no pair)
And if I understand correctly, this will also cause an AGI stall?
Yes that will cause an AGI stall. Not only will it cause an AGI stall but also starts a dependency chain but it's no big deal cause it's just short(just first chain). I hope your brain isn't fried yet. :grin:

just my 2 cents.

P.S. Personally, I don't pay too much attention on these things except if I'm coding an algo.
Posted on 2002-04-10 00:24:31 by stryker
Graebel,

There is an old rule, when all else fails, put it to the clock, this will always tell you the truth. Expect considerable variation from processor to processor and also expect the tricks that work on one not to work on another.

Agner Fog's manual will be of some use to you in selecting instructions and instruction order but the bottom line is if it does not clock up fast, it does not matter.

Regards,

hutch@movsd.com
Posted on 2002-04-10 08:38:58 by hutch--
Well, the main reason I was asking was I had an idea for a different kind of asm text editor. And of course if I had the details all worked out I was going to take my time and code it myself.

I was thinking it would be cool if on the left side of the code window (next to auto line numbering) it would show some other visual attributes as well. something like:




8
9 [COLOR=red]@[/COLOR] Op1 arg,arg
10 [COLOR=red]O[/COLOR][COLOR=green]@[/COLOR] Op1 arg,arg
11 [COLOR=green]@[/COLOR][COLOR=green]@[/COLOR] Op1 arg,arg
12 [COLOR=green]@[/COLOR][COLOR=red]@[/COLOR] Op1 arg,arg



Line number 8 shows its a non-pairable (@) instruction.
Line number 9 shows its pairable (O), but it is not paired with no agi stall (@)
Line number 10 show its paired (@), and no stall (@)... etc etc

Of course I think I will abandon my idea before it really gets started. I am certainly not going to code (basically) multiple versions of the code depending on chip set and multiple differences. Oh well, sounded fun
:rolleyes:
Posted on 2002-04-10 20:29:02 by Graebel
Graebel: the idea is not bad, but consider that you may e.g. have a label where a loop enters: the behaviour of many CPU's will change depending on if it's the first time the loop is being executed, or not.
So the editor idea in this case may be a bit in trouble. I'd prefer an integrated source level debugger which does the same thing.. so you may know what's happening in the CPU right then.. and get good optimization hints as you wanted to do.
Posted on 2002-04-11 04:54:39 by Maverick