[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

LC040 FPU emulation (was: Illegal instruction)

>> until it needed reboot. After reboot it tried to run
>> dpkg-reconfigure base-system
>> from inittab but nothing happened. Investigation showed that
>> dpkg-reconfigure aborted with 'Illegal instruction'.
>> First I thought that it was my buggy LC040 but the famous FPU emulation
>> bug only trigers on some sequence of FPU commads (FLINE exception is not
>> raised). I doubt that dpkg-reconfigure uses floating point so it must be
>> some other kind of error.

JaW> Surprisingly many programs use floating point, maybe that too.

Oh. It appears that dpkg-reconfigure is a Perl script using several modules
so yes, proably floating point is used somewhere.

How can I fix it? :-)))

One possibility should be patching gcc to add a NOP where necessary (as the
errata document says). So i should recompile the whole debian-m68k distro.
Possible, but only after I finally buy my new computer.

Another solution would be to use soft fpu option for gcc but I don't like this

A wild idea: if the appropriate exception is not generated, why do I get an
'Illegal instruction' exception? If I catch all the other exceptions and check
whether there was a FPU instruction before the problem, would it help?

If there are cases where no exception is generated and the fpu instruction just
silently fails then this is not an option. But I don't know m68k assembly well
enough (in fact, I don't know any of it, but it was quite readable with z80 and
8086 assembler experience). Can the FPU instruction fail silently?

_If_ it can't fail silently on the same or the next instruction then it should
be possible to trap the exception and go back and emulate the fpu instruction.
Or am I missing something?

For reference, here is an excerpt from the errata document about EC040 ja

        ELTEC Elektronik Mainz                     Addendum Revision 1 D
        EUROCOM-17-5xx/6xx                Dual 68040 Board with Graphics


        5. Using the 68EC040 micoprocessor

        - The Microware ULTRA C Compiler does not run on MC68EC040

        - MC68EC040 processors with mask 02E23G does not handle FPU
          instructions correctly. This failure occurs if a write
          instruction is followed immediatly by a FPU instruction.
          The CPU does not generate a correct FLINE exception and so
          the FPU emulation will not work.
          This bug will be fixed in mask 02E71.

        5.1 Workarounds for MC68EC040 FPU problem

        - Insertion of a NOP before the FPU instruction solves the
        - Using an adequate compiler option preventing the generation
          of FPU instructions solves the problem.
        - Code generated by the ULTRA C Compiler (UCC) version 1.0 does
          not run on the MC68EC040. This is due to a FMOVEM instruction
          generated by the compiler for any function call.
        - The UCC version 1.1, 1.2 and the GNU-Compiler generate FPU
          instructions only if float functions are used. So some problems
          may be fixed using a newer UCC version.

          The problems described in this paragraph are independent of the
          OS9 version used on the system.
          Microware Utilities compiled with the UCC on OS9-V3.0 may possibly
          contain FPU instructions. So the ftp utility seems to have this
          problem. There are no further problems known with other utilities
          at this time.


Does this give any additional idea to somebody?

I would like to try and fix it if possible.

Where can I download a good manual/handbook about m68k assmebly language?

Why I don't get a real 68040: nobody here has a spare 68040 and I don't want to
order one from some faraway place - the chip plus transport would cost more
than the whole computer! If I find a spare 68040 somewhere I will of course try
it but I don't see any at the moment.

And afterall: I got the Mac for running linux and I knew there will be
problems. That's what it is for: hacking something in the evenings.

Meelis Roos (mroos@linux.ee)

Reply to: