The Museum of HP Calculators

HP Forum Archive 13

[ Return to Index | Top of Index ]

HP-41 programming question
Message #1 Posted by Axel Poqué on 31 July 2003, 9:31 a.m.

I'm writing a little program to time the performance of other programs. I figured that the easiest way would be to place the name of the program to time in the alpha register and then start the timing program which would do the following:

     ...          ; start stopwatch
     asto T       ; uses T since I want to preserve X
     xeq  ind T
     ...          ; stop watch and display time 

Is this the right way to do it or is there another possibility (one that doesn't use a stack register)? My documentation is at home so I can't look it up now.

Axel

      
Re: HP-41 programming question
Message #2 Posted by Werner Huysegoms on 31 July 2003, 10:12 a.m.,
in response to message #1 by Axel Poqué

I use L for it
  ASTO L
  XEQ IND L

Werner

            
Re: HP-41 programming question
Message #3 Posted by Axel Poqué on 31 July 2003, 10:16 a.m.,
in response to message #2 by Werner Huysegoms

So it's OK to do it this way? And you're right, using L doesn't disturb the stack at all (should have thought of that).

Thanks,
Axel

Edited: 31 July 2003, 10:17 a.m.

      
Re: HP-41 programming question
Message #4 Posted by Vieira, Luiz C. (Brazil) on 31 July 2003, 10:21 a.m.,
in response to message #1 by Axel Poqué

Hi, Axel;

you know, when I bought my HP41CX I began doing time measures for whatever I thought relevant as internal resources. I once programmend the following:

...
RUNSW
XEQ "PR1"
STOPSW
...
END
LBL "PR1"
END
This was just to start: time to jump to a program and return. Tehn I added these modifications:

...
RUNSW
XEQ "PR1"
...
END
LBL "PR1"
STOPSW
END
and
...
XEQ "PR1"
STOPSW
...
END
LBL "PR1"
RUNSW
END
so I could measure the jumping and return time separately. I also did this:
...
RUNSW
LBL "PR1"
STOPSW
...
to measure the LBL instruction time. And:
...
RUNSW
STOPSW
...
for the system time spent since the stopwatch was started and stopped. All of these measures were repeated 10 and 20 times for average and I have them annotated somewhere. As you seem to be in a hurry, I decided to pass you the hint.

If the program to be measured cannot be changed, then te way you describe seems the best one. Anyway, a first measure with a blank LBL"name"END just to capture the jumping ang return would give you some more info. But if you have the chance to change the program to be measure, try this:

LBL"MEAS"
CLX
STOPSW
SETSW
RUNSW
LBL"PRG1"
....
(last program step - cannot be STOP or END or RTN)
STOPSW
...
END
where PRG1 is the program to be measured and MEAS is the name I gave to the measuring program additional part. This would also give you the chance to measure PRG1 execution time. The only fact is that you cannot add a STOP, or RTN or END in your original program because you still need the clock running. The other way would be:
LBL"MEAS"
CLX
STOPSW
SETSW
RUNSW
XEQ"PRG1"
STOPSW
...
STOP
LBL"PRG1"
....
END
As you are aware of the initial jumping time and pre-measuring, after you compute the basic program execution time you just compensate the values.

I hope this is something close to what you have in mind. If not, I'm sorry not helping you the way you want.

Best regards.

Luiz (Brazil)

Edited: 31 July 2003, 10:25 a.m.

            
Oops! Far from you question...
Message #5 Posted by Vieira, Luiz C. (Brazil) on 31 July 2003, 10:28 a.m.,
in response to message #4 by Vieira, Luiz C. (Brazil)

Hi, Axel;

I'm sorry if I added so much information to your question. After reading Werner's posts and your reply I understood I was far from your request. Maybe you are aware of what I wrote.

If you believe what I wrote is irrelevant, please, let me know, so I'll remove my post. If you believe it is of any help, that's better.

Best regards.

Luiz (Brazil)

            
Re: HP-41 programming question
Message #6 Posted by Axel Poqué on 31 July 2003, 10:36 a.m.,
in response to message #4 by Vieira, Luiz C. (Brazil)

Thanks for your ideas, Luiz.

Since I want to compare different versions of a program to find the optimal way to do it, the overhead of calling the program doesn't matter.

BTW, is there a table somewhere giving the timing of different instructions? Has someone already done this? Or I might just do one myself (I'm on holiday the next 3 weeks, so I've got plenty of time).

Axel

                  
Re: HP-41 programming question
Message #7 Posted by hugh on 31 July 2003, 12:12 p.m.,
in response to message #6 by Axel Poqué

in terms of instruction timings, i would expect branches to have a sensitive effect. according to the 41c docs, it scans forward to find a local jump destination (lbl 00-lbl14) until END, then wraps to the program start. this would make forward jumps quicker than backward ones.

also, it claims to cache the destinations for 00-14 unless they are over 112 bytes away. im not sure whether it caches labels 15+ (which are 1 extra byte).

                        
Re: HP-41 programming question (edited)
Message #8 Posted by Vieira, Luiz C. on 31 July 2003, 12:26 p.m.,
in response to message #7 by hugh

Hi, Hugh;

as you mention, all jump destinations are recorded except when calls ment to "short" are used for longer than expected. In this case, computed distance is not recorded and everytime a GTO or XEQ is found, it is computed again.

LBL 15 to 99, LBL "A" to "J" and "a" to "e" may be used for longer calls (I don't remember how far they can be from the related XEQ or GTO), and global labels may be anywhere in main memory that their distance to XEQ and GTO is always saved.

About timming each instruction: I have some relevant measures and as I find my notes I'm postiing them.

My 2¢.

Luiz (Brazil)

Edited: 31 July 2003, 11:49 p.m.

                              
Re: HP-41 programming question (edited)
Message #9 Posted by Johnny Billquist on 5 Aug 2003, 7:51 a.m.,
in response to message #8 by Vieira, Luiz C.

All local labels can be at any distance. A linear search is made from the jump to the end of the program, and then from the start up to the jump, until the label is found.

GTO and XEQ for labels 00 to 14 save the relative address in the jump instruction so that the jump can be executed faster in the future. But this has a limit on the distance. They always work, but the relative address is only saved if the distance isn't too long. Longer distances will be just the same as jumps to any other label. GTO IND and XEQ IND will (obiovusly) not save the relative address of the label at any time. Also, as soon as you modify a program, all the saved relative addresses are deleted, so that a new computation will occur the next time you run.

Speaking of distances, my memory seems to have some vague notion of a bug in the early C version, where a program could get into problems if it was too large (over 1000 steps perhaps?).


[ Return to Index | Top of Index ]

Go back to the main exhibit hall