code review 134860043: runtime: convert uint64div and uint64mod to Go

runtime: convert uint64div and uint64mod to Go

This CL expands vlrt.go to be used by the 386 build converting uint64div and uint64mod to Go.

Another CL will follow to handle the signed versions of these functions.

[dave_cheney.net, 2014-08-26 06:15:51]

Hello [email protected], [email protected], [email protected],
[email protected] (cc: [email protected]),

I'd like you to review this change to
https://code.google.com/p/go

[josharian, 2014-08-26 14:47:13]

Hmm. This CL and CL 133790043 (ready for 386, not started for arm) are on a
collision course. :) That's what I get for working on other things yesterday.
Sorry.

A few differences:

* ARM's dodiv is 386's slowdodiv. 386's dodiv requires a bit of new assembly
support.
* I inlined divvu, modvu, divv, and modv, since they were just one-line
wrappers.
* I changed dodiv's signature to return q and r rather than accept pointers.
Easier to read, no pointless temps.

Want to take a peek at CL 133790043 and suggest a course of action?

And a general question: Are we going to rewrite panicdivide in Go? I don't think
it can be marked nosplit all the way down.

[rsc, 2014-08-26 15:27:56]

what's wrong with rewriting panicdivide in Go? it's just one line.

[josharian, 2014-08-26 20:55:17]

Added arm support and mailed CL 133790043.


> what's wrong with rewriting panicdivide in Go? it's just one line.

Nothing, although it calls panicstring, which in turn calls printf, throw,
newErrorCString, and panic. I'm not sure where we stop C->Go and switch to
running on the m stack.

We can handle it in a follow-up CL either way.

[dave_cheney.net, 2014-08-26 22:21:33]

Thanks Josh, I'll abandon my change, yours is much more comprehensive.
On 27 Aug 2014 06:55, <[email protected]> wrote:

> Added arm support and mailed CL 133790043.
>
>
>  what's wrong with rewriting panicdivide in Go? it's just one line.
>>
>
> Nothing, although it calls panicstring, which in turn calls printf,
> throw, newErrorCString, and panic. I'm not sure where we stop C->Go and
> switch to running on the m stack.
>
> We can handle it in a follow-up CL either way.
>
>
> https://codereview.appspot.com/134860043/
>

[dave_cheney.net, 2014-08-26 23:31:12]

rsc, khr,

Josh and I spoke offline and we're going to try a slightly different
plan of attack.

Step 1. finish the transition to Go in this CL for arm and 386

Step 2. Integrated CL 133790043 with improvements for 386

Cheers

Dave

On Wed, Aug 27, 2014 at 8:21 AM, Dave Cheney <[email protected]> wrote:
> Thanks Josh, I'll abandon my change, yours is much more comprehensive.
>
> On 27 Aug 2014 06:55, <[email protected]> wrote:
>>
>> Added arm support and mailed CL 133790043.
>>
>>
>>> what's wrong with rewriting panicdivide in Go? it's just one line.
>>
>>
>> Nothing, although it calls panicstring, which in turn calls printf,
>> throw, newErrorCString, and panic. I'm not sure where we stop C->Go and
>> switch to running on the m stack.
>>
>> We can handle it in a follow-up CL either way.
>>
>>
>> https://codereview.appspot.com/134860043/

[dave_cheney.net, 2014-08-27 00:00:13]

Hello [email protected], [email protected], [email protected],
[email protected] (cc: [email protected]),

Please take another look.

[josharian, 2014-08-27 00:10:28]

LGTM but maybe wait for one of the others

386 tests pass here.

It's worth noting that this bypasses 386 dodiv and always uses 386 slowdodiv, so
this will be a performance regression on 386. CL 133790043 will restore 386's
dodiv.

[gobot, 2014-09-30 01:21:44]

R=close (assigned by [email protected])