Thanks! Very helpful. No, there is no need in multiplatform support in one build. Register pairs don't need to be ordered.
--Evgeny On Monday, August 13, 2012 5:10:30 PM UTC+7, Vyacheslav Egorov wrote: > > Here is another possibility: in low level IR explode double values > into pairs of low-level values. > > d2 = Mul d0, d1 > > becomes smth like > > (i20, i21) = Mul (i00, i01), (i10, i11) > > that would require a minor change in the pipeline to allow multiple > return values but I think it might be less painful than supporting > register pairs across the pipeline. > > -- > Vyacheslav Egorov > > > On Mon, Aug 13, 2012 at 11:34 AM, Vyacheslav Egorov > <veg...@chromium.org <javascript:>> wrote: > > Are you planning to allocate a couple of general purpose registers to > > represent a double? Do these registers have to be ordered? (e.g. do > > you need r_{N}, r_{N+1}) > > > > Do you want a single build of V8 work both on a hardware that supports > > real double registers and that does not? > > > > If you don't need binary portability then I don't think you need to > > extend unallocated policies. Just change "interpretation" of > > DOUBLE_REGISTER policy everywhere. > > > > Otherwise, yeah, you need new policies (which would require some bit > > stealing cause LUnallocated is packed pretty tight already). > > > > In any case it would require some adjustments in allocator to get > > "what interferes with what" right. > > > > -- > > Vyacheslav Egorov > > > > > > On Mon, Aug 13, 2012 at 7:53 AM, Evgeny Baskakov > > <evgeny....@gmail.com <javascript:>> wrote: > >> Hi guys, > >> > >> I'm looking for ways to modify the Crankshaft compilation mode to make > it > >> work without 64-bit hardware registers. > >> > >> Could someone give me brief guidelines? Is it possible at all, without > the > >> whole V8 codebase reworking? > >> > >> My first impulse is to extend the LUnallocated policies set and make > the > >> codegen distinguish between single and coupled registers. Then, the > lithium > >> codegen would use the CPU-based code stubs instead of native > double-related > >> instructions. What pitfalls should I be aware of here? > >> > >> --Evgeny > >> > >> -- > >> v8-users mailing list > >> v8-u...@googlegroups.com <javascript:> > >> http://groups.google.com/group/v8-users > -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users