2009/9/25 Erik Corry <[email protected]> > Personally I think 8-byte aligning by rounding all object sizes up to a > multiple of 8 is the easiest. It's a 2 byte penalty per object on average. > An alternative is to generate code that loads fp values into consecutive > integer registers and uses dmtc1 to move to floating point registers. You > somehow need to persuade the C++ compiler to do the same when accessing heap > numbers, perhaps with gcc inline assembly. > > A third possibility is to make heap numbers 16 byte and leave all other > objects alone. The store sequence is then (the tagged address of the heap > number object is in r0): > > ori r1, r0, #4 > addi r1, r1, 3 // 4 bytes minus heap object tag. > store fp to address in r1 > > (Sadly in MIPS IV the ldc1 instruction doesn't allow you to combine the > addi into it by providing an offset that is not divisible by 8.) > > That makes the store always be aligned somewhere in the last 3 quarters of > the heap number. The load would be similar. The two places where the > garbage collector moves objects it would need to move the map and the fp > number separately instead of using memcpy to ensure that the fp number is > correctly aligned in the new location. I can't remember whether the >
I can't remember what I couldn't remember there! > > 2009/9/25 Søren Gjesse <[email protected]> > > Aligning all objects to 8-byte boundaries will loose a lot of space in the >> heap, also it is not only an issue when allocating in new-space, but when >> allocating in ole space as well (I don't think we allocate tenured >> HeapNumbers though). Also during both scavenge and compacting garbage >> collection this property needs to be preserved. One option would be to have >> the alignment in new-space only, and then make a separate space for >> HeapNumbers, where each HeapNumber would occupy 4 words, this would waste >> one word per heap number though. There are already separate spaces for some >> fixed sized objects. >> If you want to start out with aligning all HeapNumbers make sure to place >> heap filler objects when skipping a work for allocation purposes as the GC >> needs this for consistency. >> >> Regards, >> Søren >> >> >> On Thu, Sep 24, 2009 at 19:03, Rames <[email protected]> wrote: >> >>> >>> Actually I did not change much in architecture independent code to get >>> the shell compile: I only added the mips #ifdef V8_TARGET_MIPS and >>> alikes, and added the mips architecture to scons files. >>> Of course the shell did not and (and still does not work), so I am >>> changing some code but right now it is still only testing. But don't >>> worry I will remember to submit my changes regularly. >>> >>> Right now I am trying to fix errors I meet when I run the shell, and I >>> have a few questions. I'll ask them here since they are port issues. >>> >>> Running the shell on MIPS I got a double alignment problem. v8 uses 4- >>> bytes aligned addresses for HeapObject, and thus for HeapNumber. The >>> double value contained in the HeapNumber has an offset of 4 bytes. But >>> on MIPS we need doubles to be 8-bytes aligned. Browsing the code I >>> found that allocation of such HeapObjects ended calling some >>> AllocateRaw function, but I could not find a system controling this >>> alignment: It seems everything is 4 bytes aligned because we only ask >>> for multiples of 4 sizes allocation. >>> >>> The patch I found is to always round up the allocated size to a >>> multiple of 8 (and change the double offset in HeapNumber so that it >>> is 8-bytes aligned), changing >>> Address new_top = alloc_info->top + size_in_bytes >>> to >>> Address new_top = alloc_info->top + RoundUp(size_in_bytes, 8); >>> in NewSpace::AllocateRawInternal and PagedSpace::AllocateLinearly . >>> >>> Is there some way to control alignment that I missed or do we need >>> something like that? >>> >>> Thanks. >>> >>> Alexandre >>> >>> On Sep 24, 1:58 am, Erik Corry <[email protected]> wrote: >>> > 2009/9/22 Rames <[email protected]> >>> > >>> > >>> > >>> > > I did not find documentation about how to port v8, but as Dean >>> McNamee >>> > > suggested, going through x64 commit logs was interesting. Of course >>> > > the most teaching step was to read the code, which is very well >>> > > documented! >>> > >>> > > I am still just at the beginning of the port. I can now compile the >>> > > shell, and begin the real porting part. I think I will start a wiki >>> to >>> > > keep track of and explain which main steps I follow and what issues I >>> > > meet. >>> > >>> > If you have made changes to compile the shell I think you should get >>> them >>> > integrated. We are much happier reviewing small changes than one huge >>> > change at a later date. >>> > >>> > You should consider putting in a simple, slow MIPS simulator. The ARM >>> > simulator is only around 2000 lines of code and it is enormously useful >>> when >>> > debugging. The way it was done with ARM was that an unimplemented >>> > instruction error gives an error message that tells you exactly what >>> > instruction was hit. Then you implement only the instructions that >>> your >>> > back end can emit. In the beginning that is probably very few >>> instructions >>> > :-) >>> > >>> > One way to approach a port would be to copy the ARM directory, then rip >>> out >>> > most of the implementations of all the functions, replacing them with >>> > 'unimplemented' errors. There will be some code duplication with this >>> > approach, but it is nice and simple. >>> > >>> > >>> > >>> > >>> > >>> > > This may be a starting point to this documentation, and maybe more >>> > > experienced developers will share their experience and help. >>> > >>> > > I will give some update when I have enough info, results, and >>> > > experience to start the documentation. >>> > >>> > > Alexandre >>> > >>> > > On Sep 22, 6:30 am, rmckeown <[email protected]> wrote: >>> > > > Right now I'm not seeing much guidance around porting v8 - just the >>> > > > code that is already out there, so I'm currently resigned to the >>> code >>> > > > and beginning to run gdb to figure out the behaviour. >>> > >>> > > > It would be great if we could distill out and document a general >>> > > > approach to porting as you suggest >>> > >>> > > > e.g. what key things about the target arch. must you determine, >>> what >>> > > > order should attack the files. >>> > > > With 3 architectures now supported (ia32, x64 and ARM) the best- >>> > > > practices should be emerging and if we can get them documented, >>> it'll >>> > > > make subsequent ports go easier. >>> > >>> > > > ...or am I mistaken, and is this info actually out there and I >>> haven't >>> > > > yet stumbled upon it? >>> > >>> > > > Thx >>> > > > Rob >>> > >>> > > > On Sep 13, 3:15 pm, Dean McNamee <[email protected]> wrote: >>> > >>> > > > > I would dig through the commits from William and Lasse. They >>> recently >>> > > > > implemented the x64port. It was more work than a 32-bit >>> > > > > architecture, since it involved also making parts of v8 work with >>> > > > > 64-bits. >>> > >>> > > > > I would try to follow the same path they did, which parts, tests, >>> etc >>> > > > > they started with, and how they brought the pieces together. It >>> seems >>> > > > > like a MIPSportwill be most similar to ARM, so you'll probably >>> want >>> > > > > to understand how that code generator works. >>> > >>> > > > > Good luck >>> > > > > -- dean >>> > >>> > > > > On Sat, Sep 12, 2009 at 2:06 AM, A.Rames <[email protected]> >>> wrote: >>> > >>> > > > > > I am glad to say on this group that Sigma Designs wants >>> toportv8 to >>> > > > > > the MIPS architecture and plans to contribute the code when it >>> is >>> > > > > > finished. >>> > > > > > I am a new Sigma intern and I will be working on this project >>> > > > > > (supervised by Sebastian Manciulea). >>> > >>> > > > > > After some time running tests, reading documentation about >>> dynamic >>> > > > > > compilation techniques, and reading v8's code, I am now >>> thinking >>> > > about >>> > > > > > how toportv8 to MIPS. >>> > >>> > > > > > After discussing it briefly, the rough idea would be: >>> > > > > > - To manage to compile v8 for MIPS. (without having it work) >>> > > > > > - I guess I will then need to implement the whole (or most of >>> it) >>> > > > > > instruction set and test if I can correctly generate >>> instructions >>> > > > > > before really porting anything else. >>> > > > > > - Toportgradually each element, beginning by the most >>> independent >>> > > > > > elements. (cpu.h functions, higher level description of >>> instructions, >>> > > > > > etc) >>> > > > > > - Continue to a higher level, beginning with the regexp part >>> as both >>> > > > > > interpreter and native mode are present. >>> > >>> > > > > > So this is my rough guess of how I should begin. However v8 >>> > > > > > developers' (and other's as well) opinion and advice would be a >>> great >>> > > > > > help! >>> > > > > > Are there any problems with my approach? Where would you begin? >>> Do >>> > > you >>> > > > > > have any particular warning or advice? >>> > >>> > > > > > Thanks! >>> > >>> > > > > > Alexandre >>> > >>> > -- >>> > Erik Corry, Software Engineer >>> > Google Denmark ApS. CVR nr. 28 86 69 84 >>> > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 >>> Copenhagen K, >>> > Denmark. >>> >>> >> >> >> >> > > > -- > Erik Corry, Software Engineer > Google Denmark ApS. CVR nr. 28 86 69 84 > c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen > K, Denmark. > -- Erik Corry, Software Engineer Google Denmark ApS. CVR nr. 28 86 69 84 c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K, Denmark. --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
