ARM GCC compiler issue

Ohshima, Yoshiki Yoshiki.Ohshima at disney.com
Tue Feb 26 22:07:09 UTC 2002


  Hello,

> > 	double loadFloatOrIntFrom(int floatOrInt);
> > 	int primitiveFloatAddtoArg(int rcvrOop, int argOop);
> > 	int primitiveFloatDividebyArg(int rcvrOop, int argOop);
> > 	int primitiveFloatEqualtoArg(int rcvrOop, int argOop);
> > 	int primitiveFloatGreaterthanArg(int rcvrOop, int argOop);
> > 	int primitiveFloatLessthanArg(int rcvrOop, int argOop);
> > 	int primitiveFloatMultiplybyArg(int rcvrOop, int argOop);
> > 	int primitiveFloatSubtractfromArg(int rcvrOop, int argOop);
> Excellent idea. If you could zip it up with whichever .h files etc it
> needs and send me a copy I can pass it on when discussing this bug with
> People Who Seem To Know. Much quicker and simpler than the entire vm
> codebase.

  I was trying to isolate the problem, but as you wrote
below, it seems to me that it depends a subtle state right
before the instruction gets executed.  A 50 line of C-code
whose compiled code is very similar does work perfectly.

  I guess there would be some instructions or macro to
initialize the emulator and trying to objdump'ing crt1.o,
but so far with no luck...

> >   Then, I tried to replace "mvfd f4, f0" lines in assembly
> > with "mov r0, r0" (the mnemonic in gcc generated asm is
> > "mvfd").  The executable doesn't crash with "illegal
> > instruction" but doesn't run correctly either.
> This might be a case of changing too many instances of the movfd - I'm
> guessing that some of them need to be there and others
> don't.

  In the above functions begins with 'primitive...', the
C-code look like:

---------------
	int primitiveFloatDividebyArg(int rcvrOop, int argOop) {
	    double rcvr;
	    double arg;
	
		rcvr = loadFloatOrIntFrom(rcvrOop);
		arg = loadFloatOrIntFrom(argOop);
		if (successFlag) {
                    <calculation on rcvr and arg>
---------------
.  It appears that the return value is returned via the
register f0 if the value is double (is it actually a
register pair?).  Because of this, between the two calls on
loadFloatOrIntFrom, the first return value need to be stored
somewhere and the compiler decides to "move" the contents of
f0 to f4.  In the above file, the all instnaces of movfd is
doing this.  So, all of them are unreplacable with nop.

> The basic explanation that has been passed to me is that the FP emulator
> is not properly setup when the instruction is issued and that the Acorn
> FP code was able to cope by some miracle. Since then (about early last
> year I think?) a 'new improved' FP emulator has been released that
> doesn't work. So much for improved....

  Sad story.  I'm still working without instruction set
manual.  Is there any way to setup the emulator properly?

  I also tried to use soft float.  It compiles, but the VM
crashes with a segv.  The Squeak stack trace is something
like:

  View>displayBorder
  View>display
  View>displayDeEmphasized
  ControlManager>restore

I didn't want to do this yesterday, but now I think I'm
going to compile GDB and to narrow down where it crashes...

-- Yoshiki



More information about the Squeak-dev mailing list