From: jhmeyers@miu.edu (John H Meyers)
Newsgroups: comp.sys.hp48
Subject: Is there a UBASE bug?
Date: 16 Oct 1998 07:01:35 GMT
Organization: MIU Computer Services,  Fairfield, IA 52557.  Not Approved.
Lines: 125
Message-ID: <706r0f$73j$1@news.iastate.edu>
References: <7044d3$ga1$1@news.iastate.edu>
Reply-To: jhmeyers@miu.edu
NNTP-Posting-Host: vax1.mum.edu
Xref: republic.btigate.com comp.sys.hp48:17372

Is there a UBASE bug?

Check this out:

  1_m UBASE ==> 1_m  (not a big surprise, right?)

But then try this:

  1_m       BYTES ==> #D2FCh 16

  1_m UBASE BYTES ==> #E983h 12.5

Obviously, not all objects which display as 1_m
were created equally, n'est ce pas?

If you have Jazz handy (or other decompiler/disassembler),
you may see that this comes about because when you enter
1_m, it is compiled into the following object:

  UNIT  %1  $ "m"  umEND  ;

which means a 5-nibble "unit object" prolog, followed by
the real number part of the unit object, followed by
a string containing the unit name, followed by
a token which terminates all unit specifications,
followed by a "semi" (ubiquitous compound object terminator).

However, when you enter 1_m and then perform UBASE, you get:

  UNIT  %1  tok_m  umEND  ;

in which the string has been replaced by a *pointer*
to a ROM object which contains the identical string.

This new object is displayed just like the original object,
and for most purposes behaves just like the original object,
but note that in a program such as { 1_m } 1_m UBASE POS,
the POS command will fail to find the supposedly "equal"
object in the list, because the comparisons made by POS
are not algebraic, but are in the same sense as the
SAME command: the objects must be absolutely identical
in internal structure, not merely equivalent in value.

Oh, well, it's just a small problem, thus far;
after all, the UBASE command merely substituted
a "supported" entry point named tok_m for the string "m";
the result will still be valid in all versions of the HP48,
because that's what "supported" entry points mean,
and the result still represents the same value.

OTOH, how about this:

  1_kg        ==>  UNIT  %1  CHR k     $ "g"  umP  umEND  ;

  1_kg UBASE  ==>  UNIT  %1  PTR FA62  tok_g  umP  umEND  ;

Well, now we suddenly have an *unsupported* entry point
replacing the "character object" CHR k.  However, a search
through the file "entries.all" suggests that this address
is part of an unsupported ROM object 1_kg at address #FA58h,
which has at least not moved between S/SX and G/GX (rom R).

How about this one, then:

  1_r        ==>  UNIT  %1  $ "r"      umEND  ;

  1_r UBASE  ==>  UNIT  %1  PTR 10DAA  umEND  ; [in rom R]

Checking "entries.all", I do not find address 10DAA listed;
I do find listings for the nearest other objects 10D90 and 10E34,
*neither* of which appears correct any longer for rom version R.

1_cd*sr/m^2  vs.  1_cd*sr/m^2  UBASE [in rom R]:

  UNIT  %1  $ "cd"    $ "sr"     um*  $ "m"  %2  um^  um/  umEND  ;

  UNIT  %1  PTR FB0E  PTR 10DCA  um*  tok_m  %2  um^  um/  umEND  ;

While FB0E seems to be part of the unit object 1_cd at FB04,
which has been a stable address, 10DCA looks highly suspicious
again, being right next to the above 10DAA address, which
might not have been the original S/SX address.

So, what does this mean?

If by any chance some of the above unsupported addresses,
created within "user" objects by the UBASE command,
have moved between some ROM versions and others, and if
you have stored any such objects into values or programs
which were transferred to other calculators in binary mode,
then you may thereby have created version-dependent,
incompatible objects and/or programs, even though User-RPL
objects were supposed to be version-independent.

If any owners of various versions of HP48 would care to
check these addresses (or to decompile their own objects
after UBASE and see what addresses they find, as compared
to those above, found in version R), or if any folks still
have their releases of original "developer" ROM source
handy, then perhaps we may obtain a definitive answer
as to whether or not the user UBASE command is actually
buggy, in that it might create version-dependent objects,
which then just might crash another calculator.


The lesson from such incidents is to be cautious about taking
"shortcuts" that save a few bytes, or a few milliseconds,
or a few dollars, but are not very "robust," or else
are clearly dependent upon assumptions and relationships
which may not hold as things change and develop further;
many a product has failed, and sometimes even caused harm,
by not heeding the inner voice of caution about such things.

See also:

"Is cutting corners worth it?"  1997/09/07
<http://www.dejanews.com/getdoc.xp?AN=270458763>

"Structural engineering is the art of moulding materials we do not wholly
 understand into shapes we cannot precisely analyze, so as to withstand
 forces we cannot really assess, in such a way that the community at large
 has no reason to suspect the extent of our ignorance." Dr. A. R. Dykes

-----------------------------------------------------------
With best wishes from:   John H Meyers   <jhmeyers@mum.edu>

From: jhmeyers@miu.edu (John H Meyers)
Newsgroups: comp.sys.hp48
Subject: Re: Is there a UBASE bug?
Date: 16 Oct 1998 08:29:51 GMT
Organization: MIU Computer Services,  Fairfield, IA 52557.  Not Approved.
Lines: 69
Message-ID: <70705v$f80$1@news.iastate.edu>
References: <7044d3$ga1$1@news.iastate.edu>,<706r0f$73j$1@news.iastate.edu>
Reply-To: jhmeyers@miu.edu
NNTP-Posting-Host: vax1.mum.edu
Xref: republic.btigate.com comp.sys.hp48:17381

Yes, there *is* a UBASE bug!

Answering my own previous question, I performed the following
in my HP48G, rev M:

{ 1_r 1_sr } UBASE  [producing no visible change]

I then transferred this list in binary
to my HP48GX, rev R.

Lo and behold, this list now displays on the stack as:

{ 1_UNKNOWN 1_UNKNOWN }

and it disassembles as:

{ UNIT %1 PTR 10DA9 umEND ;
  UNIT %1 PTR 10DC9 umEND ; }   [addresses from rev M]

whereas in rev R the same original "user" object would be:

{ UNIT %1 PTR 10DAA umEND ;
  UNIT %1 PTR 10DCA umEND ; }   [addresses from rev R]

Although it's only a one-byte difference in addresses,
the HP48 does not seem to give us "partial credit"
for being so close :)

It would seem likely that various other versions,
particularly S/SX versions, would probably also
differ from either of these, as someone may
happen to check out and post shortly.

Well, we know how much effort it must have been for HP
to keep all the "supported" entry points from moving
while making version after version of calculator;
still, if they had not taken some "shortcuts" to
save a couple of bytes in the results of UBASE,
this would not have happened.

They did better with %-9 through %9, however, I think :)

BTW, although it is nice that the calc does not crash
upon displaying these objects, containing invalid pointers,
any subsequent attempt to calculate with them seems to be
a pretty successful way to corrupt memory, I have found.

Fortunately, the creation of such objects and distribution
in binary to other calcs seems an unlikely scenario,
which may be why I haven't heard of this problem before;
the only reason it just became apparent is that I had
intended to distribute a slightly faster *binary* version
of the "units conversion aid" program I had just posted,
until I peeked into it using Jazz, and instead "recalled"
the defective product before it got released into the world.

Quite a few of science and engineering's "wonder" products
have not been recalled soon enough, however.

Say, are you sure that you don't want
"genetically engineered" foods to be labeled as such,
as USA producers have managed to avoid doing?

"You are what you eat" (which sounds so much better in German :)

 and good luck to whatever you (and your progeny) become.

-----------------------------------------------------------
With best wishes from:   John H Meyers   <jhmeyers@mum.edu>