Bochs x86 PC emulator

Hi Stanislav,

> Exactly the same result in DOS prompt.
> Also I actually followed with Bochs debugger all the program in Win98 mode
> and it had no any exceptions ...

Now I think I have found the reason for the difference in our tests: you can 
do it only on a Windows host and I did it on Linux only. Today I repeated the 
test on Windows and got the same result as you got. The behaviour of the 
cpu/fpu emulation seems to be host dependant - this should never happen!
I'll try to find out what's going wrong in the Bochs code.

While doing my tests with different configs and setup I have found another 
problem and I think you should have a look at it. Bochs compiled with SMP 
exits when booting a Linux guest in single CPU mode. The cpu_loop() quits 
when Linux probes the CPU.

--
Bye

Volker

I'll try Linux host tomorrow on my work computer.
About SMP problem, could you elaborate a bit ? Which Linux image you use ?

Thanks,
Stanislav

-----Original Message-----
From: Volker Ruppert [mailto:info@...] 
Sent: Wednesday, September 12, 2007 8:26 PM
To: bochs-developers@...
Cc: Stanislav
Subject: Re: [Bochs-developers] FPU type detection

Hi Stanislav,

> Exactly the same result in DOS prompt.
> Also I actually followed with Bochs debugger all the program in Win98 mode
> and it had no any exceptions ...

Now I think I have found the reason for the difference in our tests: you can

do it only on a Windows host and I did it on Linux only. Today I repeated
the 
test on Windows and got the same result as you got. The behaviour of the 
cpu/fpu emulation seems to be host dependant - this should never happen!
I'll try to find out what's going wrong in the Bochs code.

While doing my tests with different configs and setup I have found another 
problem and I think you should have a look at it. Bochs compiled with SMP 
exits when booting a Linux guest in single CPU mode. The cpu_loop() quits 
when Linux probes the CPU.

--
Bye

Volker

Hi Stanislav,

> I'll try Linux host tomorrow on my work computer.

I have added a BX_INFO here after FCOMPP to show the status. On Linux it 
reports 4501 and on Windows the value is 0104. Tomorrow I'll do some more 
tests.

> About SMP problem, could you elaborate a bit ? Which Linux image you use ?

I tried a few Linux versions with the same result. It happens even with the 
DLX Linux image distributed with Bochs. I guess it happens when checking the 
HLT instruction.

--
Bye

Volker

(apologies if this is a duplicate, I think the last one got
eaten by the html filter).

Hi, I just wanted to drop a note saying how much I appreciated
Bochs. For my project, a new operating system, I originally
envisioned having a separate computer just for that work, due to
the danger in bringing up "direct to hardware" code on my main
machine. Because I had heard of Bochs, I gave it a try -- and
was stepping through my bootstrap code within a day.

I have brought up a direct boot before, an embedded system using
the 64 bit AMD processors. I did that job without a debugger,
just blood and guts debugging. I'm convinced that it would have
taken half as long with Bochs.

Thanks again.

Scott Moore

Hi Volker,

Just tested on Linux host:

> uname -a
Linux 2.6.5-7.276.PTF.196309.1-bigsmp #1 SMP Mon Jul 24 10:45:31 UTC 2006
i686 i386 GNU/Linux 

The result is the same, 387/487 FPU. Which host do you try?
Could you trace your testcase with debugger starting from FINIT and till the
test decided?
Just do 'step' and 'info fpu' after the test begun and send me the output.

Thanks,
Stanislav


-----Original Message-----
From: Volker Ruppert [mailto:info@...] 
Sent: Wednesday, September 12, 2007 8:26 PM
To: bochs-developers@...
Cc: Stanislav
Subject: Re: [Bochs-developers] FPU type detection

Hi Stanislav,

> Exactly the same result in DOS prompt.
> Also I actually followed with Bochs debugger all the program in Win98 mode
> and it had no any exceptions ...

Now I think I have found the reason for the difference in our tests: you can

do it only on a Windows host and I did it on Linux only. Today I repeated
the 
test on Windows and got the same result as you got. The behaviour of the 
cpu/fpu emulation seems to be host dependant - this should never happen!
I'll try to find out what's going wrong in the Bochs code.

While doing my tests with different configs and setup I have found another 
problem and I think you should have a look at it. Bochs compiled with SMP 
exits when booting a Linux guest in single CPU mode. The cpu_loop() quits 
when Linux probes the CPU.

--
Bye

Volker

I fixed the Linix SMP issue.

Thanks,
Stanislav

-----Original Message-----
From: bochs-developers-bounces@...
[mailto:bochs-developers-bounces@...] On Behalf Of Volker
Ruppert
Sent: Thursday, September 13, 2007 12:31 AM
To: Stanislav
Cc: bochs-developers@...
Subject: Re: [Bochs-developers] FPU type detection

Hi Stanislav,

> I'll try Linux host tomorrow on my work computer.

I have added a BX_INFO here after FCOMPP to show the status. On Linux it 
reports 4501 and on Windows the value is 0104. Tomorrow I'll do some more 
tests.

> About SMP problem, could you elaborate a bit ? Which Linux image you use ?

I tried a few Linux versions with the same result. It happens even with the 
DLX Linux image distributed with Bochs. I guess it happens when checking the

HLT instruction.

--
Bye

Volker

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
bochs-developers mailing list
bochs-developers@...
https://lists.sourceforge.net/lists/listinfo/bochs-developers

Hi Stanislav,

> Just tested on Linux host:
> > uname -a
>
> Linux 2.6.5-7.276.PTF.196309.1-bigsmp #1 SMP Mon Jul 24 10:45:31 UTC 2006
> i686 i386 GNU/Linux

OpenSuSE 10.2:
> uname -a
Linux 2.6.18.8-0.5-default #1 SMP Fri Jun 22 12:17:53 UTC 2007 i686 athlon 
i386 GNU/Linux

> gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.

> The result is the same, 387/487 FPU. Which host do you try?
> Could you trace your testcase with debugger starting from FINIT and till
> the test decided?
> Just do 'step' and 'info fpu' after the test begun and send me the output.

In the meantime I did some different tests by adding BX_INFOs and printf's in 
the sources:

Status before FDIV: 0000
Windows status after FDIV: 0004
Linux status after FDIV: 0001

The exponent of argument 'a' is different after reading from FPU register 
before FDIV:
Windows: 16383
Linux: 0

--
Bye

Volker

Aaaa, now I understand everything !
I bet on Windows host you have gcc 3.x, right ?
Throw away gcc version 4, or may be even better open a bug report for it.

It generates wrong code causing wrong results, we already similar issue
before, you could refer another bug report as example.

http://sourceforge.net/tracker/index.php?func=detail&aid=1526255&group_id=12
580&atid=112580

I also seen the same complains in QEMU forum. Replace gcc with older version
and it will work fine under any host.

Thanks,
Stanislav

P.S> It would be interesting to see what is the difference between gcc 3.x
compiled Bochs FPU and gcc 4.x compiled ... wondering what is the reason for
the problem ...

-----Original Message-----
From: Volker Ruppert [mailto:info@...] 
Sent: Thursday, September 13, 2007 9:17 PM
To: Stanislav
Cc: bochs-developers@...
Subject: Re: [Bochs-developers] FPU type detection

Hi Stanislav,

> Just tested on Linux host:
> > uname -a
>
> Linux 2.6.5-7.276.PTF.196309.1-bigsmp #1 SMP Mon Jul 24 10:45:31 UTC 2006
> i686 i386 GNU/Linux

OpenSuSE 10.2:
> uname -a
Linux 2.6.18.8-0.5-default #1 SMP Fri Jun 22 12:17:53 UTC 2007 i686 athlon 
i386 GNU/Linux

> gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.

> The result is the same, 387/487 FPU. Which host do you try?
> Could you trace your testcase with debugger starting from FINIT and till
> the test decided?
> Just do 'step' and 'info fpu' after the test begun and send me the output.

In the meantime I did some different tests by adding BX_INFOs and printf's
in 
the sources:

Status before FDIV: 0000
Windows status after FDIV: 0004
Linux status after FDIV: 0001

The exponent of argument 'a' is different after reading from FPU register 
before FDIV:
Windows: 16383
Linux: 0

--
Bye

Volker

Hi Stanislav,

> I also seen the same complains in QEMU forum. Replace gcc with older
> version and it will work fine under any host.

You are right, the compiler versions in Cygwin and MinGW/MSYS are 3.x. The 
code produced by the MSVC toolkit is okay, too. OpenSUSE 10.2 usually uses 
the GCC 4.x, but there is a GCC 3.3.5 in the source package of QEMU. I'll try 
to build this package and then I intend to use it for building the Linux 
release binary.

I'll try to make the release on Sunday, unless there are important bugs to 
fix.

> P.S> It would be interesting to see what is the difference between gcc 3.x
> compiled Bochs FPU and gcc 4.x compiled ... wondering what is the reason
> for the problem ...

See the attached patch. It makes FLD1 work with this buggy GCC 4.x.

--
Bye

Volker