Rollover behavior in User Data

[DaveBarnett]

It would be useful to be able to use 2’s complement math in Script.

But, I noticed the following oddity:

Sys.Udata[0]++      // doesn’t rollover… it saturates instead

but,

Sys.Idata[0]++      // does rollover
and
Sys.CData[0]++        //does rollover

 To wrap my head around this… I created the following watch window:

 

I would have expected the unsigned data to be the one that rolls over.  'Curious.

Can we rely on this rollover behavior not to change in future firmware ??   I haven't tried it yet..but I wonder if this behaviour is the same when using C routines instead of script.

If you want to try out for yourself, I’ve attached the watch window XML file.

-Dave

 

 

 

 

UdataRollover.wtb

Edited February 8 by DaveBarnett

[leandro.martins]

Not much related, but it might be interesting to add for discussion.
Recently I have faced some differences on Sys.Cdata[i] structure between different firmware versions.
I can't say if the difference is due to firmware version, or is something more intrinsic to the cpu (since the PowerPC endianess diverge from the ARM).

While in fw 2.5.0.4 the Sys.Udata[0] points to the same region of Sys.Cdata[3], in fw 2.7.1.0 Sys.Udata[0] points to the same location of Sys.Cdata[0].

 

About the roll over, I have tested and both of the versions presented the same behaviour that Dave described.

 

 

[leandro.martins]

The description of "M{data}->{address definition}" in Power PMAC Software Reference Manual (May 19, 2023) states the following:

 

Quote

• s specifies a signed integer of up to 32 bits that saturates (not rolls over) when a command attempts to assign a value greater than its range to it
• i specifies a signed integer of up to 32 bits that rolls over (not saturates) when a command attempts to assign a value greater than its range to it
• u specifies an unsigned integer of up to 32 bits that rolls over (not saturates) when a command attempts to assign a value greater than its range to it

However, as I expected the u.user:(4*i) has the same behaviour of Sys.Udata[i], saturating instead of rolling  over.
Besides that the s.user rolls over instead of saturate.

Am I misinterpreting that statement, or is the statement incorrect?

Edited May 22 by leandro.martins