58 views

Skip to first unread message

Feb 18, 2020, 7:00:24 AM2/18/20

to

My head is hurting.

I need a BASIC routine to subtract one 5-byte time from another and return

a correctly signed result.

Complications arise at the point where the low word goes from &7fffffff to

&80000000, and where the high byte increases.

BASIC doesn't allow access to the carry or borrow from arithmetic

operations.

I've developed the following which *seems* to work correctly. However I'm

not sure about all the edge cases.

This is part of a timing system, Next February the high byte of times will

change from &57 to &58, and I would like this code to survive working

across this boundary. I need to reliably detect negative results, which

can occur if a spurious finish time pulse arrives before a start time.

Subtract stamp2 from stamp1 and store the result in resultbuf.

( Although the result is 5 bytes. the elapsed time will always be

contained in the low 4 bytes. This will only overflow after 1 year, 5

months and 2 hours 27 minutes. The system doesn't meed to run for that

long. )

PROCsubstamp(resultbuf%,stamp1%,stamp2%)

LOCAL I%,J%,K%,L%,borrow%

borrow%=0

FOR I%=0 TO3

J%=stamp1%?I%

K%=stamp2%?I%

L%=J%-K%-borrow%

resultbuf%?I%=L%AND&FF

IF L% < 0 THEN borrow%=1 ELSE borrow%=0

NEXT

I%=4

J%=stamp1%?I%

K%=stamp2%?I%

L%=J%-K%-borrow%

IF L% < 0 THEN

resultbuf%!0 = -(resultbuf%!0)

ENDIF

resultbuf%?I%=L%AND&FF

ENDPROC

--

Alan Adams, from Northamptonshire

al...@adamshome.org.uk

http://www.nckc.org.uk/

I need a BASIC routine to subtract one 5-byte time from another and return

a correctly signed result.

Complications arise at the point where the low word goes from &7fffffff to

&80000000, and where the high byte increases.

BASIC doesn't allow access to the carry or borrow from arithmetic

operations.

I've developed the following which *seems* to work correctly. However I'm

not sure about all the edge cases.

This is part of a timing system, Next February the high byte of times will

change from &57 to &58, and I would like this code to survive working

across this boundary. I need to reliably detect negative results, which

can occur if a spurious finish time pulse arrives before a start time.

Subtract stamp2 from stamp1 and store the result in resultbuf.

( Although the result is 5 bytes. the elapsed time will always be

contained in the low 4 bytes. This will only overflow after 1 year, 5

months and 2 hours 27 minutes. The system doesn't meed to run for that

long. )

PROCsubstamp(resultbuf%,stamp1%,stamp2%)

LOCAL I%,J%,K%,L%,borrow%

borrow%=0

FOR I%=0 TO3

J%=stamp1%?I%

K%=stamp2%?I%

L%=J%-K%-borrow%

resultbuf%?I%=L%AND&FF

IF L% < 0 THEN borrow%=1 ELSE borrow%=0

NEXT

I%=4

J%=stamp1%?I%

K%=stamp2%?I%

L%=J%-K%-borrow%

IF L% < 0 THEN

resultbuf%!0 = -(resultbuf%!0)

ENDIF

resultbuf%?I%=L%AND&FF

ENDPROC

--

Alan Adams, from Northamptonshire

al...@adamshome.org.uk

http://www.nckc.org.uk/

Feb 18, 2020, 1:11:31 PM2/18/20

to

In message <37f8364458...@ArmX6.adamshome.org.uk>

from Steve Drain (ROOL Forum 18/12/2016)

I wrote a library to support some of this this, as have others. It is a

candidate for Basalt, someday. ;-)

Look at http://kappa.me.uk/Libraries/lbLongs032.zip

Jean-Michel

--

Jean-Michel

I wrote a library to support some of this this, as have others. It is a

candidate for Basalt, someday. ;-)

Look at http://kappa.me.uk/Libraries/lbLongs032.zip

Jean-Michel

--

Jean-Michel

Feb 19, 2020, 3:35:14 AM2/19/20

to

In message <37f8364458...@ArmX6.adamshome.org.uk>

understanding is that you want a signed result, so that if stamp1% is

three centiseconds bigger than stamp2% you want a positive number (listing

the bytes in memory order):

03 00 00 00 00

and if stamp1% is three centiseconds less than stamp2% you want a negative

result:

FD FF FF FF FF

I also take it that you want a five-byte result, but that in your use case

four bytes would always contain the differences.

> This is part of a timing system, Next February the high byte of times will

> change from &57 to &58, and I would like this code to survive working

> across this boundary. I need to reliably detect negative results, which

> can occur if a spurious finish time pulse arrives before a start time.

>

> Subtract stamp2 from stamp1 and store the result in resultbuf.

> ( Although the result is 5 bytes. the elapsed time will always be

> contained in the low 4 bytes. This will only overflow after 1 year, 5

> months and 2 hours 27 minutes. The system doesn't meed to run for that

> long. )

>

> PROCsubstamp(resultbuf%,stamp1%,stamp2%)

> LOCAL I%,J%,K%,L%,borrow%

> borrow%=0

> FOR I%=0 TO3

> J%=stamp1%?I%

> K%=stamp2%?I%

> L%=J%-K%-borrow%

> resultbuf%?I%=L%AND&FF

> IF L% < 0 THEN borrow%=1 ELSE borrow%=0

> NEXT

> I%=4

> J%=stamp1%?I%

> K%=stamp2%?I%

> L%=J%-K%-borrow%

If you want a signed result, you need to remove the following three lines:

> IF L% < 0 THEN

> resultbuf%!0 = -(resultbuf%!0)

> ENDIF

If you want the absolute difference, so that in the above examples of stamp1%

and stamp2% differing by 3 centiseconds you would always get 03 00 00 00 00

no matter which of the two was the larger value, you should retain the three

lines above but change the following line to resultbuf%?I%=0

But that's only if you're sure the result fits in 4 bytes.

> resultbuf%?I%=L%AND&FF

> ENDPROC

If you wnat a signed result, you can simplify by making the FOR-NEXT loop

with I% run from 0 to 4 and lose all the lines after the NEXT.

--

Matthew Phillips

Durham

on 18 Feb 2020 Alan Adams wrote:

> My head is hurting.

>

> I need a BASIC routine to subtract one 5-byte time from another and return

> a correctly signed result.

>

> Complications arise at the point where the low word goes from &7fffffff to

> &80000000, and where the high byte increases.

>

> BASIC doesn't allow access to the carry or borrow from arithmetic

> operations.

>

> I've developed the following which *seems* to work correctly. However I'm

> not sure about all the edge cases.

I don't think it's doing quite what you want it to do. From the above, my
> My head is hurting.

>

> I need a BASIC routine to subtract one 5-byte time from another and return

> a correctly signed result.

>

> Complications arise at the point where the low word goes from &7fffffff to

> &80000000, and where the high byte increases.

>

> BASIC doesn't allow access to the carry or borrow from arithmetic

> operations.

>

> I've developed the following which *seems* to work correctly. However I'm

> not sure about all the edge cases.

understanding is that you want a signed result, so that if stamp1% is

three centiseconds bigger than stamp2% you want a positive number (listing

the bytes in memory order):

03 00 00 00 00

and if stamp1% is three centiseconds less than stamp2% you want a negative

result:

FD FF FF FF FF

I also take it that you want a five-byte result, but that in your use case

four bytes would always contain the differences.

> This is part of a timing system, Next February the high byte of times will

> change from &57 to &58, and I would like this code to survive working

> across this boundary. I need to reliably detect negative results, which

> can occur if a spurious finish time pulse arrives before a start time.

>

> Subtract stamp2 from stamp1 and store the result in resultbuf.

> ( Although the result is 5 bytes. the elapsed time will always be

> contained in the low 4 bytes. This will only overflow after 1 year, 5

> months and 2 hours 27 minutes. The system doesn't meed to run for that

> long. )

>

> PROCsubstamp(resultbuf%,stamp1%,stamp2%)

> LOCAL I%,J%,K%,L%,borrow%

> borrow%=0

> FOR I%=0 TO3

> J%=stamp1%?I%

> K%=stamp2%?I%

> L%=J%-K%-borrow%

> resultbuf%?I%=L%AND&FF

> IF L% < 0 THEN borrow%=1 ELSE borrow%=0

> NEXT

> I%=4

> J%=stamp1%?I%

> K%=stamp2%?I%

> L%=J%-K%-borrow%

> IF L% < 0 THEN

> resultbuf%!0 = -(resultbuf%!0)

> ENDIF

and stamp2% differing by 3 centiseconds you would always get 03 00 00 00 00

no matter which of the two was the larger value, you should retain the three

lines above but change the following line to resultbuf%?I%=0

But that's only if you're sure the result fits in 4 bytes.

> resultbuf%?I%=L%AND&FF

> ENDPROC

If you wnat a signed result, you can simplify by making the FOR-NEXT loop

with I% run from 0 to 4 and lose all the lines after the NEXT.

--

Matthew Phillips

Durham

Feb 19, 2020, 5:03:15 AM2/19/20

to

In message <757ca8445...@sinenomine.freeserve.co.uk>

interval%=!resultbuf%. i need this value to be correctly signed.

>> This is part of a timing system, Next February the high byte of times will

>> change from &57 to &58, and I would like this code to survive working

>> across this boundary. I need to reliably detect negative results, which

>> can occur if a spurious finish time pulse arrives before a start time.

>>

<snip>

> If you want a signed result, you need to remove the following three lines:

>> IF L% < 0 THEN

>> resultbuf%!0 = -(resultbuf%!0)

>> ENDIF

That bit is intended to ensure that the 40-byte part is correctly signed.

> If you want the absolute difference, so that in the above examples of stamp1%

> and stamp2% differing by 3 centiseconds you would always get 03 00 00 00 00

> no matter which of the two was the larger value, you should retain the three

> lines above but change the following line to resultbuf%?I%=0

> But that's only if you're sure the result fits in 4 bytes.

If anyone takes a year and a half to paddle round a slalom course, we can

time them with a calendar.

>> resultbuf%?I%=L%AND&FF

>> ENDPROC

> If you wnat a signed result, you can simplify by making the FOR-NEXT loop

> with I% run from 0 to 4 and lose all the lines after the NEXT.

The following shows why this makes my head hurt.

adding two positive numbers shouldn't produce a negative result.

>A%=&7FFFFFFF

>PRINT A%

2.14748365E9

>B%=A%+1

>PRINT B%

-2.14748365E9

Matthew Phillips <spam...@yahoo.co.uk> wrote:

> In message <37f8364458...@ArmX6.adamshome.org.uk>

> on 18 Feb 2020 Alan Adams wrote:

>> My head is hurting.

>>

>> I need a BASIC routine to subtract one 5-byte time from another and return

>> a correctly signed result.

>>

>> Complications arise at the point where the low word goes from &7fffffff to

>> &80000000, and where the high byte increases.

>>

>> BASIC doesn't allow access to the carry or borrow from arithmetic

>> operations.

>>

>> I've developed the following which *seems* to work correctly. However I'm

>> not sure about all the edge cases.

> I don't think it's doing quite what you want it to do. From the above, my

> understanding is that you want a signed result, so that if stamp1% is

> three centiseconds bigger than stamp2% you want a positive number (listing

> the bytes in memory order):

> 03 00 00 00 00

> and if stamp1% is three centiseconds less than stamp2% you want a negative

> result:

> FD FF FF FF FF

> I also take it that you want a five-byte result, but that in your use case

> four bytes would always contain the differences.

I do want a 4-byte result - the final stage after calling this is
> In message <37f8364458...@ArmX6.adamshome.org.uk>

> on 18 Feb 2020 Alan Adams wrote:

>> My head is hurting.

>>

>> I need a BASIC routine to subtract one 5-byte time from another and return

>> a correctly signed result.

>>

>> Complications arise at the point where the low word goes from &7fffffff to

>> &80000000, and where the high byte increases.

>>

>> BASIC doesn't allow access to the carry or borrow from arithmetic

>> operations.

>>

>> I've developed the following which *seems* to work correctly. However I'm

>> not sure about all the edge cases.

> I don't think it's doing quite what you want it to do. From the above, my

> understanding is that you want a signed result, so that if stamp1% is

> three centiseconds bigger than stamp2% you want a positive number (listing

> the bytes in memory order):

> 03 00 00 00 00

> and if stamp1% is three centiseconds less than stamp2% you want a negative

> result:

> FD FF FF FF FF

> I also take it that you want a five-byte result, but that in your use case

> four bytes would always contain the differences.

interval%=!resultbuf%. i need this value to be correctly signed.

>> This is part of a timing system, Next February the high byte of times will

>> change from &57 to &58, and I would like this code to survive working

>> across this boundary. I need to reliably detect negative results, which

>> can occur if a spurious finish time pulse arrives before a start time.

>>

> If you want a signed result, you need to remove the following three lines:

>> IF L% < 0 THEN

>> resultbuf%!0 = -(resultbuf%!0)

>> ENDIF

> If you want the absolute difference, so that in the above examples of stamp1%

> and stamp2% differing by 3 centiseconds you would always get 03 00 00 00 00

> no matter which of the two was the larger value, you should retain the three

> lines above but change the following line to resultbuf%?I%=0

> But that's only if you're sure the result fits in 4 bytes.

time them with a calendar.

>> resultbuf%?I%=L%AND&FF

>> ENDPROC

> If you wnat a signed result, you can simplify by making the FOR-NEXT loop

> with I% run from 0 to 4 and lose all the lines after the NEXT.

adding two positive numbers shouldn't produce a negative result.

>A%=&7FFFFFFF

>PRINT A%

2.14748365E9

>B%=A%+1

>PRINT B%

-2.14748365E9

Feb 19, 2020, 8:04:18 AM2/19/20

to

Am Wed, 19 Feb 2020 10:03:26 +0000 schrieb Alan Adams:

> In message <757ca8445...@sinenomine.freeserve.co.uk>

> Matthew Phillips <spam...@yahoo.co.uk> wrote:

>

>> In message <37f8364458...@ArmX6.adamshome.org.uk>

>> on 18 Feb 2020 Alan Adams wrote:

>

>>> My head is hurting.

>>>

>>> I need a BASIC routine to subtract one 5-byte time from another and

>>> return a correctly signed result.

>>>

>>> Complications arise at the point where the low word goes from

>>> &7fffffff to &80000000, and where the high byte increases.

>>>

>>> BASIC doesn't allow access to the carry or borrow from arithmetic

>>> operations.

> In message <757ca8445...@sinenomine.freeserve.co.uk>

> Matthew Phillips <spam...@yahoo.co.uk> wrote:

>

>> In message <37f8364458...@ArmX6.adamshome.org.uk>

>> on 18 Feb 2020 Alan Adams wrote:

>

>>> My head is hurting.

>>>

>>> I need a BASIC routine to subtract one 5-byte time from another and

>>> return a correctly signed result.

>>>

>>> Complications arise at the point where the low word goes from

>>> &7fffffff to &80000000, and where the high byte increases.

>>>

>>> BASIC doesn't allow access to the carry or borrow from arithmetic

>>> operations.

>> But that's only if you're sure the result fits in 4 bytes.

>

> If anyone takes a year and a half to paddle round a slalom course, we

> can time them with a calendar.

>

>>> resultbuf%?I%=L%AND&FF

>>> ENDPROC

>

>> If you wnat a signed result, you can simplify by making the FOR-NEXT

>> loop with I% run from 0 to 4 and lose all the lines after the NEXT.

>

> The following shows why this makes my head hurt.

>

> adding two positive numbers shouldn't produce a negative result.

>

>>A%=&7FFFFFFF PRINT A%

> 2.14748365E9

>>B%=A%+1 PRINT B%

> -2.14748365E9

But: that's no problem at all since You are NOT doing some kind of
>

> If anyone takes a year and a half to paddle round a slalom course, we

> can time them with a calendar.

>

>>> resultbuf%?I%=L%AND&FF

>>> ENDPROC

>

>> If you wnat a signed result, you can simplify by making the FOR-NEXT

>> loop with I% run from 0 to 4 and lose all the lines after the NEXT.

>

> The following shows why this makes my head hurt.

>

> adding two positive numbers shouldn't produce a negative result.

>

>>A%=&7FFFFFFF PRINT A%

> 2.14748365E9

>>B%=A%+1 PRINT B%

> -2.14748365E9

integer mathematics here. You are trying to change the bytes as they are

stored in memory.

The example with B%=A%+1 results in a "higher" value in memory - but the

BASIC interprets it as a signed value, and therefore it changes to

negative value if the top-most bit has been set.

This only means that You can't print this values directly via PRINT -

there is always the need to use an output-procedure if a "time" value is

intended.

If You really know that the times measured never (!) execeed the 4 Bytes

then I dont know why anyone should deal with the highest (the 5th) Byte.

If these time stamp%s are taken as start and stop times then they are

ordered since You already know wich is the higher/later one.

One thing - and thats the first I wanted to mention - more:

If this is on a 32 Bit Machine (as an Archimedes or RPC or Pi) then there

are only 4 Bytes per integer variable% !

If You use a construct such as stamp1%?I% with I%=4 there will be a result

- but probably not the one, wich gives the correct value for the 5th

Byte. I think this should give You the least significant Byte of the next

32Bit variable wich is stored in memory directly after (behind) the

stamp1% . This means: stamp1%?4 doesn't give the 5th Byte of stamp1% as

intendend, but will result in Byte 1 of stamp2% ( hence the same as

stamp2%?0 ).

All the best,

SBn

Feb 19, 2020, 11:42:15 AM2/19/20

to

In message <r2jboh$ap3$1...@solani.org>

The inconsistency is that BASIC shows a number as signed, but treats it in

addition as unsigned. To be consistent it should signal an overflow in the

example above.

> If You really know that the times measured never (!) execeed the 4 Bytes

> then I dont know why anyone should deal with the highest (the 5th) Byte.

> If these time stamp%s are taken as start and stop times then they are

> ordered since You already know wich is the higher/later one.

I don't know which, that's where the problem lies.

Suppose the finisher knocks his button. Then the starter starts someone.

We now have a finish timestamp which is before a start timestamp. To

detect this I need to get the difference returned as a negative number.

The 5th byte becomes important in Februiary 2021. Currently it has the

value &57. Next Feb it moves to &58. I need to ensure that a start with

byte5 as 57 and a finish with a byte5 of 58 doesn't result in a negative

number, nor a ridiculously large one. While it would potentially only

affect a small number of runs, it could also result in a crash somewhere

in the system when presented with invalid data.

> One thing - and thats the first I wanted to mention - more:

> If this is on a 32 Bit Machine (as an Archimedes or RPC or Pi) then there

> are only 4 Bytes per integer variable% !

> If You use a construct such as stamp1%?I% with I%=4 there will be a result

> - but probably not the one, wich gives the correct value for the 5th

> Byte. I think this should give You the least significant Byte of the next

> 32Bit variable wich is stored in memory directly after (behind) the

> stamp1% . This means: stamp1%?4 doesn't give the 5th Byte of stamp1% as

> intendend, but will result in Byte 1 of stamp2% ( hence the same as

> stamp2%?0 ).

I'm not using the 5th byte as part of the answer. I'm using the

calculation of the 5th byte to determine whether to negate the result that

I do use, i.e. bytes 1 to 4. There's no reason in fact to store it after

calculating it - that's left over from some testing situations.

> All the best,

> SBn

addition as unsigned. To be consistent it should signal an overflow in the

example above.

> If You really know that the times measured never (!) execeed the 4 Bytes

> then I dont know why anyone should deal with the highest (the 5th) Byte.

> If these time stamp%s are taken as start and stop times then they are

> ordered since You already know wich is the higher/later one.

Suppose the finisher knocks his button. Then the starter starts someone.

We now have a finish timestamp which is before a start timestamp. To

detect this I need to get the difference returned as a negative number.

The 5th byte becomes important in Februiary 2021. Currently it has the

value &57. Next Feb it moves to &58. I need to ensure that a start with

byte5 as 57 and a finish with a byte5 of 58 doesn't result in a negative

number, nor a ridiculously large one. While it would potentially only

affect a small number of runs, it could also result in a crash somewhere

in the system when presented with invalid data.

> One thing - and thats the first I wanted to mention - more:

> If this is on a 32 Bit Machine (as an Archimedes or RPC or Pi) then there

> are only 4 Bytes per integer variable% !

> If You use a construct such as stamp1%?I% with I%=4 there will be a result

> - but probably not the one, wich gives the correct value for the 5th

> Byte. I think this should give You the least significant Byte of the next

> 32Bit variable wich is stored in memory directly after (behind) the

> stamp1% . This means: stamp1%?4 doesn't give the 5th Byte of stamp1% as

> intendend, but will result in Byte 1 of stamp2% ( hence the same as

> stamp2%?0 ).

calculation of the 5th byte to determine whether to negate the result that

I do use, i.e. bytes 1 to 4. There's no reason in fact to store it after

calculating it - that's left over from some testing situations.

> All the best,

> SBn

Feb 19, 2020, 3:01:04 PM2/19/20

to

When I've done this I've manipulated the 5-byte number as

two 3-byte numbers, something like:

REM time1%=>first 5-byte time

REM time2%=>second 5-byte time

REM sum% =>7 bytes to hold 5-byte result

REM temp1A%=>7 bytes to hold intermediate result

REM temp1B%=>7 bytes to hold intermediate result

REM temp2A%=>7 bytes to hold intermediate result

REM temp2B%=>7 bytes to hold intermediate result

:

temp1A%!0=time1%!0:temp1A%?3=0

temp1B%!0=time1%!3:temp1B%!5=0

:

temp2A%!0=time2%!0:temp2A%?3=0

temp2B%!0=time2%!3:temp2B%!5=0

:

sum%!0=temp1A%!0+temp2A%!0

sum%!3=temp1B%!0+temp2B%!0+sum%?3

:

(similar for subtraction)

The memory use and operations can be optimised, and reading the

thread I'd probably go with something like:

REM time1%=>first 5-byte time

REM time2%=>second 5-byte time

REM sum% =>8 bytes to hold 5-byte result

sum%!0=0:sum%!4=0

FOR A%=0 TO 4

sum%!A%=time1%?A%+time2%?A%+sum%?A%

NEXT A%

(similar for subtraction)

(I've been staring at that for a while, it looks

too simple to be correct!)

jgh

two 3-byte numbers, something like:

REM time1%=>first 5-byte time

REM time2%=>second 5-byte time

REM sum% =>7 bytes to hold 5-byte result

REM temp1A%=>7 bytes to hold intermediate result

REM temp1B%=>7 bytes to hold intermediate result

REM temp2A%=>7 bytes to hold intermediate result

REM temp2B%=>7 bytes to hold intermediate result

:

temp1A%!0=time1%!0:temp1A%?3=0

temp1B%!0=time1%!3:temp1B%!5=0

:

temp2A%!0=time2%!0:temp2A%?3=0

temp2B%!0=time2%!3:temp2B%!5=0

:

sum%!0=temp1A%!0+temp2A%!0

sum%!3=temp1B%!0+temp2B%!0+sum%?3

:

(similar for subtraction)

The memory use and operations can be optimised, and reading the

thread I'd probably go with something like:

REM time1%=>first 5-byte time

REM time2%=>second 5-byte time

REM sum% =>8 bytes to hold 5-byte result

sum%!0=0:sum%!4=0

FOR A%=0 TO 4

sum%!A%=time1%?A%+time2%?A%+sum%?A%

NEXT A%

(similar for subtraction)

(I've been staring at that for a while, it looks

too simple to be correct!)

jgh

Feb 19, 2020, 6:54:29 PM2/19/20

to

On 18 Feb in article <37f8364458...@ArmX6.adamshome.org.uk>,

--

Martin Avison

Note that unfortunately this email address will become invalid

without notice if (when) any spam is received.

Alan Adams <al...@adamshome.org.uk> wrote:

> I need a BASIC routine to subtract one 5-byte time from another and

> return a correctly signed result.

Can it be assumed that both 5-byte times are work aligned?
> I need a BASIC routine to subtract one 5-byte time from another and

> return a correctly signed result.

--

Martin Avison

Note that unfortunately this email address will become invalid

without notice if (when) any spam is received.

Feb 20, 2020, 6:20:28 AM2/20/20

to

In message <5844fc97...@avisoft.f9.co.uk>

Martin <New...@avisoft.f9.co.uk> wrote:

> On 18 Feb in article <37f8364458...@ArmX6.adamshome.org.uk>,

> Alan Adams <al...@adamshome.org.uk> wrote:

>> I need a BASIC routine to subtract one 5-byte time from another and

>> return a correctly signed result.

> Can it be assumed that both 5-byte times are work aligned?

As the buffers are created with DIM, I believe they are aligned.
> On 18 Feb in article <37f8364458...@ArmX6.adamshome.org.uk>,

> Alan Adams <al...@adamshome.org.uk> wrote:

>> I need a BASIC routine to subtract one 5-byte time from another and

>> return a correctly signed result.

> Can it be assumed that both 5-byte times are work aligned?

Feb 21, 2020, 6:28:39 AM2/21/20

to

Michel wrote:

For interest's sake I put together a couple of routines to deal solely with 5-byte times using assembly at:

http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

I am not sure that I have got it right, so please pull it apart. ;-)

> Alan Adams wrote:

> > I need a BASIC routine to subtract one 5-byte time from another and return

> > a correctly signed result.

> > I need a BASIC routine to subtract one 5-byte time from another and return

> > a correctly signed result.

> from Steve Drain (ROOL Forum 18/12/2016)

>

> I wrote a library to support some of this this, as have others. It is a

> candidate for Basalt, someday. ;-)

>

> Look at http://kappa.me.uk/Libraries/lbLongs032.zip

I suspect that this problem has been satisfactorily solved in plain BASIC, but that library I wrote a good while ago uses fragments of assembly to do the heavy lifting, because of the carry etc.
>

> I wrote a library to support some of this this, as have others. It is a

> candidate for Basalt, someday. ;-)

>

> Look at http://kappa.me.uk/Libraries/lbLongs032.zip

For interest's sake I put together a couple of routines to deal solely with 5-byte times using assembly at:

http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

I am not sure that I have got it right, so please pull it apart. ;-)

Feb 21, 2020, 7:49:44 AM2/21/20

to

In message <80ec8ad6-58f7-4862...@googlegroups.com>

borrow/carry can be detected.

> For interest's sake I put together a couple of routines to deal solely

> with 5-byte times using assembly at:

> http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

> I am not sure that I have got it right, so please pull it apart. ;-)

It looks good. I'll test it in a bit.

The boundary conditions seem to be when the low word goes from 7fffffff to

80000000, when it goes from ffffffff to 00000000, and in each case when

the arguments swap.

Then there are the cases where the high bytes differ.

There's no way to indicate with an integer return, the result when the

high bytes differ by more than 1. Those cases are when the times are more

than a year and a half apart, so in my case, won't occur.

Steve Drain <st...@kappa.me.uk> wrote:

> Michel wrote:

>> Alan Adams wrote:

>>> I need a BASIC routine to subtract one 5-byte time from another and return

>>> a correctly signed result.

>> from Steve Drain (ROOL Forum 18/12/2016)

>>

>> I wrote a library to support some of this this, as have others. It is a

>> candidate for Basalt, someday. ;-)

>>

>> Look at http://kappa.me.uk/Libraries/lbLongs032.zip

> I suspect that this problem has been satisfactorily solved in plain BASIC,

> but that library I wrote a good while ago uses fragments of assembly to do

> the heavy lifting, because of the carry etc.

In BASIC it has to be done byte-by-byte, or using half-words, so that the
> Michel wrote:

>> Alan Adams wrote:

>>> I need a BASIC routine to subtract one 5-byte time from another and return

>>> a correctly signed result.

>> from Steve Drain (ROOL Forum 18/12/2016)

>>

>> I wrote a library to support some of this this, as have others. It is a

>> candidate for Basalt, someday. ;-)

>>

>> Look at http://kappa.me.uk/Libraries/lbLongs032.zip

> I suspect that this problem has been satisfactorily solved in plain BASIC,

> but that library I wrote a good while ago uses fragments of assembly to do

> the heavy lifting, because of the carry etc.

borrow/carry can be detected.

> For interest's sake I put together a couple of routines to deal solely

> with 5-byte times using assembly at:

> http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

> I am not sure that I have got it right, so please pull it apart. ;-)

The boundary conditions seem to be when the low word goes from 7fffffff to

80000000, when it goes from ffffffff to 00000000, and in each case when

the arguments swap.

Then there are the cases where the high bytes differ.

There's no way to indicate with an integer return, the result when the

high bytes differ by more than 1. Those cases are when the times are more

than a year and a half apart, so in my case, won't occur.

Feb 21, 2020, 10:20:36 AM2/21/20

to

each case the sign is wrong for the returned integer. The values are too

small as well. These are the cases where the result is too large for an

integer to hold.

The 5-byte integer values looks correct, but cannot be returned to BASIC.

I compared it with my BASIC routine. The adjustment I made after the last

subtraction was wrong. Omitting it returned the correct answer.

A$ is the bytes (high to low) in a%, similarly for B$ and C$.

the dates are the conversion iof A% and B% to dates.

14:51:20.29 ** Clear **

A$="00 00 00 00 20 " B$="00 7F FF FF C0 " C$="FF 80 00 00 60 "

!C%=-2147483552

A$="00:00:00 01-Jan-1900" B$="13:13:55 06-Sep-1900" !C%=-2147483552

A$="00 7F FF FF C0 " B$="00 00 00 00 20 " C$="00 7F FF FF A0 "

!C%=2147483552

A$="13:13:55 06-Sep-1900" B$="00:00:00 01-Jan-1900" !C%=2147483552

A$="00 80 00 00 20 " B$="00 7F FF FF C0 " C$="00 00 00 00 60 " !C%=96

A$="13:13:56 06-Sep-1900" B$="13:13:55 06-Sep-1900" !C%=96

A$="00 7F FF FF C0 " B$="00 80 00 00 20 " C$="FF FF FF FF A0 " !C%=-96

A$="13:13:55 06-Sep-1900" B$="13:13:56 06-Sep-1900" !C%=-96

A$="00 FF FF FF 20 " B$="01 00 00 00 C0 " C$="FF FF FF FE 60 " !C%=-416

A$="02:27:50 13-May-1901" B$="02:27:54 13-May-1901" !C%=-416

A$="01 00 00 00 C0 " B$="00 FF FF FF 20 " C$="00 00 00 01 A0 " !C%=416

A$="02:27:54 13-May-1901" B$="02:27:50 13-May-1901" !C%=416

A$="01 FF FF FF 20 " B$="00 00 00 00 C0 " C$="01 FF FF FE 60 " !C%=-416

A$="04:55:43 22-Sep-1902" B$="00:00:01 01-Jan-1900" !C%=-416

A$="00 00 00 00 C0 " B$="01 FF FF FF 20 " C$="FE 00 00 01 A0 " !C%=416

A$="00:00:01 01-Jan-1900" B$="04:55:43 22-Sep-1902" !C%=416

A$="FF FF FF FF 20 " B$="00 00 00 00 C0 " C$="FF FF FF FE 60 " !C%=-416

A$="06:57:55 03-Jun-2248" B$="00:00:01 01-Jan-1900" !C%=-416

A$="00 00 00 00 C0 " B$="FF FF FF FF 20 " C$="00 00 00 01 A0 " !C%=416

A$="00:00:01 01-Jan-1900" B$="06:57:55 03-Jun-2248" !C%=416

Feb 22, 2020, 5:38:22 AM2/22/20

to

Alan Adams wrote:

If the BASIC version is fine, I think I will leave it there.

> Steve Drain wrote:

>> For interest's sake I put together a couple of routines to deal solely

>> with 5-byte times using assembly at:

>

>> http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

>

>> I am not sure that I have got it right, so please pull it apart. ;-)

>

> I ran 10 sets of test data. I think it gets it wrong for the last 4. In

> each case the sign is wrong for the returned integer. The values are too

> small as well. These are the cases where the result is too large for an

> integer to hold.

I can see that, and was right to be sceptical of my own code.
>> For interest's sake I put together a couple of routines to deal solely

>> with 5-byte times using assembly at:

>

>> http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

>

>> I am not sure that I have got it right, so please pull it apart. ;-)

>

> I ran 10 sets of test data. I think it gets it wrong for the last 4. In

> each case the sign is wrong for the returned integer. The values are too

> small as well. These are the cases where the result is too large for an

> integer to hold.

> The 5-byte integer values looks correct, but cannot be returned to BASIC.

Yes, the subtraction is fine, but does not produce the desired result.
If the BASIC version is fine, I think I will leave it there.

Feb 23, 2020, 3:46:18 PM2/23/20

to

In message <4e83b04458...@ArmX6.adamshome.org.uk>

When you say "correctly signed" do you mean that you always want the result

to be positive, so that it expresses the difference in time between stamp1%

and stamp2% regardless of which is the earlier?

Or do you mean that you want the answer to be negative if stamp1% is

earlier than stamp2% and positive if stamp2% is earlier?

I was assuming the latter from your other postings, because you say that you

need to detect the condition of the finisher knocking a button before the

starter starts someone.

If you want the result to be +/- as I had assumed, then you need to get rid

of the bit that says

IF L% < 0 THEN

resultbuf%!0 = -(resultbuf%!0)

ENDIF

That will not be helping. As I said...

> > If you want a signed result, you need to remove the following three

> > lines:

>

> >> IF L% < 0 THEN

> >> resultbuf%!0 = -(resultbuf%!0)

> >> ENDIF

>

> That bit is intended to ensure that the 40-byte part is correctly signed.

You get a correctly signed plus or minus result by just looping through the

five bytes doing the subtraction and borrowing. That is the beauty of

two's-complement representation of negative numbers: exactly the same

operation is done at the byte level no matter whether it is signed or

unsigned arithmentic. The only difference is in the detection of carrying or

overflow. You've already made it clear that the times you are dealing with a

relatively close to each other (within a day or two, say) so you will not get

any overflow from subtracting them and the top byte can be ignored

completely.

> The following shows why this makes my head hurt.

>

> adding two positive numbers shouldn't produce a negative result.

>

> >A%=&7FFFFFFF

> >PRINT A%

> 2.14748365E9

> >B%=A%+1

> >PRINT B%

> -2.14748365E9

Well, that's a quirk of BBC BASIC that we were discussing a few weeks ago.

BASIC stupidly, in my opinion, allows you to do arithmetic on signed values

without warning about overflows.

I suggest you use:

PROCsubstamp(resultbuf%,stamp1%,stamp2%)

LOCAL I%,J%,K%,L%,borrow%

borrow%=0

FOR I%=0 TO3

J%=stamp1%?I%

K%=stamp2%?I%

L%=J%-K%-borrow%

resultbuf%?I%=L%AND&FF

IF L% < 0 THEN borrow%=1 ELSE borrow%=0

NEXT

ENDPROC

And then your answer can be read from !resultbuf% as a 4-byte signed value.

This will only work if the two timestamps are within 497 days of each other.

You are probably worried what will happen when we have these two timestamps:

A: 57FFFFFFFF

B: 5800000000

B is one centisecond higher than A.

Take FF off 0 and we get 1, borrow one.

Take FF and a borrow off 0 and we get 0

Take FF and a borrow off 0 and we get 0

Take FF and a borrow off 0 and we get 0

Take 57 and a borrow off 58 and we also get 0, but you're only looping from 0

to 3 so we don't even calculate this bit.

Therefore you get the answer 00000001 which is what you want.

Similarly if you take B off A, you will get FFFFFFFF which is -1 and is

correct.

If you know your answer is always going to fit in 4 bytes, just ditch all the

code after the end of your FOR-NEXT loop.

--

Matthew Phillips

Durham

to be positive, so that it expresses the difference in time between stamp1%

and stamp2% regardless of which is the earlier?

Or do you mean that you want the answer to be negative if stamp1% is

earlier than stamp2% and positive if stamp2% is earlier?

I was assuming the latter from your other postings, because you say that you

need to detect the condition of the finisher knocking a button before the

starter starts someone.

If you want the result to be +/- as I had assumed, then you need to get rid

of the bit that says

IF L% < 0 THEN

resultbuf%!0 = -(resultbuf%!0)

ENDIF

> > If you want a signed result, you need to remove the following three

> > lines:

>

> >> IF L% < 0 THEN

> >> resultbuf%!0 = -(resultbuf%!0)

> >> ENDIF

>

> That bit is intended to ensure that the 40-byte part is correctly signed.

five bytes doing the subtraction and borrowing. That is the beauty of

two's-complement representation of negative numbers: exactly the same

operation is done at the byte level no matter whether it is signed or

unsigned arithmentic. The only difference is in the detection of carrying or

overflow. You've already made it clear that the times you are dealing with a

relatively close to each other (within a day or two, say) so you will not get

any overflow from subtracting them and the top byte can be ignored

completely.

> The following shows why this makes my head hurt.

>

> adding two positive numbers shouldn't produce a negative result.

>

> >A%=&7FFFFFFF

> >PRINT A%

> 2.14748365E9

> >B%=A%+1

> >PRINT B%

> -2.14748365E9

BASIC stupidly, in my opinion, allows you to do arithmetic on signed values

without warning about overflows.

I suggest you use:

PROCsubstamp(resultbuf%,stamp1%,stamp2%)

LOCAL I%,J%,K%,L%,borrow%

borrow%=0

FOR I%=0 TO3

J%=stamp1%?I%

K%=stamp2%?I%

L%=J%-K%-borrow%

resultbuf%?I%=L%AND&FF

IF L% < 0 THEN borrow%=1 ELSE borrow%=0

NEXT

And then your answer can be read from !resultbuf% as a 4-byte signed value.

This will only work if the two timestamps are within 497 days of each other.

You are probably worried what will happen when we have these two timestamps:

A: 57FFFFFFFF

B: 5800000000

B is one centisecond higher than A.

Take FF off 0 and we get 1, borrow one.

Take FF and a borrow off 0 and we get 0

Take FF and a borrow off 0 and we get 0

Take FF and a borrow off 0 and we get 0

Take 57 and a borrow off 58 and we also get 0, but you're only looping from 0

to 3 so we don't even calculate this bit.

Therefore you get the answer 00000001 which is what you want.

Similarly if you take B off A, you will get FFFFFFFF which is -1 and is

correct.

If you know your answer is always going to fit in 4 bytes, just ditch all the

code after the end of your FOR-NEXT loop.

--

Matthew Phillips

Durham

Feb 23, 2020, 8:39:52 PM2/23/20

to

Alan Adams wrote:

> The 5-byte integer values looks correct, but cannot be returned to BASIC.

While you can't use the 5-byte integers, you can store and retrieve
> The 5-byte integer values looks correct, but cannot be returned to BASIC.

them with | and hold them in reals, as long as you treat them as

opaque values and don't "look" at them. So you can do: |here%=|there%

and bar=FNfoo with DEFFNfoo ending with =|somewhere

I do this with my Phone library to hold UK telephone numbers in

5-byte objects.

jgh

Feb 24, 2020, 5:25:24 AM2/24/20

to

j...@mdfs.net wrote:

> Alan Adams wrote:

>> The 5-byte integer values looks correct, but cannot be returned to BASIC.

>

> While you can't use the 5-byte integers, you can store and retrieve

> them with | and hold them in reals, as long as you treat them as

> opaque values and don't "look" at them. So you can do: |here%=|there%

> and bar=FNfoo with DEFFNfoo ending with =|somewhere

In Basalt time values are held in float variables in just this way, but
> Alan Adams wrote:

>> The 5-byte integer values looks correct, but cannot be returned to BASIC.

>

> While you can't use the 5-byte integers, you can store and retrieve

> them with | and hold them in reals, as long as you treat them as

> opaque values and don't "look" at them. So you can do: |here%=|there%

> and bar=FNfoo with DEFFNfoo ending with =|somewhere

the manipulation is transparent when used with appropriate keywords.

And I, too, have a more-or-less equivalent library in just BASIC.

In neither is there a function to satisfy the OP. The nearest is a time

difference in seconds, which always fits into an signed integer.

Feb 24, 2020, 6:14:32 AM2/24/20

to

In message <r308ag$h4j$1...@gioia.aioe.org>

And thank you to all who have contributed. I now have several options to

use. My preference is Martin's, because although all the options return

the time difference in an integer for valid ranges, Martin's returns a

defined -1 to indicate negative or overflow, which helps with the calling

code.

use. My preference is Martin's, because although all the options return

the time difference in an integer for valid ranges, Martin's returns a

defined -1 to indicate negative or overflow, which helps with the calling

code.

Feb 24, 2020, 8:18:46 AM2/24/20

to

On 24 Feb in article <21f8494758...@ArmX6.adamshome.org.uk>,

send it direct to Alan because I was away with no csap access.

DEF FNsub(A%,B%) = USR tsub% :REM = B% - A% (=> 5 byte times)

REM Returns -1 (error) if result negative,

REM or over &7fffffff (~35 weeks)

.tsub%

; Entry r0 = A% => 5 byte start time (word aligned) lsb..msb

; r1 = B% => 5 byte stop time (word aligned) lsb..msb

; Exit r0 = B%-A% 4 byte time difference or -1 if start after stop

; r0 = r3 - r2 (low word)

; r4 = r6 - r5 (high byte)

LDR r2,[r0] ; get low 4 bytes start

LDR r3,[r1] ; get low 4 bytes stop

LDRB r5,[r0,#4] ; get high byte start

LDRB r6,[r1,#4] ; get high byte stop

SUBS r0,r3,r2 ; get low bytes difference

SBCS r4,r6,r5 ; get high bytes difference - set Z if zero

; r4 = 0 if positive, -1 if negative, else over ~70 weeks

Bne error ;

TST r0,#1<<31 ; r0 'negative' if over 35 weeks

MOVeq pc,r14 ; ok to return positive result

.error

; Return error indicator if negative or > ~35 weeks positive

MVN r0,#0 ; set return to -1 to indicate error

MOV pc,r14

It could be extended, and prbably improved!

Martin

Alan Adams <al...@adamshome.org.uk> wrote:

> My preference is Martin's, because although all the options return

> the time difference in an integer for valid ranges, Martin's

> returns a defined -1 to indicate negative or overflow, which helps

> with the calling code.

In in case anyone is interested, I have posted it below. I had to
> My preference is Martin's, because although all the options return

> the time difference in an integer for valid ranges, Martin's

> returns a defined -1 to indicate negative or overflow, which helps

> with the calling code.

send it direct to Alan because I was away with no csap access.

DEF FNsub(A%,B%) = USR tsub% :REM = B% - A% (=> 5 byte times)

REM Returns -1 (error) if result negative,

REM or over &7fffffff (~35 weeks)

.tsub%

; Entry r0 = A% => 5 byte start time (word aligned) lsb..msb

; r1 = B% => 5 byte stop time (word aligned) lsb..msb

; Exit r0 = B%-A% 4 byte time difference or -1 if start after stop

; r0 = r3 - r2 (low word)

; r4 = r6 - r5 (high byte)

LDR r2,[r0] ; get low 4 bytes start

LDR r3,[r1] ; get low 4 bytes stop

LDRB r5,[r0,#4] ; get high byte start

LDRB r6,[r1,#4] ; get high byte stop

SUBS r0,r3,r2 ; get low bytes difference

SBCS r4,r6,r5 ; get high bytes difference - set Z if zero

; r4 = 0 if positive, -1 if negative, else over ~70 weeks

Bne error ;

TST r0,#1<<31 ; r0 'negative' if over 35 weeks

MOVeq pc,r14 ; ok to return positive result

.error

; Return error indicator if negative or > ~35 weeks positive

MVN r0,#0 ; set return to -1 to indicate error

MOV pc,r14

It could be extended, and prbably improved!

Martin

Feb 25, 2020, 11:07:09 AM2/25/20

to

Steve Drain wrote:

> If the BASIC version is fine, I think I will leave it there.

Last words. Adapting a technique I used to implement 'magic numbers' for
> If the BASIC version is fine, I think I will leave it there.

assembler division by a constant I have come up with:

DEFFNdiff(a%,b%)

LOCAL a,b,c:c=2^32

IF !a%<0 THEN a=c-(NOT!a%+1) ELSE a=!a%

IF !b%<0 THEN b=c-(NOT!b%+1) ELSE b=!b%

=(a%!4-b%!4)*c+a-b

The returned value is a signed float and if assigned to an integer it

will give a 'Number to big' error if out of the range you want. I think

it is exact within that range.

I will be interested to know where the bugs are. ;-)

Feb 25, 2020, 11:38:46 AM2/25/20

to

In message <r33gnb$1q0r$1...@gioia.aioe.org>

I don't think I will try to understand it.

Alan

> The returned value is a signed float and if assigned to an integer it

> will give a 'Number to big' error if out of the range you want. I think

> it is exact within that range.

> I will be interested to know where the bugs are. ;-)

Steve Drain <st...@kappa.me.uk> wrote:

> Steve Drain wrote:

>> If the BASIC version is fine, I think I will leave it there.

> Last words. Adapting a technique I used to implement 'magic numbers' for

> assembler division by a constant I have come up with:

> DEFFNdiff(a%,b%)

> LOCAL a,b,c:c=2^32

> IF !a%<0 THEN a=c-(NOT!a%+1) ELSE a=!a%

> IF !b%<0 THEN b=c-(NOT!b%+1) ELSE b=!b%

> =(a%!4-b%!4)*c+a-b

That's so terse it makes my eyes water.
> Steve Drain wrote:

>> If the BASIC version is fine, I think I will leave it there.

> Last words. Adapting a technique I used to implement 'magic numbers' for

> assembler division by a constant I have come up with:

> DEFFNdiff(a%,b%)

> LOCAL a,b,c:c=2^32

> IF !a%<0 THEN a=c-(NOT!a%+1) ELSE a=!a%

> IF !b%<0 THEN b=c-(NOT!b%+1) ELSE b=!b%

> =(a%!4-b%!4)*c+a-b

I don't think I will try to understand it.

Alan

> The returned value is a signed float and if assigned to an integer it

> will give a 'Number to big' error if out of the range you want. I think

> it is exact within that range.

> I will be interested to know where the bugs are. ;-)

Feb 27, 2020, 12:11:41 PM2/27/20

to

Alan Adams wrote:

> That's so terse it makes my eyes water.

> I don't think I will try to understand it.

The original problem could be solved if BASIC would do arithmetic with
> That's so terse it makes my eyes water.

> I don't think I will try to understand it.

unsigned integers. A 5-byte float can hold an unsigned integer exactly,

but we have to get those integers into floats. I think the method I

posted earlier is actually over-thought and more elaborate than it needs

to be. Please let me know if this works for you:

DEFFNdiff(a%,b%)

LOCAL a,b,c:c=2^32

IF !a%<0 THEN a=c+!a% ELSE a=!a%

IF !b%<0 THEN b=c+!b% ELSE b=!b%

=(a%!4-b%!4)*c+a-b

This, some other ramblings, and an extension of the assembler routine

that Martin posted, which will return negative values, are at:

http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

I think the assembler routine is the most useful, but the BASIC one is

quite satisfying. ;-)

Feb 27, 2020, 1:06:41 PM2/27/20

to

Ooops!

=(a%?4-b%?4)*c+a-b

=(a%?4-b%?4)*c+a-b

Feb 28, 2020, 6:22:47 AM2/28/20

to

In message <r38t89$nvf$1...@gioia.aioe.org>

> DEFFNdiff(a%,b%)

> LOCAL a,b,c:c=2^32

> IF !a%<0 THEN a=c+!a% ELSE a=!a%

> IF !b%<0 THEN b=c+!b% ELSE b=!b%

> =(a%!4-b%!4)*c+a-b

> This, some other ramblings, and an extension of the assembler routine

> that Martin posted, which will return negative values, are at:

> http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

> I think the assembler routine is the most useful, but the BASIC one is

> quite satisfying. ;-)

Steve Drain <st...@kappa.me.uk> wrote:

> Alan Adams wrote:

>> That's so terse it makes my eyes water.

>> I don't think I will try to understand it.

> The original problem could be solved if BASIC would do arithmetic with

> unsigned integers. A 5-byte float can hold an unsigned integer exactly,

> but we have to get those integers into floats. I think the method I

> posted earlier is actually over-thought and more elaborate than it needs

> to be. Please let me know if this works for you:

With your followup correction, yes it works well.
> Alan Adams wrote:

>> That's so terse it makes my eyes water.

>> I don't think I will try to understand it.

> The original problem could be solved if BASIC would do arithmetic with

> unsigned integers. A 5-byte float can hold an unsigned integer exactly,

> but we have to get those integers into floats. I think the method I

> posted earlier is actually over-thought and more elaborate than it needs

> to be. Please let me know if this works for you:

> DEFFNdiff(a%,b%)

> LOCAL a,b,c:c=2^32

> IF !a%<0 THEN a=c+!a% ELSE a=!a%

> IF !b%<0 THEN b=c+!b% ELSE b=!b%

> =(a%!4-b%!4)*c+a-b

> This, some other ramblings, and an extension of the assembler routine

> that Martin posted, which will return negative values, are at:

> http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

> I think the assembler routine is the most useful, but the BASIC one is

> quite satisfying. ;-)

Apr 22, 2020, 3:00:26 PM4/22/20

to

Sorry that I'm late to the party here. In order to calculate the elapsed time you can just subtract the lower 4 bytes.

So if Start% is the lower four bytes of the start time & Finish% is the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result even with rollovers.

If TimeTaken% < 0 then the finish was before the start.

Jeff

So if Start% is the lower four bytes of the start time & Finish% is the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result even with rollovers.

If TimeTaken% < 0 then the finish was before the start.

Jeff

Apr 22, 2020, 7:09:59 PM4/22/20

to

On 22 Apr in article

<69d8792f-18c1-4a2c...@googlegroups.com>,

I don't think this works if the time difference is over 35 weeks....

<69d8792f-18c1-4a2c...@googlegroups.com>,

Apr 23, 2020, 6:13:57 AM4/23/20

to

Apr 23, 2020, 1:01:46 PM4/23/20

to

On 23 Apr in article

<dccbb754-a167-43b8...@googlegroups.com>,

start time = 58 00 00 04 00

end time = 57 00 00 05 00

gives x100 ... when it should be flagged as negative and duff!

<dccbb754-a167-43b8...@googlegroups.com>,

<jeffrey....@gmail.com> wrote:

> On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:

> > On 22 Apr in article

> > <69d8792f-18c1-4a2c...@googlegroups.com>,

> > <jeffrey....@gmail.com> wrote:

> > > Sorry that I'm late to the party here. In order to calculate the

> > > elapsed time you can just subtract the lower 4 bytes.

> >

> > > So if Start% is the lower four bytes of the start time &

> > > Finish% is the lower four bytes of the finish time:

> >

> > > TimeTaken% = Finish% - Start%

> >

> > > This "Just works" and will always produce the correct result

> > > even with rollovers.

> >

> > > If TimeTaken% < 0 then the finish was before the start.

> >

> > I don't think this works if the time difference is over 35

> > weeks....

> On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:

> > On 22 Apr in article

> > <69d8792f-18c1-4a2c...@googlegroups.com>,

> > <jeffrey....@gmail.com> wrote:

> > > Sorry that I'm late to the party here. In order to calculate the

> > > elapsed time you can just subtract the lower 4 bytes.

> >

> > > So if Start% is the lower four bytes of the start time &

> > > Finish% is the lower four bytes of the finish time:

> >

> > > TimeTaken% = Finish% - Start%

> >

> > > This "Just works" and will always produce the correct result

> > > even with rollovers.

> >

> > > If TimeTaken% < 0 then the finish was before the start.

> >

> > I don't think this works if the time difference is over 35

> > weeks....

> No, but Alan is timing a canoeist down a slalom course. If it

> takes 35 weeks then there's something amiss.

Indeed. But what happens when the 5-byte hex times are...
> takes 35 weeks then there's something amiss.

start time = 58 00 00 04 00

end time = 57 00 00 05 00

gives x100 ... when it should be flagged as negative and duff!

Apr 23, 2020, 1:10:09 PM4/23/20

to

In article <5865cc4b...@avisoft.f9.co.uk>,

definitive answer on this, please!

An agreed one that I can save as a note!

John

--

John WILLIAMS, now back in the UK - no attachments to these addresses!

Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!

Who is John WILLIAMS? http://petit.four.free.fr/picindex/author/

Martin <New...@avisoft.f9.co.uk> wrote:

> Indeed. But what happens when the 5-byte hex times are...

> start time = 58 00 00 04 00

> end time = 57 00 00 05 00

> gives x100 ... when it should be flagged as negative and duff!

I've already added a note in my programming library, but can we have a
> Indeed. But what happens when the 5-byte hex times are...

> start time = 58 00 00 04 00

> end time = 57 00 00 05 00

> gives x100 ... when it should be flagged as negative and duff!

definitive answer on this, please!

An agreed one that I can save as a note!

John

--

John WILLIAMS, now back in the UK - no attachments to these addresses!

Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!

Who is John WILLIAMS? http://petit.four.free.fr/picindex/author/

Apr 23, 2020, 2:18:45 PM4/23/20

to

> Indeed. But what happens when the 5-byte hex times are...

> start time = 58 00 00 04 00

> end time = 57 00 00 05 00

> gives x100 ... when it should be flagged as negative and duff!

That would require the judge on the finish line to press his button 35 weeks before the starter presses his button. Cannot happen.
> start time = 58 00 00 04 00

> end time = 57 00 00 05 00

> gives x100 ... when it should be flagged as negative and duff!

Apr 23, 2020, 3:58:00 PM4/23/20

to

In message <5865cc4b...@avisoft.f9.co.uk>

certain range of times, something like 35 weeks, which is orders of

magnitude greater than can happen in this use case.

It's not a general solution, but it is entirely correct and appropriate

for what the OP's needs.

David

Martin <New...@avisoft.f9.co.uk> wrote:

> On 23 Apr in article

> <dccbb754-a167-43b8...@googlegroups.com>,

> <jeffrey....@gmail.com> wrote:

> > On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:

> > > On 22 Apr in article

> > > <69d8792f-18c1-4a2c...@googlegroups.com>,

> > > <jeffrey....@gmail.com> wrote:

> > > > Sorry that I'm late to the party here. In order to calculate the

> > > > elapsed time you can just subtract the lower 4 bytes.

> > >

> > > > So if Start% is the lower four bytes of the start time & Finish% is

> > > > the lower four bytes of the finish time:

> > >

> > > > TimeTaken% = Finish% - Start%

> > >

> > > > This "Just works" and will always produce the correct result even

> > > > with rollovers.

> > >

> > > > If TimeTaken% < 0 then the finish was before the start.

> > >

> > > I don't think this works if the time difference is over 35 weeks....

>

> > No, but Alan is timing a canoeist down a slalom course. If it takes 35

> > weeks then there's something amiss.

>

> Indeed. But what happens when the 5-byte hex times are...

> start time = 58 00 00 04 00

> end time = 57 00 00 05 00 gives x100 ... when it should be flagged as

> negative and duff!

As has already been pointed out, the answers are all correct within a
> On 23 Apr in article

> <dccbb754-a167-43b8...@googlegroups.com>,

> <jeffrey....@gmail.com> wrote:

> > On Thursday, 23 April 2020 00:09:59 UTC+1, Martin wrote:

> > > On 22 Apr in article

> > > <69d8792f-18c1-4a2c...@googlegroups.com>,

> > > <jeffrey....@gmail.com> wrote:

> > > > Sorry that I'm late to the party here. In order to calculate the

> > > > elapsed time you can just subtract the lower 4 bytes.

> > >

> > > > So if Start% is the lower four bytes of the start time & Finish% is

> > > > the lower four bytes of the finish time:

> > >

> > > > TimeTaken% = Finish% - Start%

> > >

> > > > This "Just works" and will always produce the correct result even

> > > > with rollovers.

> > >

> > > > If TimeTaken% < 0 then the finish was before the start.

> > >

> > > I don't think this works if the time difference is over 35 weeks....

>

> > No, but Alan is timing a canoeist down a slalom course. If it takes 35

> > weeks then there's something amiss.

>

> Indeed. But what happens when the 5-byte hex times are...

> start time = 58 00 00 04 00

> end time = 57 00 00 05 00 gives x100 ... when it should be flagged as

> negative and duff!

certain range of times, something like 35 weeks, which is orders of

magnitude greater than can happen in this use case.

It's not a general solution, but it is entirely correct and appropriate

for what the OP's needs.

David

Apr 23, 2020, 4:32:17 PM4/23/20

to

On 23 Apr in article

<6667d647-6873-488d...@googlegroups.com>,
> I need to reliably detect negative results, which can occur if a

> spurious finish time pulse arrives before a start time.

Apr 24, 2020, 10:29:18 AM4/24/20

to

In message <5865ded0...@avisoft.f9.co.uk>

(roughly) 17 weeks and 35 weeks before the start time.

David

Martin <New...@avisoft.f9.co.uk> wrote:

> On 23 Apr in article

> <6667d647-6873-488d...@googlegroups.com>,

> <jeffrey....@gmail.com> wrote:

> > > Indeed. But what happens when the 5-byte hex times are...

> > > start time = 58 00 00 04 00

> > > end time = 57 00 00 05 00 gives x100 ... when it should be

> > > flagged as negative and duff!

>

> > That would require the judge on the finish line to press his button 35

> > weeks before the starter presses his button. Cannot happen.

>

> Unfortunately the OP in his first post said...

> > I need to reliably detect negative results, which can occur if a spurious

> > finish time pulse arrives before a start time.

Still OK; it won't go wrong unless the spurious pulse arrives between
> On 23 Apr in article

> <6667d647-6873-488d...@googlegroups.com>,

> <jeffrey....@gmail.com> wrote:

> > > Indeed. But what happens when the 5-byte hex times are...

> > > start time = 58 00 00 04 00

> > > end time = 57 00 00 05 00 gives x100 ... when it should be

> > > flagged as negative and duff!

>

> > That would require the judge on the finish line to press his button 35

> > weeks before the starter presses his button. Cannot happen.

>

> Unfortunately the OP in his first post said...

> > I need to reliably detect negative results, which can occur if a spurious

> > finish time pulse arrives before a start time.

(roughly) 17 weeks and 35 weeks before the start time.

David

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu