PearPC - PowerPC Emulator

Patrick Naubert wrote:

> Trying to install Mac OS X 10.3.4 with the latest CVS (2004-07-20 21:23
> EST) and getting the famous:
> 
> [CPU/OPC] <Warning> write dec > 20 millisec := 8405395 (840539500)
> [..]
> 
> This happens at the "Processing Mac OS X" installation step.
> These messages have been going by for the last 2 hours.
> If I move the mouse (SDL) the messages will stop, and continue as soon
> as I stop the mouse.  This happens in jitc-generic and jitc-x86.
> I can click on menu items in the installer and I will see the menu items
> popup and the screen refreshes fine. As soon as I stop doing these,
> those messages re-appear.

I suspect this happens because disk io currently blocks the CPU.

> 
> If I let these messages scroll for about 10 minutes, they will end up
> outputting an endless stream of 
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)

Odd.

> 
> If I give pearpc focus again, and move the mouse, the first block of
> messages I pasted in this message will appear.
> 
> As far as I can tell, my installation will never complete; although I
> will let it run through the night and see.
> 
> Nope, an hour later, even the mouse won't move, and that first block of
> message appears.
> 
> I am on Gentoo Linux, kernel 2.4.26
> 
> Any suggestions ?
> 
> Pat
> 

Sebastian

Sebastian Biallas <sb <at> biallas.net> writes:

> 
> Patrick Naubert wrote:
> 

> > If I let these messages scroll for about 10 minutes, they will end up
> > outputting an endless stream of 
> > [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> > [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> > [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> > [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> 
> Odd.
> 

I see the same thing.

> > As far as I can tell, my installation will never complete; although I
> > will let it run through the night and see.

There's some sort of timing(?) problem which people on IRC reported 
doesn't happen on Windows. As a point of information it doesn't 
happen on the same box with a PearPC 0.2.0 build, and has happened 
typically when installing packages either at install or system update 
time with every 0.3pre I've built. I haven't yet figured out the problem. 

I suspect it is more or less this problem:
http://sourceforge.net/tracker/index.php?
func=detail&aid=987376&group_id=108675&atid=651195

Something else I noticed: 0.2.0's clock is slow. 0.3pre's clock is 
hyper: I use ntp to set it to what it should be and in 5 minutes 
it's run about 12 minutes... 

But when the machine gets into the state where the installer 
stops making progress (but I can still run other processes, 
kill things including the process which stopped, etc) the clock 
in the bar at the top right stops advancing, and in some (most?) 
cases jumps to a random earlier time. Opening the time/date
control panel and forcing an NTP sync neither changes nor 
restarts that clock nor the stuck process. My initial guess 
was something went into select() and its timeout never happened.
I don't know for sure yet.

On Wed, 21 Jul 2004 18:11:38 +0000 (UTC), Derrick Brashear
<shadow@...> wrote:
> Something else I noticed: 0.2.0's clock is slow. 0.3pre's clock is
> hyper: I use ntp to set it to what it should be and in 5 minutes
> it's run about 12 minutes...
Odd, I get the exact opposite. On 0.3pre the clock is in perfect sync
or a little behind the real clock and on 0.2 the clock advanced ~4
minutes for every real minute.

> Something else I noticed: 0.2.0's clock is slow. 0.3pre's clock is 
> hyper: I use ntp to set it to what it should be and in 5 minutes 
> it's run about 12 minutes... 

Forcing linux to not USE_POSIX_REALTIME_CLOCK does seem to fix the hyper clock.
It doesn't fix the hang which  this time occurred during the 10.3->10.3.4
upgrade during the "running installer script" phase.

And sure enough I got write decs around then (and no sooner)

Derrick Brashear <shadow <at> dementia.org> writes:

> 
> > Something else I noticed: 0.2.0's clock is slow. 0.3pre's clock is 
> > hyper: I use ntp to set it to what it should be and in 5 minutes 
> > it's run about 12 minutes... 
> 
> Forcing linux to not USE_POSIX_REALTIME_CLOCK does seem to fix the hyper clock.
> It doesn't fix the hang which  this time occurred during the 10.3->10.3.4
> upgrade during the "running installer script" phase.
> 
> And sure enough I got write decs around then (and no sooner)

Putting (considerable) padding around the dec element in the cpu struct doesn't
change the problem at all. (you need to change both ppc_cpu.h and the copies of
the struct in the asm files, which is sort of weird; can nasm not deal with
inclusion? seems like only one of the asm files should need it, not both)

So presumably it's not coming from a too-large write at an earlier offset into
the structure.

On Fri, 23 Jul 2004 18:17:51 +0000 (UTC), Derrick Brashear
<shadow@...> wrote:
> 
> Putting (considerable) padding around the dec element in the cpu struct doesn't
> change the problem at all. (you need to change both ppc_cpu.h and the copies of
> the struct in the asm files, which is sort of weird; can nasm not deal with
> inclusion? seems like only one of the asm files should need it, not both)

You're upset that an assembler can't parse a C structure in a header file?

Am I missing something?

This is although, of course, the reason why I put the AltiVec
registers at the end, so that I didn't change the internal structure
in the ASM files.

Daniel Foesch <krach42 <at> gmail.com> writes:

> > Putting (considerable) padding around the dec element in the 
> > cpu struct doesn't change the problem at all. (you need to change 
> > both ppc_cpu.h and the copies of
> > the struct in the asm files, which is sort of weird; can nasm not 
> > deal with inclusion? seems like only one of the asm files should 
> > need it, not both)
> 
> You're upset that an assembler can't parse a C structure in a header file?

Nope.

> Am I missing something?

You are. jitc_tools.asm and jitc_mmu.asm both have a copy of the 
expanded-for-asm structure included. I'd rather see one copy 
(still set up for asm) in a file included by both of those. Hence the 
comment about one file instead of both ;-)

On Sat, 24 Jul 2004 02:39:03 +0000 (UTC), Derrick Brashear
<shadow@...> wrote:
> Daniel Foesch <krach42 <at> gmail.com> writes:
> 
> > > Putting (considerable) padding around the dec element in the
> > > cpu struct doesn't change the problem at all. (you need to change
> > > both ppc_cpu.h and the copies of
> > > the struct in the asm files, which is sort of weird; can nasm not
> > > deal with inclusion? seems like only one of the asm files should
> > > need it, not both)
> >
> > You're upset that an assembler can't parse a C structure in a header file?
> 
> Nope.
> 
> > Am I missing something?
> 
> You are. jitc_tools.asm and jitc_mmu.asm both have a copy of the
> expanded-for-asm structure included. I'd rather see one copy
> (still set up for asm) in a file included by both of those. Hence the
> comment about one file instead of both ;-)
> 

Ah, yes, I was missing something.  I'm supposing it would be nice to
have them both link in an include.  I don't know enough about NASM to
get this done though.

Using GAS it'd be easy: switch them to .S, instead of .s, and #include ""

But that would also mean they would have to be in AT&T syntax... I
don't know how many of you like that syntax as much as I do, but I'd
rather see it using AT&T syntax.

But I'm a freak. ;)

Derrick Brashear <shadow <at> dementia.org> writes:

> Forcing linux to not USE_POSIX_REALTIME_CLOCK does seem to fix the 
> hyper clock.
> It doesn't fix the hang which  this time occurred during the 10.3->10.3.4
> upgrade during the "running installer script" phase.

Incidentally when I last touched it it seemed like
ppc_get_cpu_ideal_timebase() might be involved, I notice that rdtsc is called 
on x86 linux only, and clock() is called everywhere else. But I doubt the problem
is that simple.

Derrick Brashear <shadow <at> dementia.org> writes:

> 
> Derrick Brashear <shadow <at> dementia.org> writes:
> 
> > Forcing linux to not USE_POSIX_REALTIME_CLOCK does seem to fix the 
> > hyper clock.
> > It doesn't fix the hang which  this time occurred during the 10.3->10.3.4
> > upgrade during the "running installer script" phase.
> 
> Incidentally when I last touched it it seemed like
> ppc_get_cpu_ideal_timebase() might be involved, I notice that rdtsc is called 
> on x86 linux only, and clock() is called everywhere else. But I doubt the 
> problem is that simple.

1) sys_set_timer is being passed (in write_dec) an int64 for nanoseconds, 
but it only takes a long int (32 bits). Mmmmm, truncation. I'll put a 
patch in the sourceforge bug tracker.

2) So, uh, rhetorically, what happens if 
gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()?
It seems like readDEC would deal poorly. It also seems experimentally 
that if I disallow things from ever going back (set itb to 0 when 
gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()) that
it works. I'll include that in the patch.

Derrick Brashear <shadow <at> dementia.org> writes:

> 2) So, uh, rhetorically, what happens if 
> gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()?
> It seems like readDEC would deal poorly. It also seems experimentally 
> that if I disallow things from ever going back (set itb to 0 when 
> gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()) that
> it works. I'll include that in the patch.

setting itb to 0 and not say something small but non-zero might be a 
mistake. in fact thinking about it, I think i'd argue it should never
be zero, at least as long as we're pretending to be uniprocessor.

Why don't we print out some debug data on what values this actually
happens for, and then using that data, we can look at what needs to be
done to correct the problem.

On Tue, 27 Jul 2004 00:47:00 +0000 (UTC), Derrick Brashear
<shadow@...> wrote:
> Derrick Brashear <shadow <at> dementia.org> writes:
> 
> > 2) So, uh, rhetorically, what happens if
> > gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()?
> > It seems like readDEC would deal poorly. It also seems experimentally
> > that if I disallow things from ever going back (set itb to 0 when
> > gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()) that
> > it works. I'll include that in the patch.
> 
> setting itb to 0 and not say something small but non-zero might be a
> mistake. in fact thinking about it, I think i'd argue it should never
> be zero, at least as long as we're pretending to be uniprocessor.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Pearpc-devel mailing list
> Pearpc-devel@...
> https://lists.sourceforge.net/lists/listinfo/pearpc-devel
>

Derrick Brashear wrote:
> Derrick Brashear <shadow <at> dementia.org> writes:
> 
>>2) So, uh, rhetorically, what happens if 
>>gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()?
>>It seems like readDEC would deal poorly. It also seems experimentally 
>>that if I disallow things from ever going back (set itb to 0 when 
>>gDECwriteITB is larger than ppc_get_cpu_ideal_timebase()) that
>>it works. I'll include that in the patch.
> 
> setting itb to 0 and not say something small but non-zero might be a 
> mistake. in fact thinking about it, I think i'd argue it should never
> be zero, at least as long as we're pretending to be uniprocessor.
> 
> 

The problem I see is:
The dec exceptions is often fired /before/ the dec register has become 
negative (if you enable the debug prints in readDEC you'll see). Maybe 
this is confusing the client. We should:

a) ceil instead of round the timeout value
b) Wait/Reset the timer if readDEC would return a positive value in readDEC

Sebastian

Sebastian Biallas <sb <at> biallas.net> writes:

> The problem I see is:
> The dec exceptions is often fired /before/ the dec register has become 
> negative (if you enable the debug prints in readDEC you'll see). Maybe 
> this is confusing the client. We should:

What's the granularity on the timer functions we're using? I suppose it 
can be determined.

> a) ceil instead of round the timeout value

ok.

> b) Wait/Reset the timer if readDEC would return a positive value in readDEC

That seems sort of poor; The real CPU wouldn't wait. 

If it's really an overrun, can't we just assume it wrapped and give them the 
difference between the 2 numbers assuming that it wrapped only once?

Or am I barking up the wrong tree? I will confess to being somewhat confused 
at what I'm looking at.

Derrick Brashear wrote:

> Sebastian Biallas <sb <at> biallas.net> writes:
> 
> 
>>The problem I see is:
>>The dec exceptions is often fired /before/ the dec register has become 
>>negative (if you enable the debug prints in readDEC you'll see). Maybe 
>>this is confusing the client. We should:
> 
> What's the granularity on the timer functions we're using? I suppose it 
> can be determined.

Depends on the host. I guess it's between 1 and 10 ms.

> 
>>a) ceil instead of round the timeout value
> 
> ok.
> 
>>b) Wait/Reset the timer if readDEC would return a positive value in readDEC
> 
> That seems sort of poor; The real CPU wouldn't wait. 

Yes, we should restart the timer and don't raise the dec exception.

> 
> If it's really an overrun, can't we just assume it wrapped and give them the 
> difference between the 2 numbers assuming that it wrapped only once?
> 
> Or am I barking up the wrong tree? I will confess to being somewhat confused 
> at what I'm looking at.

As far as I know it not the problem of overruns. I guess it's more a 
problem of the exception fired to early and then the client 
miscalculates the next dec value (like, say, a division by zero). I need 
more debug info on this since I can't reliably reproduce it.

BTW: Is this a problem with all client/host combinations, i.e. does this 
happens with Linux on Windows and Darwin on Linux etc.? Or is this only 
a problem of a certain combination?

Sebastian

Sebastian Biallas <sb <at> biallas.net> writes:

> > That seems sort of poor; The real CPU wouldn't wait. 
> 
> Yes, we should restart the timer and don't raise the dec exception.

But, restart it at what?

> As far as I know it not the problem of overruns. I guess it's more a 
> problem of the exception fired to early and then the client 
> miscalculates the next dec value (like, say, a division by zero). I need 
> more debug info on this since I can't reliably reproduce it.

I can. So I will keep doing it. Basically, I have an installed image of 10.3. 
If I keep trying to upgrade it to 10.3.4 using software upgrade, it fails
every time.

> BTW: Is this a problem with all client/host combinations, i.e. does this 
> happens with Linux on Windows and Darwin on Linux etc.? Or is this only 
> a problem of a certain combination?

MacOS on Linux is the only thing I've tried (other than MacOS on MacOS,
which doesn't quite work yet)

On Tuesday 27 July 2004 08:24 am, Derrick Brashear wrote:
> Sebastian Biallas <sb <at> biallas.net> writes:
> > The problem I see is:
> > The dec exceptions is often fired /before/ the dec register has become
> > negative (if you enable the debug prints in readDEC you'll see). Maybe
> > this is confusing the client. We should:
>
> What's the granularity on the timer functions we're using? I suppose it
> can be determined.

It depends on the O.S. it's running under and how it was compiled. A few cases 
don't really have good enough resolution for truly accurate timing, but it'll 
be close. Windows is a millisecond I think. Most linux machines should have 
either 1 nanosecond or 10 millisecond resolution.

> > b) Wait/Reset the timer if readDEC would return a positive value in
> > readDEC
>
> That seems sort of poor; The real CPU wouldn't wait.

Well, the real CPU wouldn't be using a timer - it'd be counting down, so it'd 
always have a negative when the exception fires. :)

If the timer fires early, it'd depend on how early it fires. I don't think 
that restarting the timer is a good idea - our clocks will start running at 
half speed most of the time, since many unix machines barely have the 
resolution to handle the original request. The better solution would probably 
be something on the order of in the callback handler for the timer firing, 
trigger the exception, and mark a flag. Then in the readDEC, if that flag is 
true, guarantee that the returned value is negative. Maybe even if that flag 
is true, set the value to -1.

>
> If it's really an overrun, can't we just assume it wrapped and give them
> the difference between the 2 numbers assuming that it wrapped only once?
>
> Or am I barking up the wrong tree? I will confess to being somewhat
> confused at what I'm looking at.

It might not be an overrun, and might be a miscalculation in the readDEC. The 
interesting thing about all this is that it seems to happen whenever we've 
made a system call (i.e. File I/O, network read/write). Both of which might 
be blocking signals during the duration of the call. Which then seems to 
trigger it. So maybe the signal was blocked long enough that some computation 
goes haywire, and the value is actually too negative or something...

I'll play around with a couple of things this evening and see if I can figure 
it out as well.

- Kimball

On Tue, 2004-07-27 at 11:43, Sebastian Biallas wrote:
> Derrick Brashear wrote:

> BTW: Is this a problem with all client/host combinations, i.e. does this 
> happens with Linux on Windows and Darwin on Linux etc.? Or is this only 
> a problem of a certain combination?

I can consistently reproduce it while trying to install Mac OSX 10.3.4
The problem occurs exactly at the same place everytime.

Linux kernel 2.6.7, but also hapened with kernel 2.4.26
AMD Athlon-XP 1500+, 512 MB RAM.
Latest cvs update of pearpc, no additional patches, using HEAD.
Configure flags are --enable-ui=sdl
This has occured with both --enable-release set and not set.
This has occured with --enable-cpu=jitc_x86 and
--enable-cpu=jitc_generic
Libc is 2.3.3

Pat

On Tuesday 27 July 2004 09:14 am, Kimball Thurston wrote:
> I'll play around with a couple of things this evening and see if I can
> figure it out as well.
>

The attached patch seems to help, or I was lucky and it took longer for the 
problem to start appearing. I unfortunately need to leave for work, so I 
can't continue, but if people could play with this and see if it helps, 
that'd be cool (it would need to be cleaned up to be an official patch, but 
this was just a quick hack to test). Otherwise tonight I'll look through the 
xnu code and see how they handle the dec exception and see if I can work back 
what value they're writing.

- Kimball

On Tue, 2004-07-27 at 13:02, Kimball Thurston wrote:

> The attached patch seems to help, or I was lucky and it took longer for the 
> problem to start appearing. I unfortunately need to leave for work, so I 
> can't continue, but if people could play with this and see if it helps, 
> that'd be cool.

Testing, give me 2 hours.

Pat

Kimball Thurston <kdt3rd <at> adelphia.net> writes:

> The attached patch seems to help, or I was lucky and it took longer for the 

[]

> can't continue, but if people could play with this and see if it helps, 

Ok. Trying it now, will let you know what I find.

Kimball Thurston <kdt3rd <at> adelphia.net> writes:

> The attached patch seems to help, or I was lucky and it took longer for the 
> problem to start appearing. I unfortunately need to leave for work, so I 
> can't continue, but if people could play with this and see if it helps, 
> that'd be cool 

Still loses. Here's the interesting thing, the first message is:
[CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)

I'm going to reinstrument readDEC, I still think I saw a botched value returned
there just before the first of these errors yesterday.

Derrick Brashear <shadow <at> dementia.org> writes:

> Still loses. Here's the interesting thing, the first message is:
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)

Nope. I lied. Waiting sufficiently long, it recovered. I'm going to run 
the next phase of the test.

> I'm going to reinstrument readDEC, I still think I saw a botched value returned
> there just before the first of these errors yesterday.

I'll do this on the next pass.

On Tue, 2004-07-27 at 14:18, Derrick Brashear wrote:
> Kimball Thurston <kdt3rd <at> adelphia.net> writes:
> 
> > The attached patch seems to help, or I was lucky and it took longer for the 
> > problem to start appearing. I unfortunately need to leave for work, so I 
> > can't continue, but if people could play with this and see if it helps, 
> > that'd be cool 
> 
> Still loses. Here's the interesting thing, the first message is:
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)

Here are my first 4; my installer has not completed yet.

[CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
[CPU/OPC] <Warning> write dec > 20 millisec := 289890 (28989000)
[CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
[CPU/OPC] <Warning> write dec > 20 millisec := 289890 (28989000)

Pat

Patrick Naubert <patrickn <at> tygerteam.com> writes:

> Here are my first 4; my installer has not completed yet.
> 
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> [CPU/OPC] <Warning> write dec > 20 millisec := 289890 (28989000)
> [CPU/OPC] <Warning> write dec > 20 millisec := 2147483647 (4294967196)
> [CPU/OPC] <Warning> write dec > 20 millisec := 289890 (28989000)


I've let it run longer. I noticed that it's lost several times since. 
Now I'm seeing 2147483647 over and over, and eventually it will
start dropping. It does recover. It just takes a while. 

I'm now seeing a long countdown, where:
[CPU/OPC] <Warning> write dec > 20 millisec := 1505002427 (176387340)
[CPU/OPC] <Warning> write dec > 20 millisec := 1504602351 (136379740)
[CPU/OPC] <Warning> write dec > 20 millisec := 1504202453 (96389940)
[CPU/OPC] <Warning> write dec > 20 millisec := 1503802412 (56385840)
[CPU/OPC] <Warning> write dec > 20 millisec := 1503402450 (16389640)
[CPU/OPC] <Warning> write dec > 20 millisec := 1503002468 (4271358736)

q decreases over time, then jumps back up to huge; gCPU.dec is slowly
decaying.

Sebastian Biallas <sb <at> biallas.net> writes:

> As far as I know it not the problem of overruns. I guess it's more a 
> problem of the exception fired to early and then the client 
> miscalculates the next dec value (like, say, a division by zero). I need 
> more debug info on this since I can't reliably reproduce it.

Wait. dec register is only 32 bits, and all of those are in nanoseconds, 
so if gDECwriteITB is say 0x158726243 while ppc_get_cpu_ideal_timebase()
returns that plus 0x17809, you get a dec of 0xffff2037 when you read it.

Ok. Let me propose looking at readDEC as:
  gCPU.dec = gDECwriteValue + gDECwriteITB - ppc_get_cpu_ideal_timebase()

The first time things go high, in readDEC, I saw:
gDECwriteITB was 0xf0020d92.
gDECwriteITB - ppc_get_cpu_ideal_timebase() was 0x43f
gCPU.dec was set to 0x22e

And the next read showed gCPU.dec set to something which amounts to 
"rolled under": 0xfffff510

And my reading of the DEC register part of docs is "that's how it's 
supposed to work".

I did *not* see the
write dec > 20 millisec := %ld (%llu)
message trigger before this. 

So there's probably something going on with the rollunder. What, I'm
not sure. My next pass, I'm going to find some way to print 
something when timerCB triggers.

Kimball Thurston wrote:
> +	if (gExceptionFired) {
> +		if (0 == gCPU.dec & 0x80000000)

a) Please write such expression in human readable order (not backwards)
b) & has lower precedence than ==, so this is equivalent to

 > +		if ((0 == gCPU.dec) & 0x80000000)

Certainly not what you meant.

So either write as
 > +		if (!(gCPU.dec & 0x80000000))
or
 > +		if ((gCPU.dec & 0x80000000) == 0)


> +			gCPU.dec = static_cast<uint32>(-1);

understanding the c++ casts in on my todo list :)
Can you explain why do you use a static_cast instead of reinterpret_cast 
here?

Sebastian

On Tue, 27 Jul 2004 23:16:02 +0200, Sebastian Biallas <sb@...> wrote:
> Kimball Thurston wrote:
> > +     if (gExceptionFired) {
> > +             if (0 == gCPU.dec & 0x80000000)
> 
> a) Please write such expression in human readable order (not backwards)

I have to disagree with this, I prefer the style written here.  If I
get used to this and typo the == to be an =, then I get a compiler
error, instead of either a warning or a silent pass/run-time error.

> > +                     gCPU.dec = static_cast<uint32>(-1);
> 
> understanding the c++ casts in on my todo list :)
> Can you explain why do you use a static_cast instead of reinterpret_cast
> here?

reinterpret_cast only deals with pointers.  pointer->pointer,
pointer->integer type, or integer type->pointer.  This is converting
one size/type int to another type, no pointers involved, so
reinterpret_cast would give compiler errors here.  At least, that's my
understanding of it.

> 
> Sebastian

Kyle Lippincott wrote:

> On Tue, 27 Jul 2004 23:16:02 +0200, Sebastian Biallas <sb@...> wrote:
> 
>>Kimball Thurston wrote:
>>
>>>+     if (gExceptionFired) {
>>>+             if (0 == gCPU.dec & 0x80000000)
>>
>>a) Please write such expression in human readable order (not backwards)
> 
> I have to disagree with this, I prefer the style written here.  If I
> get used to this and typo the == to be an =, then I get a compiler
> error, instead of either a warning or a silent pass/run-time error.

Then you shouldn't program in C/C++ if you get confused by such things. 
I prefer clear code over such ugly syntax.

And how do you write things like
if (x == y)
?


> 
> 
>>>+                     gCPU.dec = static_cast<uint32>(-1);
>>
>>understanding the c++ casts in on my todo list :)
>>Can you explain why do you use a static_cast instead of reinterpret_cast
>>here?
> 
> reinterpret_cast only deals with pointers.  pointer->pointer,
> pointer->integer type, or integer type->pointer.  This is converting
> one size/type int to another type, no pointers involved, so
> reinterpret_cast would give compiler errors here.  At least, that's my
> understanding of it.

Ah, thanks. I still use the C-style cast where I don't have to think 
about such stuff.

> 
> 
>>Sebastian
> 
>

Kimball Thurston <kdt3rd <at> adelphia.net> writes:

> It might not be an overrun, and might be a miscalculation in the readDEC. The 
> interesting thing about all this is that it seems to happen whenever we've 

Well, here's what I just discovered. Whenever a dec exception is raised, I 
printed ppc_get_cpu_ideal_timebase(), gDECwriteITB and gCPU.dec.

I get the write dec errors right around when ppc_get_cpu_ideal_timebase()
rolls over. But realize, it didn't roll over at 2^64-1. I saw:
15871287d
and then I saw:
2007

So, there's something I'm missing. It's the math, but what?

Derrick Brashear wrote:

> Kimball Thurston <kdt3rd <at> adelphia.net> writes:
> 
> 
>>It might not be an overrun, and might be a miscalculation in the readDEC. The 
>>interesting thing about all this is that it seems to happen whenever we've 
> 
> 
> Well, here's what I just discovered. Whenever a dec exception is raised, I 
> printed ppc_get_cpu_ideal_timebase(), gDECwriteITB and gCPU.dec.
> 
> I get the write dec errors right around when ppc_get_cpu_ideal_timebase()
> rolls over. 

What does mean "it rolls over"?
It should never ever roll over (for small values of ever). It's a 64 bit 
value, so a 10 GHz timer would roll over after
2^64/(10*10^9/s) == 1'844'674'406 s == 30'744'573 min == 512'409 h == 
21'350 d == 58 y

So, unless you have a 1000 GHz computer it shouldn't roll over.

> But realize, it didn't roll over at 2^64-1. I saw:
> 15871287d
> and then I saw:
> 2007
> 
> So, there's something I'm missing. It's the math, but what?

Maybe there's something wrong in the calculation of the timebase.

Sebastian

Derrick Brashear wrote:

> Kimball Thurston <kdt3rd <at> adelphia.net> writes:
> 
> 
>>It might not be an overrun, and might be a miscalculation in the readDEC. The 
>>interesting thing about all this is that it seems to happen whenever we've 
> 
> 
> Well, here's what I just discovered. Whenever a dec exception is raised, I 
> printed ppc_get_cpu_ideal_timebase(), gDECwriteITB and gCPU.dec.
> 
> I get the write dec errors right around when ppc_get_cpu_ideal_timebase()
> rolls over. But realize, it didn't roll over at 2^64-1. I saw:
> 15871287d
> and then I saw:
> 2007
> 
> So, there's something I'm missing. It's the math, but what?
> 

Problem is this expression:
(ticks - gStartHostCLKTicks) * gClientTimeBaseFrequency / ticks_per_sec

For rounding purposes we multiply with gClientTimeBaseFrequency first, 
which might overflow if PearPC runs long enough. I guess the best 
solution is to make gClientTimeBaseFrequency not a constant so we don't 
have to scale here.

Another possibility is to use floating point math, but I guess this had 
huge impact on the jitc.

Sebastian

Sebastian Biallas <sb <at> biallas.net> writes:

> Problem is this expression:
> (ticks - gStartHostCLKTicks) * gClientTimeBaseFrequency / ticks_per_sec
> 
> For rounding purposes we multiply with gClientTimeBaseFrequency first, 
> which might overflow if PearPC runs long enough. I guess the best 
> solution is to make gClientTimeBaseFrequency not a constant so we don't 
> have to scale here.

So I had the right idea, but I was looking in the wrong place. I assumed we had 
truncation coming from 1e9 somewhere, and was trying to figure out where.

So the thing that can change is ticks_per_sec (if the host processor implements 
power saving) correct? So the problem is that you potentially lose resolution by 
doing the right side first, correct? Do you lose enough for it to matter?

> Another possibility is to use floating point math, but I guess this had 
> huge impact on the jitc.

I'm not qualified to comment here. I only even started thinking about a jitc ppc 
implementation and realized that I'd only have a chance if I could find some 
other implementation to look at.

Hey, is there an open source emulator of (some other platform) optimized for
powerpc?