From: John H Meyers on
On 6/29/2010 7:24 PM, Han wrote:

> I'm not sure I can wholeheartedly agree here. The point of an emulator
> is to emulate -- be as close to the real thing as possible. The point
> of a debugger, though, is to try to find bugs that the user created.

I think that the point of a debugger is only to step through
what actually happens on the real machine.

This helps a programmer to find his/her own problems,
but I think it no favor to make it produce results
that can't, in the end, be duplicated on the real hardware,
after which the programmer can be left perplexed, saying
"but it works perfectly when debugging, so there can't be any bug" :)

Or to look at it another way, shouldn't the debugger
also detect bugs in the ROM, rather then try to hide them,
particularly when they are not going to be fixed,
but instead have to be faced and dealt with?

--
From: John H Meyers on
On 6/29/2010 7:59 PM, Andreas Möller wrote:

> Some examples for programs that rely deeply on the underlying
> microprocessor: Compiler/Decompiler (Jazz)

The original (HP48) Jazz (I use Jazz 5.9 in Hacker's ROM Rev. B)
works for me under Emu48 -- is Emu48 at least faithful to the Saturn?
If not, can it be fixed?

Apparently you have succeeded in working around a bug in the ARM emulator
on the HP49G+/50G series (which needed major update to Jazz), in your own projects.

Everyone has probably been faced with working around bugs,
including those in ROM functions or in the CAS.

If the bugs won't work themselves out,
then what else can we do but discover them,
then defend against and work around them?

You might be able to patch the internal emulator and reload it
into real calculators, but then programs which can only run
under those ideal conditions could be used only by people
who first patch their own calculators.

I seem to recall that Wolfgang Rautenberg was very annoyed
that certain ROM functions upon which he depended for his advanced libraries
were not "supported," hence might (and subsequently did) move between ROM versions.

But, insisting on using them anyway, because they enabled his programs
to be smaller and faster, with which goal he seemed to have been obsessed,
he released some libraries which later crashed after ROM updates
(did they cause anyone the inopportune total loss
of all their stored info and personal investment in programming?)
and had to be updated for later ROM versions.

This could lead to a discussion of whether to aim for absolute
minimum program size and time, or for absolute maximum of safety,
or somewhere between, and I suppose not everyone will ever be persuaded
of any particular position on that entire scale,
which considerations have their parallels in every field of engineering,
of software, of hardware, of economics, and of everything up to
the overall management of all the world's societies, resources,
and the future of this "Spaceship Earth," as R. Buckminster Fuller called it.

[r->] [OFF]

From: John H Meyers on
On 6/29/2010 7:59 PM, Andreas Möller wrote:

JHM:
>> Of course, all versions through 2.10 also run fine on HP49G,
>> although getting the 49G updated needs an emulator's help

AM:
> Thanks again for telling me what I described first in this newsgroup,
> although a detailed explanation based on my post was given by James M.
> Prange.

I am not telling you; this is a public newsgroup, to which new users
who don't yet know things may arrive at any time, and might like to know;
it might also give them some perspective on what otherwise would seem
a closed "insider" discussion without wider meaning to them.

[r->] [OFF]

From: Han on
> I think that the point of a debugger is only to step through
> what actually happens on the real machine.

You make a very good case here. I think I will revert CK&DISPATCH1
behavior to mirror that of ROM in the next release -- at least until
the bugs are fixed in the ROM itself (I won't hold my breath).
From: Andreas Möller on
Hello,

> I would love to have a copy of the talk
You got mail.

Regards,
Andreas
http://www.software49g.gmxhome.de