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. --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
