Porting v8 to MIPS

I am glad to say on this group that Sigma Designs wants to port v8 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 to port v8 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.
- To port gradually 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

I would dig through the commits from William and Lasse. They recently
implemented the x64 port. 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 MIPS port will be most similar to ARM, so you'll probably want
to understand how that code generator works.

Good luck
-- dean

Good idea. I am looking at the their logs and work.

Thanks.

Alexandre

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
> implemented the x64port.  It was more work than a 32-bit
> like a MIPSportwill be most similar to ARM, so you'll probably want
> On Sat, Sep 12, 2009 at 2:06 AM, A.Rames <alexra...@gmail.com> wrote:
>
> > I am glad to say on this group that Sigma Designs wants toportv8 to
> > how toportv8 to MIPS.
> >  - Toportgradually each element, beginning by the most independent

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.

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

That sounds great Alexandre,

We can compare notes. I'm going to look at porting to the POWER
arch.

Rob

--
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.

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 <erik.co...@gmail.com> wrote:
> 2009/9/22 Rames <alexra...@gmail.com>

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.

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.

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 <erik.co...@gmail.com> wrote:
> 2009/9/25 Erik Corry <erik.co...@gmail.com>
> > 2009/9/25 Søren Gjesse <sgje...@chromium.org>
> c/o Philip & Partners, 7 Vognmagergade, ...
>
> read more »

Hi,

I have been working on the MIPS port of v8, and I have a little
question.

I am working with the JavaScript shell, and follow the ARM port code.
My shell can compile any arithmetic operation an return with success.
I am working on calls to JS functions. For now I just compile a script
with a dummy function returning one of its arguments:
myfunc(p1, p2) { return p2; }
myfunc(2,5);

I have an issue with v8 not jumping to the right place in the
CodeGenerator::VisitCall(Call* node) function.
The VisitCall code layout is as follow:

Handle<Code> stub = ComputeCallInitialize(arg_count, in_loop);
[...]
frame_->CallCodeObject(stub, RelocInfo::CODE_TARGET_CONTEXT, arg_count
+ 1);
[...]

I generate and copy correctly some code through the
ComputeCallInitialize call:
At the stub location_ property address I can find a Code object, with
my actual code beginning at a (Code::kHeaderSize - kHeapObjectTag)
offset.

Through CallCodeObject I end up on a call to MacroAssembler::Call
(Handle<Code> code, RelocInfo::Mode rmod,[...]).

void MacroAssembler::Call(Handle<Code> code, RelocInfo::Mode rmode,
Condition cond, Register r1, const Operand&
r2) {
ASSERT(RelocInfo::IsCodeTarget(rmode));
Call(reinterpret_cast<intptr_t>(code.location(), rmode, cond, r1,
r2);
}

This does not work for me and I can't understand how it does on ARM.
The code is at *(code.location()) + code_offset; and here it seems to
me we will end up jumping to code.location() instead.
When I look at the ARM MacroAssembler::Call(intptr_t target,
RelocInfo::Mode rmode, [...]) I see
mov ra, pc
mov pc, target => mov pc, code.location()

Maybe the solution lies in the commentary saying "Emit a ldr<cond> pc,
[pc + offset of target in constant pool].", but I can't undersand
where we do with a constant pool offset.
I think the intptr_t type target also indicates that target is a
pointer to the actual address, but I still can't see when we get the
actual code address to jump to.

Debugging gives me the following:
stub.location_ = 0x6e34e8
*stub = 0x2ce79a21 and the generated code is thus at 0x2ce79a40 (I
can read it in memory)

With the ARM version of the code it seems I jump to 0x6e34e8 and I
meet an illegal instruction.
By patching the code to go to *(code.location()) + code_offset I reach
the generated code (generated by CallIC::Generate through the
ComputeCallInitialize call).


Thanks for your help.

Alexandre

2009/10/22 A.Rames <alex...@gmail.com>:
It's great that you are working on the port. Please send us patches a
little at a time, rather than leaving it until a big chunk is done.
If your approach is somehow incompatible with the way we do things in
V8 then you can waste a lot of time writing things that can't get into
the V8 trunk.
I think what is happening here is that we write the location() from
the handle into the instruction.
Later the code object is created and this can cause a garbage
collection, which can move the code object we are trying to jump to.
After the code object is created the reloc info is used to fix the
call destination to point to the right place. This is done while
copying the instructions into the new code object in the line
code->CopyFrom(desc) in heap.cc.
Because we are reading the right place out of the location of the
handle we will get the new location if the code object had moved.
The way you have done it will not work if you are unlucky enough to
get a compacting garbage collection when you create the code object.

Thank you for your answer. Digging through my code I found what was
wrong.
I will send the first patch next week with the beginning of the port.
I have to clean the code a little first.

Alexandre

On Oct 22, 3:39 am, Erik Corry <erik.co...@gmail.com> wrote:
> 2009/10/22 A.Rames <alexra...@gmail.com>:

Hi,

I am ready to contribute the first MIPS patch.
I gave the Corporate Contributor License Agreement to my manager and
should send it soon.

I have 2 questions before contributing:

* As this is a patch to begin v8 port to MIPS, I don't know at all who
should review this code. Should I just ask a review at chromium-
rev...@googlegroups.com ?

* I am currently working on the port and would like to submit some
specific part of my work, which I think are advanced enough. For the
first patch I'd like to give the assembler-mips files and the very few
modification to architecture independent code (mainly pre-processor
architecture checks to include the right files, and one change about
memory alignment on MIPS).
However I guess it would be nice for you to have other mips files, so
that you can build the shell and easily test the mips assembler. As I
am working on it these are unluckily not very clean, with a lots of
stubs and partly implemented functions.
I prepared a version of the code with very clean assembler-mips files,
and with the JSEntryStub::GenerateBody function just containing a Jump
(ra) to return to v8 code, which could be used to generate code and
test it if you need to.
So do you want me to send you all files or only files needing review?

Regards.

Alexandre

2009/10/29 A.Rames <alex...@gmail.com>:
Better to send it to someone specific. Perhaps me or
ag...@chromium.org. If we don't have time we can find someone else to
do it. I hope you have gcl (the client for codereview.chromium.org)
running.
I'd like to see a minimal subset that can actually compile. It
doesn't matter that it doesn't run, and it doesn't matter that there
are stubbed out functions. I'd like to see some tests that test the
bits that you expect to work. If high level tests don't work yet,
then a test/cctest/test-assembler-mips.cc file that goes alongside the
other assembler test files is the right way to go. I would very much
like to see the disassembler and simulator keeping up with the
assembler so that the same tests can be run without MIPS hardware.

>
> Regards.
>
> Alexandre
> >
>

I have been working on actual MIPS boards; I have no MIPS simulator and I don't think I really have time to code one right now.
Wouldn't it be possible to run v8 with qemu?

Alexandre,

While it might seem like extra work to write the simulator now, it is
actually much better for the maintainer of the MIPS port (you?) if
others can develop and run your code on their main machines without
have to resort to things like qemu.
I do hope that you are implementing a disassembler so that you can see
the code you are generating, the incremental step from the
disassembler to the simulator is minimal. As you can see when
comparing the ARM simulator to the ARM disassembler in V8 they share a
lot of the structure and the implementation of the simulator was very
incremental as more code came online. In an ideal situation your MIPS
assembler would use the same set of constants and accessors as the
disassembler/simulator when encoding the instructions. Only due to
historical reasons the ARM assembler in V8 does not.

Another nice benefit of having the simulator while bringing up V8 on a
new architecture is the access to the builtin debugger. if you take a
look at the debugging support in the ARM simulator, it enables you to
call helper functions in the runtime which is generally almost
impossible in any of the embedded tool chains.

I find that many developers (including me) will not bother to run any
of the tests on foreign architectures if the development is not easily
integrated into their development tools and workflow. Maintaining a
bootable qemu image is very much past that threshold and your MIPS
implementation will suffer from a lack of attention as did the ARM
implementation of V8 before we had a simulator.

Additionally, this might surprise you, is the fact that the regression
test suite completes faster on the simulator than on actual ARM
hardware. This is due to the fact that most of the time running the
regression test suite is spent in C++ code which executes at native
x86 speeds when run with the ARM simulator. For a developer this is a
huge advantage as the turn around time is a lot quicker. As far as I
understand this is still way down the road for you at this point, but
it is a point to consider.

Cheers,
-Ivan

Hi,

I understand very well the need for a simulator.
However I am an intern, and have only three months left to try to port
v8 to MIPS. Right now I would rather work on porting v8 than make a
simulator, since I still have a lot to do.
If I can progress enough before ending my internship I will make a
simulator, but right now this is not my priority.

Alexandre


On Oct 29, 4:11 pm, Ivan Posva <ipo...@chromium.org> wrote:
> > On Thu, Oct 29, 2009 at 2:01 PM, Erik Corry <erik.co...@gmail.com> wrote:
>
> >> 2009/10/29 A.Rames <alexra...@gmail.com>:
> >> a...@chromium.org.  If we don't have time we can find someone else to