🚀 go-pugleaf

In article <284@koel.rmit.oz> rcopm@koel.rmit.oz (Paul Menon) writes:
>g'dae,
>
>  This may appear as trivia to some, but I would dearly love to hear from
>anyone who *knows* the answers to any of the below.  I have made my 
>(un)educated guesses, and would like them confirmed.
>  
>(1)    What is the behaviour of the function "TickCount" 
>       (alias the Global "Ticks") when at the limit of its range?

See below.

>(2)    Am I correct in assuming that this limit is 2^31  - 1?

It depends.  If you assume that Ticks is signed (which it really isn't),
then yes, the limit is in fact 2^31-1.  If you treat it correctly as
unsigned, then the limit is 2^32-1.  The important thing to remember is that
it really doesn't matter which way you handle it (I don't know how you would
use the unsigned model in pascal), as long as you are consistent.  The system
always treats Ticks as unsigned, applications may do otherwise.

>(3)    Does it rollover to 0?

It depends.  Unsigned - yes.  2^32-1 + 1 becomes 0.  If you are looking
at it as signed, then 2^31-1 becomes -(2^31).  It still doesn't matter if
you are consistent.

>(4)    Does the System behave correctly when the rollover occurs?

Almost.  I tested it out myself on a Mac SE.  First of all realize that
there are two rollover points.  One for signed values (7FFFFFFF->80000000)
and one for unsigned values (FFFFFFFF->00000000).  The first rollover point
is not noticed by the ROM (it uses the unsigned interpretation).  The second
point has only one side-effect I noticed:  The caret (TEIdle) "skips" at the
rollover point and then continues normally.  But once every thirteen months
sin't too bad, huh?

							_emt