Prev: When finite precision creates big mistakes...
Next: July programming challenge update
From: John H Meyers on 3 Aug 2010 09:18
On 8/3/2010 3:52 AM, Kim DeVaughn wrote:

> John H Meyers<jhmeyers(a)nomail.invalid> writes:
>> On the confused meaning of "UBASE bug":

> OK ... how about UAB (Undocumented Anomalous Behaviour)
> of the UBASE command then ... :-) ...?

The only anomalous behavior is the presence of unsupported ROM addresses
in many UBASE results, which could become serious if binary object results
were transferred between ROMs in which these addresses were not consistent.

> I'm not at all clear on HP's motivation in creating multiple forms
> of objects that purport to be the same thing (eg, TYPE 13), but
> really aren't. Was it just to save a bit of memory here and there,
> or for performance reasons, or ???

It's normal for all "composite" objects, because of a basic design of RPL,
that an actual piece of data is equivalent to a ROM address of the same data,
and also because several equal objects at different addresses
are all equal, despite that composite objects containing the different addresses
of equal components are not the same object.

> Perhaps this explains the use of some weasel-words in the AUR on
> p. 3-215 for the SAME cmd, WRT unit objects:
>
> "SAME is identical in effect to == for all object types except
> algebraics, names, and some units."

The AUR is quite wrong here, as has already been demonstrated.

Here's another case:

1. BYTES DROP result is #0
#0 == result is 1.

1. BYTES DROP result is #0
#0 SAME result is 0.

In this case, the _lengths_ of each #0 are different,
although the _values_ are equal.

In fact, _all_ binary checksums produced by BYTES
are shorter than normal, exactly equal "user binary integers,"
hence _no_ binary result of BYTES is the SAME as
a comparable separately entered user binary integer,
even when they are equal per ==

This is basically just the fact that #0000000000000000h
(standard-length "user binary integer")
is equal to #0h (a shorter-length "hex string"), yet not the SAME, etc.

As to "some units," of course, 2.54_cm 1_in == results in 1.
while 2.54_cm 1_in SAME results in 0.

> The question now is which of the emulators, etc. mimic the "proper"
> operation of the UBASE and/or SAME commands (with "proper" being
> defined as the way the calculator does it).

Emulators normally use a ROM image file,
and run just as said ROM version would run on a calculator.

> I would check into this, but I have been quite unsuccessful at
> getting any such programs to run on Win7 (64-bit).

How installed, and what's the exact problem/error?

I've neither read about this nor have a system to test on,
so have to see what answers come forth here.

> I do see that there is a new version of Debug4x
> that specifically mentions Win7 and 64-bits.

http://www.debug4x.com/
Version 2.2, Build 145
"Works on Windows 7, both 32 and 64 bits."
"Files & Folders Have Moved since the XP Version - Read VersionInfo.txt"

Okay, I'll read it: http://www.debug4x.com/VersionInfo.txt

I see only one mention of Windows 7:

Windows 7, XPMode and some network situations have path names which
begin with "\\", these were not handled properly and caused errors.
Typically the root path would be duplicated in the error message as:
\\root\folder\root\folder\... could not be found.

Searching for "64"... no matches.

Glad to see that it still works even on good old XP (32-bit)!

Here's something of interest to me:

VERSION (in ROM, for 50G) results in: 2.15
This ROM file also works in Emu48,
but in _either_ Debug4x _or_ Emu48,
ON+D locks up the emulator -- due to "boot block" replacement?

There was no actual need to replace that block in the Emu ROM, was there?
Can that block be restored from locations in the older ROMs?
The STRM command is, after all, rather useless in these emulators
(but you can try it anyway, just to see :)

[r->] [OFF]
From: TW on 3 Aug 2010 10:46
> There was no actual need to replace that block in the Emu ROM, was there?

Yes there was. The space was needed for native C BCD math library
code.

> The STRM command is, after all, rather useless in these emulators
> (but you can try it anyway, just to see :)

The emulator connects to streamsmart devices just like a real
unit. . . so yes, there is need.

TW
From: TW on 3 Aug 2010 11:25
> Yes there was. The space was needed for native C BCD math library
> code.
Should qualify that by saying that it wasn't just the BCD code which
emu48 emulator obviously doesn't use, but also the rest of the
application that needed the space as well. There just wasn't any
purpose to keep a huge chunk of dead code around that isn't used on
any product HP sells or supports. . .

TW


From: John H Meyers on 3 Aug 2010 12:17
On 8/3/2010 9:46 AM, TW wrote:

>> There was no actual need to replace that block in the Emu ROM, was there?

> Yes there was. The space was needed for native C BCD math library code.

>> The STRM command is, after all, rather useless in these emulators
>> (but you can try it anyway, just to see :)

> The emulator connects to streamsmart devices just like a real
> unit. . . so yes, there is need.

The _Saturn_ emulators do all that? Emu48 does all that?
Is the native C BCD math library compiled for Saturn?

What if someone were willing to forgo use of STRM,
and would rather replace the original block?

[r->] [OFF]
From: TW on 3 Aug 2010 12:30
> The _Saturn_ emulators do all that?  Emu48 does all that?

No, emu48 does not do that. HP's emulator distributed to educators
however does. No, it is not an ARM emulator.

> What if someone were willing to forgo use of STRM,
> and would rather replace the original block?

I don't think anyone is trying to stop that. . .

TW
 |  Next  |  Last
Pages: 1 2
Prev: When finite precision creates big mistakes...
Next: July programming challenge update