Re: brokenlc040 and FPU-less plans?

> > I think there is no easy hope to have borken LC's CPU to work.  
> Neither
> > NetBSD nor Linux can and it wouldn't really make much sesne.
> > The best method would do to make a distribution compiled without FPU
> > instructions and then take care to compile the rest w/o them. This is
> > what NetBSD did.

Yeah, that's exactly the point. If openbsd ever runs on borken LC040s,  
it will be because someone compiled without FPU instructions. In other  
words, someone like me, but with time and money to match the  
masochistic tendencies, will have to apply the no-fpu option on gcc to  
the whole source tree.

> > To have 030 and "sane" LC040 (if they exist) work we need FPU
> > emulation.

My two cents, emulation is the wrong tree to bark up. Unless you want  
to modify the compiler to insert a NOP before every FPU instruction.

The best approach is to simply treat the fpu-less macs as a separate  
architecture, and compile the whole tree with the no-fpu options.  
Because of resource limitations and such I know that's not going to fly  
as an official activity at openbsd, so the next best hope is to get a  
full 040 myself, see if John, Bruce, or Kazu over at netbsd can give me  
some hints about the no-fpu options, and start compiling.

Or maybe there's someone else as crazy as me over here. Thus my  
question.

> > I don't know if that is currently working in OpenBSD.
> > NetBSD and LInux have 'provisions' for that but not all instructions
> > areimplemented yet, even if there was progress.
>
> I hope those trying to address the LC040 FPU problem are aware of the
> mask bug in some 68LC040 CPU's...
>
> <http://lists.debian.org/debian-68k/2000/debian-68k-200008/ 
> msg00076.html>:
>
> [My note:  Is 68EC040 a typo?

Given the source of the information, it might not be. Wonder if the  
mask sets for the EC and LC parts were numbered the same.

>  Do they really mean 68LC040?  I suspect
> one should read it assuming so.]
>
>          - 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
>            problem.
>          - 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.

Blast from the past. OS9/68K did, I think, run on the 68EC040 chips,  
not that it's relevant here.

>            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.