Re: HPGCC keyboard input

On Thu, 31 Aug 2006 02:32:03 -0500, Chris Smith wrote:

[excellent overall perspective of product architecture]

The current top line of HP calculators contains one processor (an ARM)
emulating another processor (a Saturn, which is no longer produced in
physical form), which runs the calculator software. This is "good
enough" for many operations, but it is many times slower than what the
ARM processor is capable of doing.

Furthermore, most traditional programming for these calculators was done
in interpreted languages. Specifically, many programs were written in
RPL (either SysRPL or UserRPL), which is... run under an interpreter.So the actual picture was more like
Program->Intepreter->Saturn->Emulator->ARM.

All calculators will be "interpreters" of some sort, because it's
the only way of structuring an environment at a simple user level,
so that you don't need a general programming course to use a calculator
(as well as to keep users from crashing the calc all the time).

The amount of "interpreter" overhead in RPL is as minimal as can be,
each object even starting not with a code, but with the actual
memory address to which the CPU goes to act on that object!
(this is exactly what made it difficult to port binary user programs
between models, which would have been effortless if calc programs
were really "interpreted" in the general form most people might imagine).

HPGCC allows you to write code in C
(not RPL, nor some little-used assembly language)

Though I'm not an HPGCC user, I have the impression that
HPGCC treats the calculator platform as a raw computer,
with the built-in calc OS (and its thousands of pre-programmed functions)
almost entirely scrapped, and would even let you write a new OS
(if there were enough memory), right?

The "little used assembly language" and the basic design
of the original Saturn processor were specifically engineered
for the qualities which HP calculators have been known for,
such as pure decimal calculation, the "round to even" floating-point,
and the re-use of the algorithms and function libraries
proven over many years, as depended upon by
thousands of user-developed programs and applications,
much as is the case with any other well-developed environment.

In return (there's always a down side), it is considerably harder
to interact with the calculator environment
such as the stack and variable contents.

Exactly -- the calc product is, as it always was, made for users
to personally interact with at an end-user (application) level,
including an abstract (and simple) programming language
suited for a calculator, rather than for a general-purpose computer.

To get some perspective on what this means, though, HPGCC programs often
run hundreds of times faster than the equivalent code in SysRPL. They
also have access to certain hardware features (notably, grayscale
graphics) that aren't available to the emulated calculator environment.

Even my old first 8_MHz IBM PC probably could do everything
that a 2.5_GHz dual-core Zeon computer does today, if only
that bloated, resource-hogging Windows OS were replaced
by the original MS-DOS, but someone always
manages to find a way to use up all the hardware capability
and leave me at exactly the same end-user speed :)

At any rate, HPGCC is the only tool which lets you
"cut through" the layers of calculator product
to get at the innermost hardware on which it runs,
or at least to get to a level where you can
manipulate what's in memory using the "C" language,
but then, to connect with the user, you still have to
take into consideration the unique environment
of the entire platform, including the expectation that
this newly opened inner environment can somehow
be seamlessly merged with it -- which I hope
will become a complete success.

[r->] [OFF]
.

Relevant Pages

  • Re: Calculator defined
    ... I'll create the basic development enviroment. ... Hot-swapper program that can save your entire calculator to SD (all ... New environment based on LUA, which is better than Python for this ... -Saturn emulator (with a bit better emulation, more accurate graphics, ...
    (comp.sys.hp48)
  • Re: Calculator defined
    ... > Hot-swapper program that can save your entire calculator to SD ... and load a completely new environment ... which can hot-swap entire HOME directories (up to 256K RAM) ...
    (comp.sys.hp48)
  • Re: Notepad > Emu48 > Calculator
    ... testing on the emulator then transferring then on the calculator ... If instead the file is carried to the calc on an SD card, ... on the calculator, the same as on Emu48, and the same thing occurs. ...
    (comp.sys.hp48)
  • Re: Is it time to stop research in Computer Architecture ?
    ... that anyone learned in school. ... language that has been mentioned in this forum. ... gigantic and noisy mechanical calculator in the lab where I worked at ... I also have more hardware courses than software courses on my ...
    (comp.arch)
  • Re: extended operators
    ... of valid source works on it, but here and there, minor alterations might be ... PDScript was based mostly on me hacking together an interpreted scripting language with a vaguely JavaScript/Scheme-style hybrid syntax, and internally based heavily on XML-based parse trees; ... BGBSCM was a Scheme interpreter, going back further, it was based partly on my attempt at immitating the internals of SCM and Guile (and eventually included more than a few alternate parsers, where I was experimenting with ways to try to escape from the IMO horridness s-expressions...). ... so, it has a bizarre syntax, but is IMO fairly good as a calculator. ...
    (comp.std.c)