Mail Archives: djgpp/1996/08/02/06:22:03
> > > I'd expect that Linux's FP emulator would handle the lack of a co-processor
> > > even for DJGPP programs, but in fact neither gcc nor programs compiled
> > > with it will run without that in the environment. WITH it, everything but
> > > make works. I dunno what's happening.
Basically this could happen if Linux's FPU did not return the values expected
of it when djgpp does the FPU test/cannot because of the linux implementation of
dosemu. I don't think djgpp should be allowed to turn off FPU emulation from
within dosemu: sounds likea security flaw if it could.
> > Do you mean that other programs that use floating point (except Make) run
> > on your system? Try to write a trivial program that does some FP
> > computations and see if it bombs.
> >
> Hmmmmm...
> What I thought was happening wasn't as weird as what IS happening.
> It's true that if, under DOSEMU, I don't set both 387=N and
> EMU387=c:\djgpp\bin\emu387.dxe that gcc won't run--it bombs with an
> FP exception.
>
> What's also true is that (with those vars set) I can compile a program
> such as the following one:
>
> #include <stdio.h>
> main()
> {
> float a, b, c;
>
> a = 4.0;
> b = 3.0;
> c = a*b;
> }
> andn run it without any crash or other messages. (do I assume it actually
> performed the floating point math?? I'll check it under GDB later.)
>
> If I add a line like printf ("%f\n", c); to the program it hangs for
> longer than I care to wait. While it's hung, I can see that top shows
> that dosemu is eating about 85% of the CPU. I can ^C out of the program
> then the usage shown by top drops down to a much more reasoanble level.
Since djgpp uses signals, I believe, for FPU emulation, could be that the
the signals are not working properly under dosemu: eg it does not save the
state of the machine to reenter the code, in certain cases. Then it returns
to the wrong place, and CRUNCH!
Since I'm not completely sure of the above, anyone else on the list care to
comment?
Sengan
- Raw text -