Hello,
I'm trying to port Squeak to US version Zaurus (developer.sharpsec.com) and it is getting to work. I knew Tim mentioned couples of times about the GCC bug, but I was narrowly hoping that the bug is fixed in the toolchain which Sharp is providing.
Unfortunately, it isn't fixed and I'm bitten by the bug. If I compile the VM without optimization, it (sort of) works on the PDA, but when I turn on the optimization, the process says "Illigal instruction" and quits.
Virtually, there is no way for me to narrow down which function(s) in the VM causes the problem. So, does anyone have a program sniplet that triggers this compiler bug? I want to take a look at it and ultimately I want to let Sharp to fix it:-)
Thank you,
-- Yoshiki
Kevin Fisher kgf@golden.net has ported the Squeak VM to ARM Linux for the iPAQ, so that should work for the Zaurus. He's worked through the toolchain issues, so you might want to talk with him.
--- Noel
Hello,
Kevin Fisher kgf@golden.net has ported the Squeak VM to ARM Linux for the iPAQ, so that should work for the Zaurus. He's worked through the toolchain issues, so you might want to talk with him.
I somehow assumeed his port uses X11 and lately uses direct access to the frame buffer. Is this right? If so, it doesn't work on Zaurus because it uses Qtopia as GUI framework. I started from the unix source tree and made up a set of functions which bind the interpreter and Qtopia.
I know Kevin is working on it. That's why I posted a message to squeak mailing list rather than sending directly to Tim!
Thank you for the suggestions. It is true that I should have done research before. A quick google'ing direct me to 'Qtalk', but I couldn't find the page itself...
-- Yoshiki
"Noel J. Bergman" noel@devtech.com is claimed by the authorities to have written:
Kevin Fisher kgf@golden.net has ported the Squeak VM to ARM Linux for the iPAQ, so that should work for the Zaurus. He's worked through the toolchain issues, so you might want to talk with him.
I remember Kevin having exactly the same issues though; it is of course possible that the gcc has been fixed since then as it must be over a year ago. I'm hoping it gets fixed sometime soon since I'd really like to get decent performance for both Squeak and VW on my NetWinder. tim
"Ohshima, Yoshiki" wrote:
Hello,
I'm trying to port Squeak to US version Zaurus (developer.sharpsec.com) and it is getting to work. I knew Tim mentioned couples of times about the GCC bug, but I was narrowly hoping that the bug is fixed in the toolchain which Sharp is providing.
Unfortunately, it isn't fixed and I'm bitten by the bug. If I compile the VM without optimization, it (sort of) works on the PDA, but when I turn on the optimization, the process says "Illigal instruction" and quits.
Virtually, there is no way for me to narrow down which function(s) in the VM causes the problem. So, does anyone have a program sniplet that triggers this compiler bug? I want to take a look at it and ultimately I want to let Sharp to fix it:-)
I far as remember there was some floating point issues.
Karl
Karl Ramberg karl.ramberg@chello.se is claimed by the authorities to have written:
I far as remember there was some floating point issues.
That's about it; what seems to happen is that a fp instruction is placed in the function preamble when optimization is on. This fp instruction is not acceptable to the FP-emulator module and it go boom. Under the earlier fp-emulator (the one licensed from Acorn directly) the instruction was not correct, but tolerated, so no practical problem.
For some reason when no optimisation isused this instruction is not scheduled at all.
tim
Karl Ramberg karl.ramberg@chello.se is claimed by the authorities to have written:
I far as remember there was some floating point issues.
and Tim Rowledge tim@sumeru.stanford.edu
That's about it; what seems to happen is that a fp instruction is placed in the function preamble when optimization is on. This fp instruction is not acceptable to the FP-emulator module and it go boom. Under the earlier fp-emulator (the one licensed from Acorn directly) the instruction was not correct, but tolerated, so no practical problem.
For some reason when no optimisation isused this instruction is not scheduled at all.
Karl -
If this is the problem, and the instruction is unique and identifiable, you might try the same trick we use to make the interpreter on the Mac go faster.
In our case, we scan the interpreter compiled module for the unnecessary check that a byte code is < 256 before the instruction dispatch. When we find it we copy the dispatch back over the test. This saves 15% -- see Interpreter patchInterp:.
In your case, you'll want to look for the offending FP instructions, and replace each one by a no-op. Really tacky, but not as bad as no Squeak ;-).
Good luck!
- Dan
Dan Ingalls Dan@SqueakLand.org is claimed by the authorities to have written:
If this is the problem, and the instruction is unique and identifiable, you might try the same trick we use to make the interpreter on the Mac go faster.
This is devious, evil, unprincipled and brilliant. It might even work.
The instruction you need to look for is movfd f4,f0. I'd suggest replacing it with mov r0,r0. You'll need to do it for every function preamble.
tim
Hi VM Makers
You can do this automaticly in the 'Makefile' by using the '-s' option to 'gcc' to get the assembly code in a file (or pipe). Then use 'sed' or 'awk' to process the file to ferret out and change the offending instructions before passing the code to the assembler. This has worked like a charm for me in other environments.
Cheers, George
Tim Rowledge wrote:
Dan Ingalls Dan@SqueakLand.org is claimed by the authorities to have written:
If this is the problem, and the instruction is unique and identifiable, you might try the same trick we use to make the interpreter on the Mac go faster.
This is devious, evil, unprincipled and brilliant. It might even work.
The instruction you need to look for is movfd f4,f0. I'd suggest replacing it with mov r0,r0. You'll need to do it for every function preamble.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: RCR: Rewind Card Reader
Hi:
You must have hit the optimisation bug.
The only way around it is to compile -without- any optimisation enabled (ie get rid of -O in the Makefile).
I don't believe this has been fixed even for the GCC 3.X series. :(
On Sat, Feb 23, 2002 at 06:01:58PM -0800, Ohshima, Yoshiki wrote:
Hello,
I'm trying to port Squeak to US version Zaurus (developer.sharpsec.com) and it is getting to work. I knew Tim mentioned couples of times about the GCC bug, but I was narrowly hoping that the bug is fixed in the toolchain which Sharp is providing.
Unfortunately, it isn't fixed and I'm bitten by the bug. If I compile the VM without optimization, it (sort of) works on the PDA, but when I turn on the optimization, the process says "Illigal instruction" and quits.
Virtually, there is no way for me to narrow down which function(s) in the VM causes the problem. So, does anyone have a program sniplet that triggers this compiler bug? I want to take a look at it and ultimately I want to let Sharp to fix it:-)
Thank you,
-- Yoshiki
Hello,
Thank you for everyone for the suggestions.
I've created a separate .c file, which I call interp-f.c, for the following functions
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);
and compile the file without optimization. (and optimize the rest of source files.) Actually, this trick seems working, at least for my majorshrink image! The tinyBenchmarks result is something like 10m bytecodes/sec, 400k sends/sec, which is in the range I expect.
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.
# Those instructions doesn't apprear in "preambles" of # functions, but it seems to me that those are the part of # the calling sequence in the caller. I guess it isn't # a nop.
My guesswork says that replacing
mvfd f4, f0
with
mvfd f4, #0 adfd f4, f4, f0
or
sufd f4, f4, f4 adfd f4, f4, f0
would work, but it turned out that both cases raise the illegal instruction exception, too. The compiler emits "mvfd f4, #0" for stackFloatValue, but I guess the executable crash once the function gets called.
I couldn't find the manual on the instcution set of SA-1110 on the web. Do I have to buy a book?
Since many plugins including B3D, B2D, and even BitBlt use C double, I will have to change the tactics, but for now I'll try to go a bit further with the first tactics.
-- Yoshiki
"Ohshima, Yoshiki" Yoshiki.Ohshima@disney.com is claimed by the authorities to have written:
Hello,
Thank you for everyone for the suggestions.
I've created a separate .c file, which I call interp-f.c, for the following functions
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.
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. 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....
tim
Hi,
Have you looked at the fpe that comes with NetBSD? It seems to be used with the sh3, arm26, and arm32 ports. One uses -msoft-float as a flag to gcc and then the calls for floating point are emulated. The file src.tgz at ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.5.2/source/sets/ in the directory usr/src/lib/libc/softfloat has the emulator. I've been poking around with this on a 68k system since the emulator for LC040 chips seems broken.
I doubt that the emulator depends on anything NetBSD specific.
cheers
bruce
Tim Rowledge writes:
"Ohshima, Yoshiki" Yoshiki.Ohshima@disney.com is claimed by the authorities to have written:
Hello,
Thank you for everyone for the suggestions.
I've created a separate .c file, which I call interp-f.c, for the following functions
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.
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. 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....
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: FD: Failsafe Disarmed
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
squeak-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
Dan Ingalls -
George D Detlefsen -
Karl Ramberg -
Kevin Fisher -
Noel J. Bergman -
Ohshima, Yoshiki -
Tim Rowledge