I did not think of memory moves issues during GC and others. I will have to look at it. Actually I already thought about your 3rd solution (not at assembly level though). I give some details below. Your 2nd solution seems nice. It seems it would only need very precise and confined changes, and avoid memory moves issues. For now aligning everything to 8 bytes is easy and seems to work fine. My shell crashes too fast to reach other doubles bad alignment errors. I am not yet very familiar with architecture independent code and have other issues to fix on my shell, so I think I will leave this aside until I get a better understanding, and then make something efficient.
Here are some details on the solution I thought about: It seems that this double value is only accessed through the WRITE or READ_DOUBLE_FIELD macros (objects-inl.h line 700), and that HeapNumber is the only one using this. Assuming HeapNumber is the only one using this (else we can make 2 macros just for it) and that only these macros are used to access the double field, ce can increase the HeapNumber size by 4 and make both macros both access 8-bytes aligned double address. The issue with this approach is that the HeapNumber kOffsetValue will stay the same for all, but in half of the cases the double value will indeed be stored at address+kValueOffset , and for the other half it will be at address+kValueOffset+4 (depending on if the HeapNumber address is 8 or 4 bytes aligned). I don't like much the idea of a value being actually stored at a different offset for a same kind of Object (while at first sight the offset seems to be the same as kOffsetValue does not change), but this might be more efficient than aligning everything to 8 bytes. Thanks On Sep 25, 1:08 am, Erik Corry <[email protected]> wrote: > 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, ... > > read more » --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
