Porting to e500v2 P1010 #119
Comments
|
We're using GCC 4.4.6 for our builds of the 3.14 level. The master code is starting to need some of the C++11 features which need later levels of GCC. I know that the Google V8 team is mostly using GCC 4.8, but I believe that 4.6 or 4.7 would be fine. With enough work you can probably make an older compiler work, but it might be larger than the effort to get a more recent GCC. The Google V8 team is only interested in accepting 'bleeding edge' (aka: master) level changes back. This makes a lot of sense. However, older versions of V8 are more popular (useful) to have. For example Node 0.10.x uses V8 3.14. Mongo works fine with V8 3.14, but is based on V8 3.16. Before you start down the path of porting - you may want to decide which level of V8 you want to focus on. There will be different challenges depending on this selection. V8 tends to make 'breaking' API changes as it moves forward. You can't pick 'master' then expect to be able to slot that code into something that is looking for 3.14 and expect it to work. |
|
Thanks for the advice Andrew. I now have a compatible toolchain to compile v8 for a real e500v2 target. Here's where I am with the e500v2 support, with a few questions embedded.... Using the ppc simulator, as you had also advised, is a nice debug platform for this problem. I added the "UNSUPPORTED()" macro in "simulator-ppc.cc" for the e500v2 unsupported Book E instructions (identified in table 3-2 in the PowerPC e500 Core Family Reference Manual). Then I built the v8ppc simulator: make nativesim=true ppc.debug V=1 -j8 snapshot=off Then ran all of the default node.js tests with: tools/run-tests.py --no-snap --progress=dots --no-presubmit --arch-and-mode=ppc.debug There were nine separate unsupported instructions encountered and listed below. All but two (fcmpu and fmadd) have an almost direct replacement in the e500v2's double-precision floating point APU instruction set. Note that these new instructions exist only on the e500v2 and will not be carried forward on other PowerQUICC processors. The e500v2 "borrows" the general purpose registers for double precision FP operations since it doesn't have dedicated floating point registers. That brings up a question about Lithium register allocation - would there be any clash between the e500v2's use of GPRs for floating point and what the current v8ppc Lithium implementation assumes to be available? Below are the unsupported Book E instructions encountered in the test run, with what I think are the logical e500v2 replacements. rD = destination register Book E..........................e500v2................................Desc. _e500v2 compare has separate instructions for lt, gt, eq compares Next steps:
The best description I've found on lithium so far: Additional pointers and suggestions welcome. I'll update my progress or send out a cry for help soon. Gary |
|
Hi Gary, |
|
Hi Deb: When you get the simulated build running you can add the "UNSUPPORTED()" macro in "simulator-ppc.cc" for the e500v2 unsupported Book E instructions (identified in table 3-2 in the PowerPC e500 Core Family Reference Manual). That way you can see when unsupported instructions are encountered when running the node tests, or just running the d8 shell. So when we replace with e500v2 instructions we can verify the "bad" instructions are being replaced. simulator-ppc.cc will also have to be updated to accommodate the translation of the new e500v2 instructions. Once you get your simulated environment up you could start looking at how to add those new instructions. Gary |
|
Here is some info we captured in respect to the work needed to support a new platform for V8 using the v8 simulator.
For example, in our efforts to get a Node.js running on zLinux, we first compiled by specifying the PPC architecture, which will trigger the PPC simulator to be compiled and enabled in V8.
A great tip is to refer to github/andrewlow/v8ppc, to compare changes between the corresponding branches of the code from joyent and the IBM add-ons. For example, the following link compares branches v0.10.21-release (joyent) and v0.10.21-release-ppc (IBM add-ons for PPC). This will highlight the changes required to build on PPC.
A) Makefiles and GYP files B) Endianness C) More OpenSSL customizations D) V8 There are some specific customizations you'll need as well. One is the signal context information, which varies from platform to platform (i.e. PPC's ucontext is different that Z's). Check out deps/v8ppc/src/platform-*.cc and deps/v8ppc/src/spaces.cc; add proper support for the break and signal handler code. Another is an atomic operations implementation, where each architecture specifies their own implementation. Check out deps/v8ppc/src/atomicops.h. E) Tools There are likely other issues that you might encounter. Just compile your code and see what breaks. |
|
Thanks for the overview on changes needed for a new platform Michael. This is very helpful. Since the e500v2 port will essentially just be addressing double-precision floating point instruction differences between the e500v2 and Power ISA v.2.06 (the current v8ppc code in src/ppc), shouldn't the implementation be similar to what was done for ARM and "CAN_USE_VFP3_INSTRUCTIONS"? In other words - adding the floating point support to the existing src/ppc codegen code rather than creating a wholly new platform (src/e500v2)? Gary |
|
Thanks a lot Gary and Michael, for your detail response. As suggested, will try the simulated mode first. |
|
I agree what you are doing is different than adding a whole new platform and that extending what's there is more likely the right way to go. I just wanted to provide what info we'd captured from our internal porting efforts |
|
@turneyj Yes - I suspect what you want to do is get to something that works on the e500v2 as quickly as possible, then consider how to refactor it. The PPC implementation for V8 is unusual in that a single src/ppc directory is used to capture both 32 and 64 bit (and dual endian). This is a little bit counter to the way that Google has structured the code, but it made sense. The Google team would prefer to see runtime checks vs. #ifdef checks in the code where possible. Those runtime checks would likely be checking a constant and any reasonable C compiler will optimize the check away entirely. The PPC implementation may move to this style, but for now we've gotten to where we are using #ifdef's. @turneyj You may want to consider working in the open on GitHub here if you haven't already. Fork this repository and point @debnath15 at your work in progress. It's probably not terribly helpful now as I suspect you're crashing pretty much right out of the gate and there is a single bottle neck. However, as things become more stable - it opens the door for some parallel work. Simulated mode is intended to be built on a Linux Intel platform, and simulates the PPC implementation. You can coax it to build simulated on PPC (look for nativesimulation) but that's an ugly hack and very slow. Now that you've got the UNSUPPORTED() macro in the simulator, you want to run under gdb and hit that. Figure out the instruction opcode that is causing this - and then put a conditional breakpoint on the emit() to catch the code that generates that opcode. There may be a few false positives, but not many given the instructions you have. Fix the code you find this way (the code emitting the bad instructions) to use your new instructions. This will require adding new instructions to assembler, disassmbler, etc. |
|
Thanks Andrew for the development advice. I've forked the v8ppc repo to my GitHub copy @ https://github.com/turneyj/v8ppc. I'm looking at the emit() call now with gdb to work on the first e500v2 replacement call, which will be to switch fcfid rD,rB (PowerPC) with efdcfs rD,rB (e500v2). I chose that instruction (convert int to double-precision float) because it's the first one encountered when running most of the node tests or just running the d8 shell, and the e500v2 instruction is the same except for the use of GP registers for floating point operands. Regarding the e500v2's use of GP registers for double-precision floating point operands instead of the dedicated FP registers - I'm assuming there will be changes to the register definition/allocation model to protect GP registers used for FP operations from being allocated for the existing v8ppc Crankshaft logic? It looks like that's defined towards the top half of assembler-ppc.h. I'll follow through that logic as well but feel free to offer some direction or tips on register allocation. With 32 GP registers it doesn't seem like there should be a contention issue. Gary |
|
You can probably get away with reserving a couple of the GPR for floating point operations. @mtbrandy might be the best person to comment on PPC register allocation / reservation. |
|
@andrewlow is correct. Especially on v3.14 -- where the lithium register allocator uses only r3-r8 -- there are plenty of GPRs to reserve for floating point operations. You can do a grep to see which other registers are used in special circumstances, but I believe r17-r19 and r23-r25 are currently unused at that level. The only required change should be to add any you use to the kCalleeSaved mask. For later versions where the register allocation has been optimized, you can simply reduce the number of registers available to the allocator. |
|
Quick update - I've added e500v2 floating-point instructions to my local copy of v8ppc that replace 5 of the 10 unsupported instructions encountered in the node test runs (the 9 listed earlier in this issue + fctidz). I'm still developing with the simulator build but need to test on an e500v2 target, which I'll try this week. |
|
I need advice on translating the Book E "stfd" instruction to an e500v2 equivalent. The e500v2 candidate is "evstdd". The general form is: stdf FRS, d(rA) Both instructions load the contents of floating point register FRS (e500v2 uses a 64 bit GP register) into the effective address which is the sum of immediate value 'd' and the contents of general purpose register rA. stfd uses a 16 bit immediate value and evstdd uses a 5 bit immediate value multiplied by 8. So the only difference between the two instructions is the precision of the immediate offset (5 bits vs 16). It seems that, when translating to the e500v2 format, an extra instruction would have to first be emitted to modify the contents of the GP register in order that the effective address calculation is the same in both cases. Is that how the code should be generated? So far this is the only case I've found where the instruction format between Book E and e500v2 is not compatible enough to allow a direct instruction replacement. Gary |
|
These limitations on immediate offsets sound very similar to the ones on the SuperH. What codegen will typically do on that platform is to allocate another base register every time you hit the limit. So in your case you would use rA for offsets 0-248, then compute rB=rA+256 the first time you need that, and then use that register for offsets 256-504. Then a third register for 512-760 etc. Does this make sense? (If you run out of registers the computed registers can be discarded since they can easily be recomputed.) |
|
@zeldin yes thanks - that logic makes sense. Up to this point all of the other e500v2 changes have been through instruction translations in lithium - so I haven't touched hydrogen codegen yet. I'm not familiar with the SuperH CPU, and don't see a reference (by name) to it in the current v8 source. Can you point me to an example? Appreciate the help. |
|
@mtbrandy regarding the register allocation - I was trying to understand the logic of the kCalleeSaved mask, which is set to registers r14 through r31 in my build. I'm tracing the emitted PPC instructions using shell version 3.30.0 and see that general purpose registers 0 through 12 are being accessed during the shell init: So I don't immediately see the connection between the mask and the actual GP register usage by v8. Looking at FP register usage of just the stfd (store floating-point double from FRS) instructions being emitted, FP registers 0 through 13 are accessed: Maybe this is just part of a save/restore step between C and JavaScript? Anyway could you provide a bit more help pointing me to the GP and FP register assignments? Thx - Gary |
|
Hi. I was talking in general terms, not about v8 specifically. There is AFAIK no SuperH port. |
|
@turneyj, my previous comment regarding unused registers in 3.14 is not applicable to more recent versions. See the Register/DoubleRegister classes in src/ppc/assembler.h for the logic that defines which registers are available to the optimizing compiler register allocator. Specifically NumAllocatableRegisters / ToAllocationIndex / FromAllocationIndex. |
|
Thanks @mtbrandy and @zeldin for the clarifications. I have a related question - I've looked briefly at the list of unsupported Power ISA 2.06 instructions on the Freescale e5500 (Table 3-1 of the e5500 Core Reference Manual, Rev. 4). The e5500 and e500mc both have the "standard" PowerPC floating point support (unlike the e500v2), so the v8ppc port for these two cores should be trvial compared to the e500v2. In fact, all of the e500v2's unsupported instructions I've logged on the node tests (on the simulator) are supported on the e500mc and e5500. I would be interested to know from @ctassell (from #118 ), or from anyone whose tried running v8ppc on these two cores, which instructions caused an exception. |
|
I just noticed that fsqrt gets called, so that instruction would definitely except on all of the Freescale cores. |
|
So after adding a filter to the emit() function to log all of the the unsupported e500v2 instructions I built the simulator with: Then ran the node tests with: All of the 16 unsupported instructions logged in the tests or just running the shell are listed in the screen cap below. Items 1 through 11 (except for fmr and fsqrt) have an e500v2 instruction that can be directly added in the assembler, and called in place of the PPC version. I've added those in to a working copy for the assembler, disassembler, simulator, etc. The remaining items will require additional code-gen logic as noted earlier in this thread by @zeldin. PPC instructions with a '2' superscript are emitted when running the d8 shell. I'd like to get the d8 shell running on a real e500v2 as a first step so will have to add code-gen logic to accommodate the remaining instructions identified with a '2' below. Comments or suggestions? Also interesting that only fsqrt is unsupported by the e500mc and e5500, at least that's all I could find so far.
|
|
Hi, I'm trying to get node working on ppc(e500v2). I've read through the |
|
Turneyj, I tried this on e500mc and I am facing some other issue with v8 crash (ibmruntimes/node#41). I will build a simulator and see what instructions are missing. |
|
V8 is itself a compiler. Thus compiling the code with -msoft-float simply ensures that the C/C++ code that implements V8 doesn't have any hard FPU instructions. However, as V8 is a compiler - there is code in it that writes out hard FPU instructions. The implementation details of V8 are unaffected by the -msoft-float compiler flag. |
|
Hi, Andrew thanks for the reply! Following on from the initial question, is there a flag within the V8 build env which tells it to generate floating point ops using the soft float api? If not, have you looked at the arm code for v8, I may be wrong but from my reading the initial version of node for the arm, used the soft floating point. Finally I noted that in your git repo, you have a branch 3.14-soft-fpu, have you made the necessary changes here to force use of the soft-fpu api. I noted in your comments you say 9X% of the test pass, is this because there is still some work to do? Thanks in advance for any help! |
No. Not yet. Someone needs to write and contribute that code. The branch 3.14-soft-fpu was an experiment I made that was abandoned. |
|
Apologies if I'm repeating information. To run v8ppc on a e500v2 core you'll have to modify v8ppc itself, so that in cases where any of the unsupported Book E instructions (listed in "Table 3-2 Unsupported Book E Instructions" from PowerPC e500 Core Reference Manual, Rev. 1) are generated/emitted, a compatible e500v2 instruction or instruction logic is used in substitute. The set of e500v2 floating point instructions you can use in replacement are listed in Table 3-7 of the same Ref Manual. There's a table I posted a few comments back showing the list of unsupported instructions encountered when running v8ppc on the simulator, as well as the e500v2 FP instructions that can be used in substitute. In many cases you can simply replace the Book E instructions. I was thinking that for some e500v2 embedded applications it may be possible to start with a version that implements the "straight replacement" instructions and asserts on the others. Then you can provide support for the asserting instructions that are used for your application. Hopefully as more e500v2 users join in the remaining Book E instructions can be addressed. I'm not sure how viable this path is but considering that the e500v2 is used on embedded network appliances the feature support is more narrowly scoped that on a traditional PowerPC server platform. |
|
@turneyj: Reading through the comments and looking at your fork I'm confused at the current state of this effort. Were you ultimately successful in getting it running on e500v2? Our use-case is to run node.js on a Cisco 819 IoX Router which has an e500v2 core. Dennis Khvostionov |
|
Hey guys, I would like to volunteer remote access to a Freescale based P5020 (e5500-based hardware, POWER ISA 2.06) running Linux 4.2 for anyone who has the time to hack on this. Please contact me directly. Alex Perez |
@mhdawson Unfortunately, the link seems to be dead. |
Greetings. I'll like to join the effort to help port v8 to Freescale. I read through the related issues here and would like to start by cross-compiling a static lib version of v8 for our target (P1010/e500v2), run the d8 shell and observe the SIGKILL illegal instruction. I downloaded build 293 (most recent successful build) from the build server, built and tested the simulated v8ppc on my Intel host. But I'm having a problem cross-compiling for my target. From the build instructions, I exported our target board compiler with:
export CXX=powerpc-linux-g++
export LINK=powerpc-linux-g++
.. which is my $PATH. Then executed the build, which fails with:
The v8 build instructions recommend 4.6 or above for GCC, but we're currently using version 3.4.5. Now that I'm typing this it seems pretty obvious I need a newer compiler?
Thanks,
Gary
The text was updated successfully, but these errors were encountered: