MIDI-OX User Forum - Print Page


    
      
        MIDI-OX User Forum
        (http://www.midiox.com/cgi-bin/yabb/YaBB.pl)
      

        HP16C Emulator >> HP16C Questions and Discussion >> HP16C Version 2.0 Beta feedback
        
(Message started by: RickN on Mar 11^th, 2008, 10:43am)

Title: HP16C Version 2.0 Beta feedback
Post by RickN on Mar 11^th, 2008, 10:43am

Hi Jamie,

Thanks for putting more time into the emulator. It was unclear where you wanted feedback so I started this topic. I haven't tried new features but did some regression testing by running all my existing programs on the Beta. They all worked, including "approximate e to 7800 digits". So far the biggest difference I see is in execution time. Working at full speed, with the calculator and stack windows open while watching a program execute, I measured 9% faster execution time than the purchased version (good). But with only the calculator window open and iconified, for the fastest operation possible, I measured 82% slower execution time -- almost twice as long to execute the program. I realize this isn't that important to most users, but it surprised me. (I compared version 1.4.0.22 to version 2.0.0.29 on the same PC.)

I will try to put more time into this, specifically looking more at the new features, before the end of March.

Thanks again,
Rick

Title: Re: HP16C Version 2.0 Beta feedback
Post by Jamie OConnell on Mar 15^th, 2008, 4:08pm

Thanks. It turns out that this is an expected result of operation because of the way the Windows scheduler operates: minimized Windows are naturally set to a lower priority than foreground Windows. Running a program in the emulator is done on a separate thread from the UI anyway, so you wouldn't likely see an improvement just by hiding the UI.

Title: Re: HP16C Version 2.0 Beta feedback
Post by RickN on Mar 30^th, 2008, 2:38am

Starting in full-resolution floating point mode ("f FLOAT ."), enter "1.234567890 EEX". The real calculator displays "1.234567 00" and is ready for exponent digits. The emulator displays "1.234567890" and ignores further digit entries.

Title: Re: HP16C Version 2.0 Beta feedback
Post by RickN on Mar 30^th, 2008, 5:43pm

I see the online Help says "Known Differences, Index Register: In the hardware calculator, the Index register has 68 bits of width. The Emulator uses an Index register of 64 bits width. However; empirical tests show that the hardware calculator index register appears to roll over after 64 bits of counting, so the fact that the original register is 68 bits seems to be only an artifact of the hardware chip used to implement the device."

I posted the following 10/16/05 that disagrees with the above, and just verified it is still a visible difference between the emulator and real calculator: "What follows is contrived, but gives an easy way to see the difference between the HP-16C's 68-bit I register and the emulator's 64-bit. Program to increment RegI and return 0|1 if it is 0|non-0: LBL A, 0, ISZ, 1, RTN. Do these keystrokes: HEX, 0, WSIZE, UNSGN, 40, MASKL, STO I, GSB A. The calculator gives 1 because its RegI has value 1<then 64 0 bits> and the emulator gives 0 because its RegI has value 0."

Title: Re: HP16C Version 2.0 Beta feedback
Post by RickN on Mar 30^th, 2008, 5:58pm

on 03/15/08 at 16:08:49, Jamie OConnell wrote:

I think you misunderstood my post. I am comparing the behavior of 2 versions of the emulator under exactly the same Windows PC and runtime conditions, and the new version is way slower than the old.

Also (a separate subject) both old and new versions of the emulator do run significantly faster for a many-minute long program when all windows are iconified. I use my "approximate e to 400 decimal places" program to see this. Even if calculation and UI are different threads, there must be pacing and fixed buffer size between them such that for a long program, calculation can't go faster than the UI can respond.

Title: Re: HP16C Version 2.0 Beta feedback
Post by Jamie OConnell on Apr 3^rd, 2008, 6:16pm

I do not think I misunderstood at all. Run the Windows Task Manager and sort by CPU%. Look at the performance graph. Start a program running on the emulator and then minimize (iconify) it. Regardless of whether you have performance set for services or for programs, you should see the performance graph slow significantly right after you minimize (iconify) the emulator. This issue is completely controlled by the Windows OS -- Any program run minimized (iconified) is going to run quite a bit slower, although it also depends on what other OS services are running as well as other variables.

Differences between the two versions of the emulator likely have much to do with the fact I am using a newer version of the MSVC++ compiler.

Title: Re: HP16C Version 2.0 Beta feedback
Post by Jamie OConnell on Apr 3^rd, 2008, 9:08pm

on 03/30/08 at 17:43:25, RickN wrote:

Fair enough. I can see your example -- can you think up any practical uses for that? For what it's worth, the data I was citing was from a different discussion:

Quote:

> Do you suggest that those extra 4 bits would hold a multiplier to be applied
> to the "normal" value of the address register? The manual is
> surprisingly ambiguous as far as the formatting of the index register is
> concerned, so that this might be possible.

My guess is that it is not a multiplier but an additional four bits of
space to compute physical nybble addresses (when the word size is
greater than four bits) without throwing away the most significant
bits of the 64-bit integer. To quote the manual:

"A number stored in RI will be represented in a 68-bit format,
numerically equivalent to the number in the X-register."
(Section 6, p.68)

But the HP-16C index register hides even more puzzles:-

If you examine the behaviour of the index register with different word
size settings, using ISZ to find out where it rolls over to zero.
This invariably happens at 2^64, not 2^68.

Perhaps more interesting is to try this out in different complement
modes. You will find that ISZ never skips in unsigned mode, skips at
FFF...FFFF in one's complement mode and at 000...0000 in two's
complement mode. I guess this is correct behaviour.

Now see what happens if you change the complement mode after loading
the index register. If you experiment with a little program like:

LBL A
ISZ
GTO A
R/S

setting up the complement mode, loading a suitable value into RI
(FFF...FFFE or less), changing the complement mode and seeing where
the routine stops, you will notice even stranger behaviour:-

* If you load RI in unsigned mode or two's complement mode and then
change mode before running the little routine above, the machine will
honour the mode that was in force _when_the_register_was_loaded_.

* If you try the same trick loading the register in one's complement
mode and then switching to unsigned mode, the machine will execute the
ISZ instruction as though it was in two's complement mode.

... This is probably a bug...

Title: Re: HP16C Version 2.0 Beta feedback
Post by Jamie OConnell on Apr 3^rd, 2008, 9:10pm

on 03/30/08 at 02:38:30, RickN wrote:

Thanks! I know this was working at one time, and I just got it working again -- although I see it was also broken in the shipped version.

Title: Re: HP16C Version 2.0 Beta feedback
Post by RickN on Apr 4^th, 2008, 2:54am

on 04/03/08 at 18:16:03, Jamie OConnell wrote:

I think there is misunderstanding... I am talking about execution time measured with a stopwatch, not CPU cycles per time period. The emulator runs (completes its user program) over twice as fast when iconified as compared to being displayed. For example, with calculator, stack, register, and program windows visible, run my "e to 400 decimal places program and watch LastX decrement from 211 to 1. On my PC it takes about 520 ms/value. Make the same measurement with all windows iconified. (I start the stopwatch and iconify all 4 windows when LastX is 200, wait about 30 seconds, uniconify, note the value of LastX, and stop the stopwatch.) 208 ms/value, or over twice as fast, because all the user interface graphics updates are bypassed. The emulator has much less of a job to do (no graphics updates), so completes its user program much faster.

Title: Re: HP16C Version 2.0 Beta feedback
Post by RickN on Apr 4^th, 2008, 3:13am

on 04/03/08 at 21:08:22, Jamie OConnell wrote:

Fair enough. I can see your example -- can you think up any practical uses for that?

The probability anyone would encounter a problem with a 64-bit index register instead of a 68-bit one is small, but I don't think that is the most important question. Would you rather say "I believe the emulator gives the same results as all or most actual HP-16C programs"? All it takes is one counter example to cast doubt on its performance. I think it is more your burden to prove/believe that there is no practical use for a 68-bit register, and that a 64-bit substitute wouldn't cause anyone any problems.

Title: Re: HP16C Version 2.0 Beta feedback
Post by RickN on Apr 4^th, 2008, 3:29am

on 03/11/08 at 10:43:54, RickN wrote:

...with only the calculator window open and iconified, for the fastest operation possible, I measured 82% slower execution time -- almost twice as long to execute the program. I realize this isn't that important to most users, but it surprised me. (I compared version 1.4.0.22 to version 2.0.0.29 on the same PC.)

on 04/03/08 at 18:16:03, Jamie OConnell wrote:

...Differences between the two versions of the emulator likely have much to do with the fact I am using a newer version of the MSVC++ compiler.

That is a big execution speed difference for just a compiler change, but maybe... I thought it might be related to other changes like register bound management or floating point BCD arithmetic (although the program being measured doesn't do floating point operations). Regardless, if speed is important, like "e to 7800 decimal places", the older version is way faster. Like anyone other than me would notice... ::)

Title: Re: HP16C Version 2.0 Beta feedback
Post by Jamie OConnell on Apr 5^th, 2008, 5:15pm

on 04/04/08 at 03:13:27, RickN wrote:

Ultimately, I would have to agree with that. However; at this point I choose to document it as a non-conforming difference, albeit with different wording than that which caused you to point it out.