pc386dx exception 6 was Re: 4.6.0pre2 and docs released

[Joel Sherrill]

Chris Caudle wrote:
> 
> Angelo Fraietta wrote:
> > I am running the pc386dx BSP.
> 
> Joel replied:
> > generates an instruction that is not valid for
> > an i386DX.  It is also possible that your CPU model
> > is just enough not an i386dx where something
> > has finally shown up.
> 
> Confusingly, I believe the pc386dx BSP is actually for an i386SX processor.
> The DX processors include a FP coprocessor, the SX processors do not include 
> a floating point unit.  The pc386dx BSP really means software simulation of 
> a DX processor, i.e. software floating point libraries.

I am showing my age here and since all of this is from memory forgive me
for any minor blunders.  :)  

i386SX has a 16-bit bus and no FPU
i386DX has a 32-bit bus and optional FPU (i387)

The big deal with the i486DX was the integration of FPU and CPU onto one
chip.
But Intel also made the i486SX (no FPU) and an "upgrade" I don't
remember
the exact name of which essentially disabled the main CPU and was
functionally
an i486DX.

There are other variations like the i386EX which is a 16-bit bus, no
FPU, and
some on-CPU peripherals.

Now to make matters ugly.  Some of the non-Intel x86 clones have weird 
variations in the instruction set and have to be treated as a different
CPU model than you would initially guess.

On BSPs, pc386 assumes an i386DX+i387 FPU.  
pc386dx assumes an i386DX with NO FPU and thus soft-float.

> 
> I seem to recall that soft floating point support has been an area of problems in the past, perhaps similar problems have resurfaced with the latest tool chain?

Software floating point exceptions SHOULD be a "coprocessor unavailable"
or #7.  

I am suspicious that the CPU is not an Intel variety and should be
treated
as a different CPU model.  If Angelo can track the address down to a
single
instruction (ala printed message plus objdump) and tell us the CPU
model, 
we can confirm or discredit that.

> -- Chris Caudle