Bullshit... the cpu has extra gates and logic and memory (internal) to handle it only thing required is more bandwidth for the extra counter data :)
Again the programmer makes the decision. If he is wrong or usage pattern changes these decision are no longer valid :D
Have a nice day =D
Bye, Skybuck.
Isn't is nearly as effective to put these instructions in front of the branch? This means that if later incarnations need a shorter slot everything will be compatible.
For extra points auto-insert NOPs if the loop is too small.
This will make things more complex but perhaps not slower.
Thomas
Except that these may be put to a much better use.
-- Sander +++ Out of cheese error +++
Guess why I wrote "object at a given address" and not "variable".
Lots of variables may refer to the same object - the object's address captures this. The same variable may refer to different objects at different times; again, object address differences tell you that type may be different.
-andy
The old ATT one had only one extra instruction per branch and also had conditional math operations. The result was you could do all sorts of useful and very fast things.
-- -- kensmith@rahul.net forging knowledge
Are you refering to the usual "find 1/X and then multiply by that" method?
Booth's divide is more common in microcontroller land. If you have a micro that doesn't natively do 32 bit divides and an integer math library, chances are you are using a Booth's divide.
Actually this isn't really true. There are a huge number of processors out there that don't do the divides in hardware for at least some of the types that are commonly used on them. These are not desk top PCs. They are systems that contain a processor but are not general purpose computers.
-- -- kensmith@rahul.net forging knowledge
In article , Andy Freeman wrote: [...]
Yes, and once you have XXXXYYYYed that variable, you aren't likely to do it again. You will XXXXYYYY most of the variables of that same type though. This I say makes the address of the object a poor input to the prediction and the VMT a good one.
-- -- kensmith@rahul.net forging knowledge
In article , snipped-for-privacy@green.rahul.net (Ken Smith) writes: |> In article , |> Nick Maclaren wrote: |> |> [... booth's divide ..] |> >The mind boggles! I have never seen it used, but I can believe that |> >it is. The most usual software divide is Newton-Raphson. |> |> Are you refering to the usual "find 1/X and then multiply by that" method?
No. That is a component of the method, but you need to do a bit more to get it quite right.
|> Booth's divide is more common in microcontroller land. If you have a micro |> that doesn't natively do 32 bit divides and an integer math library, |> chances are you are using a Booth's divide.
Boggle. Well, if performance isn't a major issue, I suppose that it doesn't matter what you use.
|> > Whatever |> >the case, only a few systems lack hardware division for the standard |> >types, very few applications use it for non-standard types, and the |> >proportion of time spent in such code is miniscule! |> |> Actually this isn't really true. There are a huge number of processors |> out there that don't do the divides in hardware for at least some of the |> types that are commonly used on them. These are not desk top PCs. They |> are systems that contain a processor but are not general purpose |> computers.
The context was where branch prediction of the division operation is critical for performance, as the above paragraph makes clear. If performance of the division IS a major issue, can you explain why people use Booth's algorithm IN SOFTWARE? As I said, the mind boggles!
[ All right, I do know of one case. If you have NEITHER hardware division NOR reasonable hardware multiplication, it is a real pain to code Newton-Raphson. But anyone who runs codes where division is a bottleneck on such a system is off his tiny mind. ]Regards, Nick Maclaren.
under
therefore I
Ok dinky, then it's aaaalll gooooddddd :)
So you say "no" and then "yes".
Performance can be a major issue along with other limitations like low power or small size.
No, that is not the context at all. The context was showing a simple example of code where earlier branches are a very bad predicter of later branches. The Booth's method only appeared in the discussion because it is so simple and easy to understand. Other examples were cited.
-- -- kensmith@rahul.net forging knowledge
You wrote "object" because you couldn't spell "variable". Did I get it right? :)
[...]That has no effect on the argument. Once you have XXXXYYYYed a given object you are not likely to have to XXXXYYYY it again. This is why the VMT is the better way to predict.
-- -- kensmith@rahul.net forging knowledge
Snark and error in the same sentence.... (Yes, objects aren't variables.)
Actually, it does, as my explanation showed. XXXXYYYYing an object's address does the right thing - it even handles other references to the same object. XXXYYYing a variable that refers to an object doesn't work nearly as well because that variable may be used to refer to a different object at some other time and other references don't get the benefit of any caching you might do.
-andy
[...]
You are assuming that you need to XXXXYYYY the object more than once. This is not a good thing to assume. You are very likely to XXXXYYYY many objects of the same type but much less likely to XXXXYYYY the same variable more than once.
A good example is some sort of widget that is part of a GUI. The widget gets constructed, displayed, removed from the display and destroyed. Each of these is done only once to that object. Others of that same type would get the same things done to it so optimizing based on the VMT address would work.
-- -- kensmith@rahul.net forging knowledge
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.