Can FORTH be extended into RPL?

[Jim Cook]

I've read through the HP provided docs for sysRPL,
especially the first chapter. I think I understand the
fundamental differences between FORTH and RPL. Can a
standard version of FORTH be modified through word
definitions to provide the functionality of RPL?

Since I've moved into engineering management, I found the
PalmPilot to be more useful in my work than my HP-48. But,
I miss programming in RPL. There is a very good
implementation of FORTH for the PalmPilot which, of course,
is very similar to RPL. I can make it even closer to RPL
through additional word definitions. The major differences
seem to be in the addition of LISP like list manipulations
and the different objects (comp, bin, etc.) used in RPL.
This makes it seem a little more daunting to me.

What I really need is an implementation of the HP's Solver
for the PalmPilot...

Better yet, an HP-48 (S or G) emulator that will work with
the PalmPilots hardware (68000 series CPU, 1M RAM)and OS!

James Cook

[Steve VanDevender]

"Jim Cook" <jc...@komsil.com> writes:

> I've read through the HP provided docs for sysRPL,
> especially the first chapter. I think I understand the
> fundamental differences between FORTH and RPL. Can a
> standard version of FORTH be modified through word
> definitions to provide the functionality of RPL?

In theory, yes; in practice, it could get ugly. In the FORTH
implementations I'm familiar with, the primary stack is a stack of
integers and most operations deal implicitly with integers. RPL is
inherently a dynamically typed language, meaning that type information
is part of an object, not a property of an identifier or the elements of
a data structure. Extending FORTH to work similarly to RPL would
probably involve using something like 'typed pointers' -- using some
bits of a pointer to store a type tag and storing those pointers on the
stack or in identifiers, with all operators redefined to examine type
information of their operands to select the appropriate specific
operation to perform, and to know what data lies in the objects.

RPL objects always have a type tag at the beginning of the object that
uniquely defines the object (cleverly, this tag is the address of a
routine for pushing the address of the object on the stack, more
cleverly a routine capable of determining whether it was invoked
indirectly via a pointer to the object in the runstream, or the object
itself embedded in the runstream, so that it knows which address to push
on the stack). All operators in user RPL look at the type tags for
their operands and select exactly what operation to perform. FORTH, on
the other hand, doesn't usually have to go to that much work. System
RPL gains speed at the expense of type safety -- many operations assume
that they have been given objects of appropriate types for arguments and
blindly manipulate them as such.

Before anyone flames me for saying something wrong about FORTH -- the
only FORTH I've worked with was a weird Apple II version a long time
ago. However, as I recall FORTH was designed to be pretty darn simple,
and I've never seen FORTH extended to use floating-point or other object
types.

--
Steve VanDevender "I ride the big iron" ste...@efn.org
ste...@hexadecimal.uoregon.edu http://jcomm.uoregon.edu/~stevev
"bash awk grep perl sed df du, du-du du-du,
vi troff su fsck rm * halt LART LART LART!" -- the Swedish BOFH

[Jeffery Wood]

> However, as I recall FORTH was designed to be pretty darn simple,
> and I've never seen FORTH extended to use floating-point or other object
> types.

Forth has come a long long way since then.

Jeffery

[Norm Arnold]

Steve VanDevender wrote:

> "Jim Cook" <jc...@komsil.com> writes:
>
> > I've read through the HP provided docs for sysRPL,
> > especially the first chapter. I think I understand the
> > fundamental differences between FORTH and RPL. Can a
> > standard version of FORTH be modified through word
> > definitions to provide the functionality of RPL?
>

> <snip>

>
> Before anyone flames me for saying something wrong about FORTH -- the
> only FORTH I've worked with was a weird Apple II version a long time

> ago. However, as I recall FORTH was designed to be pretty darn

> simple,
> and I've never seen FORTH extended to use floating-point or other
> object
> types.
>

> --
> Steve VanDevender "I ride the big iron" ste...@efn.org
> ste...@hexadecimal.uoregon.edu http://jcomm.uoregon.edu/~stevev
> "bash awk grep perl sed df du, du-du du-du,
> vi troff su fsck rm * halt LART LART LART!" -- the Swedish BOFH

Check out HSForth (Harvard Softworks). I don't know if they are
still in business but in 1986 their HSForth could do floating point math
and a lot more. It was capable of:
- full string support
- support of the 8087 floating point co-processor
- an editor
- a tracing utility
- a decompiler
- vectored execution
- hyperbolic trigonometry of complex numbers
- array and matrix manipulation
- graphics (including the ability to save and restore whole or partial
screens)
- user-defined windows
- built in assembler language complete with an optimizer
- sound and music capabilities
- and much more.
All this was accomplished on a DOS 2.X platform
----------------------------------------------------------------------
Norm_...@bc.sympatico.ca
It now costs more to amuse
Norm Arnold a child than it once did
Surrey, British Columbia to educate his father.
Canada - Herbert Prochnow
----------------------------------------------------------------------

[Neville A. Joseph]

In article <87raa72...@efn.org>, Steve VanDevender <ste...@efn.org>
writes

>
>
>Before anyone flames me for saying something wrong about FORTH -- the
>only FORTH I've worked with was a weird Apple II version a long time
>ago. However, as I recall FORTH was designed to be pretty darn simple,
>and I've never seen FORTH extended to use floating-point or other object
>types.
>

While Forth has come a long way since then, the fact remains that it is
intended to be a fast and simple language with a lot of possibility for
extensions. While it can have have Floating-point, this is most often a
separate group of instructions using a separate stack - I think that
hardware manufacturers convenience outweighs anything else, but the
width difference between 16 or even 32 bits for FXP and 64 for FLP has
proved too difficult in practice for suppliers to try and combine.

I think that this really points out the problem. If two different
sizes have proved impossible to combine, what hope is there for the
range of possibilities in RPL. I think that you have to choose the
simplicity of a fixed width object on a simple stack, where for speed
and simplicity the actual object is on the stack, and the flexibility of
RPN where the stack only has pointers.

I do not see why, however, you should not implement Forth on RPL by
merely keeping to a simple set of commands all using the same type of
object, and in the next version of the 48 I do not see why Binary
Integers (which are 20 bits long in the 48, but might have to be a
little longer in the next machine as memory is bound to be larger, so I
would expect the equivalent to be 24 bits if the new machine follows the
present ideas and is not a complete restart) should not be provided as
an object type for general use. It would then be a simple :-) matter
to have a similar type of BINT which actually resides on the stack
instead of merely being a pointer, or possibly a system flag could
differentiate between pointers and actual BINTs on the stack.

Incidentally I should be pleased to learn if there is a genuine reason
why BINTs are not available to the user as working with them must of
necessity be faster than working with 16-digit reals, particularly as
the processor has faster instructions for the fixed size of a BINT quite
apart from the speedup in moving 11 less digits every time.

The speed of Forth comes from its lack of checking, which you can get,
to some extent, even on the slow 48 processor by using system RPL.
This gives you, in exchange for loss of speed, automatic usage of
15-digit real numbers but there is no penalty for voluntarily
restricting yourself to integers. What is there, therefore, in Forth
that you see as lacking in RPL, bearing in mind the difference in
outlook between a language intended for control and a language intended
to have a great deal of input-output (the amount of conversion needed
would probably make a binary-based 48 slower than the decimal-based on
we have - this is of course the opposite position of most computer
uses).
--
Neville A. Joseph

[Neville A. Joseph]

In article <wQx+$AA91C...@najoseph.demon.co.uk>, "Neville A. Joseph"
<n...@najoseph.demon.co.uk> writes

>I do not see why, however, you should not implement Forth on RPL by
>merely keeping to a simple set of commands all using the same type of
>object, and in the next version of the 48 I do not see why Binary
>Integers (which are 20 bits long in the 48, but might have to be a
>little longer in the next machine as memory is bound to be larger, so I
>would expect the equivalent to be 24 bits if the new machine follows the
>present ideas and is not a complete restart) should not be provided as
>an object type for general use. It would then be a simple :-) matter
>to have a similar type of BINT which actually resides on the stack
>instead of merely being a pointer, or possibly a system flag could
>differentiate between pointers and actual BINTs on the stack.
>
>Incidentally I should be pleased to learn if there is a genuine reason
>why BINTs are not available to the user as working with them must of
>necessity be faster than working with 16-digit reals, particularly as
>the processor has faster instructions for the fixed size of a BINT quite
>apart from the speedup in moving 11 less digits every time.
>

For the avoidance of doubt I am referring to internal binary integers
and not user binary integers (the former also called system binaries).
I apologise if I have created confusion :-(
--
Neville A. Joseph