m32lib GetPercent need a correction

[dedndave]

undefined means it can be either true or false

[ToutEnMasm]

undefined means it can be either true or false

Perhaps a bit short because some comparison seems to work with one cpu and not with another.
I suspect here some secret of particular cpu.

[dedndave]

not really - lol
if it doesn't work the same way on all CPU's, you don't want to use it

i think it's NexGen CPU's where they divide 25 by 5 or something
the ZF is clear for all CPU's except theirs (something like that)
pretty hokie, if you ask me
some other manufacturer that isn't aware of their quirk (flaw) might violate the rule

[Antariy]

For example for calculation of some coordinates.

The Earth's diameter is 40,000 km, that makes 40,000,000 metres or 40,000,000,000 millimetres
40,000,000,000/4294967296 = 9.3 millimetres

For GPS, that is a damn good resolution :bg

Distance to the Sun: ~149,700,000,000,000 mm / DWORD range= 34854,74 MM = 34 meters. :bg

[Antariy]

Hi,

   According to some old documentation I am referring to, only
the carry and overflow flags are valid for the IMUL instruction.
And JL also uses the sign flag, so should not be used.  Do you
have differing documentation as to what are the valid flags
when using IMUL?

Hi Steve!

Yes, your documentation is right.
Just in the original code used simple (and logical at first look) assumption: if result of multiplication have higher bit set, then IMUL set CF and OF. But, since higher bit setted - this is signed value, and SF should be setted, too (in theory  :lol). When truly overflow was occured, then OF was setted but SF - not (since truncation). So, I checked this on my CPU, and this "rule" seemed to work. And I have used it in algo. But it is not seemed to work on some other CPUs :green2

Steve, at page 2, here: "http://www.masm32.com/board/index.php?topic=15263.msg127043#msg127043" contained old code. Test it please if you have spare time. But firstly needed to comment call SSE code.



Alex

[redskull]

Code Select Expand

Intel(R) Core(TM)2 Duo CPU     E4500  @ 2.20GHz (SSE4)
14      cycles for GetPercentSSE
47      cycles for GetPercent
9       cycles for GetPercent2c
9       cycles for GetPercent2nc
9       cycles for GetPercentJJ1
12      cycles for GetPercentJJ2
19      cycles for AxGetPercentInt

38      cycles for GetPercentSSE
37      cycles for GetPercent
22      cycles for GetPercent2c
9       cycles for GetPercent2nc
9       cycles for GetPercentJJ1
10      cycles for GetPercentJJ2
10      cycles for AxGetPercentInt

Code sizes:
39      bytes for GetPercentSSE, result=6790123
36      bytes for GetPercent, result=-2147483648
41      bytes for GetPercent2c, result=-2147483648
45      bytes for GetPercent2nc, result=6790123
37      bytes for GetPercentJJ1, result=6790123
32      bytes for GetPercentJJ2, result=6790123
31      bytes for AxGetPercentInt, result=6790122

--- ok ---

:thumbu

-r

[FORTRANS]

Hi Steve!

Steve, at page 2, here: "http://www.masm32.com/board/index.php?topic=15263.msg127043#msg127043" contained old code. Test it please if you have spare time. But firstly needed to comment call SSE code.

Hi Alex,

   Doesn't seem to work.  Neither the *.EXE included nor a
rebuild with SSE code commented out  Seems to hang.
Results displayed (both cases):

Code Select Expand

G:\WORK\TEMP>2getperc
pre-P4 (SSE1)
-2125943931 for 7FFF0000/1, case 1



Regards,

Steve N.

[jj2007]

Steve,
There is an int 3 in ChkPrecision:
            inkey str$(edi), 13, 10
            int 3
            invoke AxGetPercentInt, esi, ebx
Just comment the call to ChkPrecision out, but keep in mind it was there for a reason. AxGetPercentInt behaves differently for negative values.

[FORTRANS]

Hi jj2007,

   Thanks for pointing that out.  It now goes into an infinite loop.
But it does run.  (?)

Code Select Expand

-2061530988 for 7FFF2710/4, case 1243708

-2040056706 for 7FFF2710/5, case 1243708

-2018582425 for 7FFF2710/6, case 1243708

-1997108144 for 7FFF2710/7, case 1243708

-1975633863 for 7FFF2710/8, case 1243708

-1954159582 for 7FFF2710/9, case 1243708

-1932685301 for 7FFF2710/10, case 1243708

Regards,

Steve N.

[Antariy]

Hi jj2007,

   Thanks for pointing that out.  It now goes into an infinite loop.
But it does run.  (?)

Code Select Expand

-2061530988 for 7FFF2710/4, case 1243708

-2040056706 for 7FFF2710/5, case 1243708

-2018582425 for 7FFF2710/6, case 1243708

-1997108144 for 7FFF2710/7, case 1243708

-1975633863 for 7FFF2710/8, case 1243708

-1954159582 for 7FFF2710/9, case 1243708

-1932685301 for 7FFF2710/10, case 1243708

Regards,

Steve N.

Hi Steve!

Thank, that is right - code from page 2, which I asks for testing, uses assumption that SF is setted according to the results.
So, it seemed to work only on Prescotts :bg

Here you can get working version: "http://www.masm32.com/board/index.php?topic=15263.msg127085#msg127085".



Alex

[FORTRANS]

Hi Alex,

   After a couple of edits.

G:\WORK\TEMP> 2getperc
pre-P4 (SSE1)
52      cycles for GetPercent
19      cycles for GetPercent2c
21      cycles for GetPercent2nc
21      cycles for GetPercentJJ1
21      cycles for GetPercentJJ2
13      cycles for AxGetPercentInt

52      cycles for GetPercent
19      cycles for GetPercent2c
21      cycles for GetPercent2nc
21      cycles for GetPercentJJ1
21      cycles for GetPercentJJ2
13      cycles for AxGetPercentInt

Code sizes:
36      bytes for GetPercent, result=-2147483648
41      bytes for GetPercent2c, result=-2147483648
45      bytes for GetPercent2nc, result=6790123
37      bytes for GetPercentJJ1, result=6790123
32      bytes for GetPercentJJ2, result=6790123
31      bytes for AxGetPercentInt, result=6790122

--- ok ---

Regards,

Steve N.

[Antariy]

Hi Alex,

   After a couple of edits.

Hi Steve!

Thank you!

Yes, here we see drawbacks of the used testbed :bg



Alex

[jj2007]

Yes, here we see drawbacks of the used testbed :bg

The testbed is transparent - anybody with basic search skills can search for "case" and find the "culprit", ChkPrecision was introduced because some results did not yield the expected results, and so I let it crash there for testing purposes. I didn't know that somebody would develop an algo that yields, as result for invoke GetPercent, -1000, 50 the number 2147483148 (and claims the result is correct...).

So stop blaming the testbed, and start explaining in which real coding situations an "unsigned" GetPercent algo is useful.

[dedndave]

well - i know of a simple example
displaying percent completion in a file transfer or other procedure
that is a case where a simple percent routine can be used; always positive, 0 to 100 %
it could even be a macro, but speed is not really critical in that case

we shouldn't spend too much time in the laboratory speeding up algos that are used like that
so - you can assume that this algo should be general purpose, and cover a wide range of input values

[hutch--]

Humerously enough the GetPercent() algo was designed to do something really simple, calculate screen percentages to the nearest pixel for sizing windows on the screen. I was happy enough to use JJs technique that made it faster and smaller but for what it was designed for, ain't like you are going to tell the difference.