Small optimizations to parseInt

Small optimizations to parseInt:
- Second argument to Runtime_StringParseInt is always a smi, avoid converting to double and back to int

- parseInt(positive float) is more common than parseInt(negative float), so check for positive numbers first.

[Erik Corry, 2009-11-11 11:16:49]

http://codereview.chromium.org/391014/diff/1/3
File src/runtime.cc (right):

http://codereview.chromium.org/391014/diff/1/3#newcode3390
Line 3390: CONVERT_SMI_CHECKED(radix, args[1]);
This version doesn't work if the argument is not a Smi.  It throws an exception
instead of just working.  We should have a test that parseInt("100", 16.1) ==
256.

[Lasse Reichstein, 2009-11-11 11:43:34]

Add some tests for fractional bases in parse-int-float.js, and it'll LGTM.

http://codereview.chromium.org/391014/diff/1/3
File src/runtime.cc (right):

http://codereview.chromium.org/391014/diff/1/3#newcode3390
Line 3390: CONVERT_SMI_CHECKED(radix, args[1]);
It's perfectly fine to throw an exception for a non-smi, if we only ever use it
with a smi (as we do, if TO_INT32 returns values in the range 2..36 as smis), so
this in itself is not a problem.
But yes, we do need some tests to see that we don't pass non-smis as arguments.

http://codereview.chromium.org/391014/diff/1/2
File src/v8natives.js (right):

http://codereview.chromium.org/391014/diff/1/2#newcode99
Line 99: (string < -0.01 && -1e9 < string))) {
Just for readability, could you swap the terms of the last '&&'?
It's probably safe to assume that positive numbers outweigh negative numbers as
argument to parseInt, so it's a fine optimization (although I doubt it will make
a measureable difference in practice).

[Erik Corry, 2009-11-13 12:24:22]

http://codereview.chromium.org/391014/diff/1/3
File src/runtime.cc (right):

http://codereview.chromium.org/391014/diff/1/3#newcode3390
Line 3390: CONVERT_SMI_CHECKED(radix, args[1]);
On 2009/11/11 11:16:49, Erik Corry wrote:
> This version doesn't work if the argument is not a Smi.  It throws an
exception
> instead of just working.  We should have a test that parseInt("100", 16.1) ==
> 256.

My apologies, I was too fast with this comment.  The 16.1 case is caught in the
js code, so the patch LGTM.