d8 does not run on G4 Mac

[spotlightishere]

Yes, I've read lots of the other G4 related problems. But, I don't think this is related.

• I believe this was compiled using clang
• Snapshot was off (it doesn't work anyway)
• I ran GDB on it and got this:

(gdb) run
Starting program: /home/me/g4compat/out/ppc.release/d8 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
[New Thread 0x4883d480 (LWP 28348)]

Program received signal SIGILL, Illegal instruction.
0x5185ebe8 in ?? ()
(gdb) x/20i $pc
=> 0x5185ebe8:  fcfid   f1,f1
   0x5185ebec:  clrlwi. r0,r5,31
   0x5185ebf0:  srawi   r11,r5,1
   0x5185ebf4:  beq     0x5185ed70
   0x5185ebf8:  lwz     r11,-1(r5)
   0x5185ebfc:  cmpw    cr7,r11,r8
   0x5185ec00:  bne     cr7,0x5185ee1c
   0x5185ec04:  lfd     f2,3(r5)
   0x5185ec08:  fctidz  f0,f2
   0x5185ec0c:  addi    r1,r1,-8
   0x5185ec10:  stfd    f0,0(r1)
   0x5185ec14:  ori     r2,r2,0
   0x5185ec18:  lwz     r10,0(r1)
   0x5185ec1c:  lwz     r11,4(r1)
   0x5185ec20:  addi    r1,r1,8
   0x5185ec24:  srawi   r0,r11,31
   0x5185ec28:  cmpw    cr7,r0,r10
   0x5185ec2c:  bne     cr7,0x5185ec38
   0x5185ec30:  fcfid   f0,f0
   0x5185ec34:  fcmpu   cr7,f0,f2
(gdb) 

If you need other info, please ask.

[spotlightishere]

Oh yeah, this was compiled from the g4compat branch. I should have added that.

[turneyj]

Other knowledgeable folks should check me on this, but ...

The PowerPC 74xx family of processors don't support the Book E floating point instructions, including fcfid (floating point convert from int) which triggered the exception you encountered. The full list of unsupported instructions for this processor is in "Appendix B - Instructions Not Implemented" in http://www.freescale.com/files/32bit/doc/ref_manual/MPC7410UM.pdf

I'm working on a similar issue for Freescale's e500v2 - #119

The e500v2 has a set of closely related double-precision floating point instructions. These can be used by lithium (the v8 machine code generator) as substitutes for the standard book E FPU instructions currently implemented in v8ppc. These "e500v2-only" instructions are described in section 10.4 - Double-Precision Floating-Point APU (e500 v2 Only) of the PowerPC e500 Core Family Reference Manual, Rev. 1 - http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf

Unfortunately Freescale only implemented these "alternate" FP instructions in the e500v2. The solution will be a bit more complicated if no alternate DPFP instructions exist. We should implement the e500v2 support in a way that can extend to other Freescale cores which don't support the Book E FP implementation.

[spotlightishere]

I'm not on OS X right now (linux is faster) but with Xcode 3.2, they have an instruction reference book. I don't think it's legal to share it but it has some important tips and usage things.

[mhdawson]

I was thinking the issue was as outlined by Gary (turneyj) I had just not confirmed that fcfid was one of the unsupported instructions which it looks like he already has.

[spotlightishere]

Ok so we need a workaround?

[spotlightishere]

Yes, according to my book fcfid is 64-bit, whereas mine is 32 bit.

[turneyj]

Hmmm - I wonder why a 32 bit v8ppc implementation emits a 64 bit instruction.

But even if you built a 64 bit v8ppc, the 74xx core will generate an illegal instruction exception for fcfid, since it has no register support for DPFP.

I'm wondering what is the minimum double-precision floating-point (DPFP) support for a embedded network device (i.e. Freescale core) running node on v8ppc. I'm not familiar with the node test cases beyond just running them but if there was a way to identify which node APIs depend on the unsupported DPFP instructions, the Freescale porting effort could be reduced to accommodate what would be considered acceptable for an embedded network device running node. The unsupported DPFP instructions could be handled through the "not supported" exception which uses a different event notification than illegal instruction.

The node tests hit 10 out of the 40 or so unsupported instructions. So the acceptable Freescale DPFP support may be something less than 10 instructions.

[spotlightishere]

I haven't run tests -- mostly because the Excuable itself won't run. However, I do agree about running something else, but I'm not an assembly expert.

Sent from my iPad

On Sun, Dec 28, 2014 at 4:05 PM, Gary Jones [email protected]
wrote:

Hmmm - I wonder why a 32 bit v8ppc implementation emits a 64 bit instruction.
But even if you built a 64 bit v8ppc, the 74xx core will generate an illegal instruction exception for fcfid, since it has no register support for DPFP.
I'm wondering what is the minimum double-precision floating-point (DPFP) support for a embedded network device (i.e. Freescale core) running node on v8ppc. I'm not familiar with the node test cases beyond just running them but if there was a way to identify which node APIs depend on the unsupported DPFP instructions, the Freescale porting effort could be reduced to accommodate what would be considered acceptable for an embedded network device running node. The unsupported DPFP instructions could be handled through the "not supported" exception which uses a different event notification than illegal instruction.

The node tests hit 10 out of the 40 or so unsupported instructions. So the acceptable Freescale DPFP support may be something less than 10 instructions.

Reply to this email directly or view it on GitHub:
#120 (comment)

[andrewlow]

Caught me on a holiday break from the computer -- @tunniclm had done some hacking here and gotten most of the way to making it work on the G4 (under Linux). He captured most of the work in this branch https://github.com/andrewlow/v8ppc/tree/g4compat .. probably out of date at this point, but should have been in a working state.

[spotlightishere]

@andrewlow I did compile that from the g4compat branch, and it has an illegal instruction for me.

[tunniclm]

@awesomebing1 Hi, fcfid is one of the instructions that the g4compat branch should be avoiding. It does attempt to detect incompatible processors, so it may be that the detection is not triggering.

Can you run LD_SHOW_AUXV=1 /bin/true to check the processor name? Currently the code is quite restricted and only checks for specific known processors, and will assume it has found a G4 if the AT_PLATFORM is 'ppc7450'.

[spotlightishere]

That's a pretty cool command. Yes, the platform is ppc7450.

If it was compiled with clang and snapshot off, would that make a difference?

Sent from my iPad

On Mon, Jan 5, 2015 at 5:59 AM, Mike Tunnicliffe [email protected]
wrote:

@awesomebing1 Hi, fcfid is one of the instructions that the g4compat branch should be avoiding. It does attempt to detect incompatible processors, so it may be that the detection is not triggering.

Can you run LD_SHOW_AUXV=1 /bin/true to check the processor name? Currently the code is quite restricted and only checks for specific known processors, and will assume it has found a G4 if the AT_PLATFORM is 'ppc7450'.

Reply to this email directly or view it on GitHub:
#120 (comment)

[andrewlow]

Next step would be to try to identify WHERE this fcfid is being emitted from.

You could put a breakpoint into the src/ppc/assembler-ppc.cc code where it emits the instruction. I'm actually a bit suspicious of clang possibly sneaking it in, do you have proof that clang works ok?

[tunniclm]

0x5185ec08:  fctidz  f0,f2
0x5185ec0c:  addi    r1,r1,-8
0x5185ec10:  stfd    f0,0(r1)
0x5185ec14:  ori     r2,r2,0
0x5185ec18:  lwz     r10,0(r1)
0x5185ec1c:  lwz     r11,4(r1)
0x5185ec20:  addi    r1,r1,8
0x5185ec24:  srawi   r0,r11,31
0x5185ec28:  cmpw    cr7,r0,r10
0x5185ec2c:  bne     cr7,0x5185ec38
0x5185ec30:  fcfid   f0,f0
0x5185ec34:  fcmpu   cr7,f0,f2

That chunk looks a lot like something that would be emitted by EmitVFPTruncate() [macro-assembler-ppc.cc:2370] if the call to EmitVFPTruncate_NoPPC64() was not taken.

I can't recognise where the start of the chunk you posted comes from though.

[spotlightishere]

Yes. My clang does work. I have not encountered any errors. It's clang 3.5 compiled with clang 3, on Debian. I can add a breakpoint later.

Sent from my iPad

On Mon, Jan 5, 2015 at 10:08 AM, Mike Tunnicliffe
[email protected] wrote:

0x5185ec08:  fctidz  f0,f2
0x5185ec0c:  addi    r1,r1,-8
0x5185ec10:  stfd    f0,0(r1)
0x5185ec14:  ori     r2,r2,0
0x5185ec18:  lwz     r10,0(r1)
0x5185ec1c:  lwz     r11,4(r1)
0x5185ec20:  addi    r1,r1,8
0x5185ec24:  srawi   r0,r11,31
0x5185ec28:  cmpw    cr7,r0,r10
0x5185ec2c:  bne     cr7,0x5185ec38
0x5185ec30:  fcfid   f0,f0
0x5185ec34:  fcmpu   cr7,f0,f2

That chunk looks a lot like something that would be emitted by EmitVFPTruncate() [macro-assembler-ppc.cc:2370] if the call to EmitVFPTruncate_NoPPC64() was not taken.

I can't recognise where the start might come from though.

Reply to this email directly or view it on GitHub:
#120 (comment)

[andrewlow]

Weird - I just checked out the g4compat branch.

$ cd v8ppc/src/ppc
$ grep fcfid *
assembler-ppc.cc:void Assembler::fcfid(const DwVfpRegister frt,
assembler-ppc.h:  void fcfid(const DwVfpRegister frt, const DwVfpRegister frb,
code-stubs-ppc.cc:  __ fcfid(double_dst, double_dst);
disasm-ppc.cc:      Format(instr, "fcfid'.  'Dt, 'Db");
macro-assembler-ppc.cc:    fcfid(double_scratch, double_scratch);

So code-stubs-ppc.cc and macro-assembler-ppc.cc would be the two locations where I'd expect to see this instruction.

code-stubs-ppc.cc

  // Convert to double word FP from stack
  __ lfd(double_dst, MemOperand(sp, 0));
  __ fcfid(double_dst, double_dst);

  __ addi(sp, sp, Operand(8));  // restore stack

macro-assembler-ppc.cc

    // convert back and compare
    fcfid(double_scratch, double_scratch);
    fcmpu(double_scratch, double_input);
    bind(&done);

Neither of them seem to be the sequence that matches the bad one.

=> 0x5185ebe8:  fcfid   f1,f1
   0x5185ebec:  clrlwi. r0,r5,31
   0x5185ebf0:  srawi   r11,r5,1
   0x5185ebf4:  beq     0x5185ed70
   0x5185ebf8:  lwz     r11,-1(r5)

Feels like I'm missing something here?

[spotlightishere]

Ok. I recompiled everything with gcc. I got the same Illegal instruction (and backtrace, except for the addresses) as the one with clang. I can add a hook, in a minute.

[barracuda156]

So does it work on MacOS PowerPC in the current state or not? I need V8 for some R functionality.