ViewLevel1 - Challenge!
Wolfgang Rautenberg
Jean-Yves Avenard wrote:
> For UserRPL program, the new decompiler (coming from the MetaKernel) is so
> fast, that a need to interrupt it become unecessary. Adding a way to
> interrupt it, will only slow down everything by a quite big factor.
OK. But this has the fatal consequence
that if a SysRPL-object is in the stack
and you press unintensionally DownArrow
(the view key) the HP49 "hangs". Only a
warmstart interrupts and the whole stack
is lost. EXAMPLE: put the small assignment
program of the MODE key 23.1 on the stack.
Press DownArrow and you are lost.
Nowadays also users who formerly did'nt care
about SysRPL will now have SysRPL objects on
the stack from time to time, e.g. if producing
mode-sensitive key assignments.
Thus, the only way out is a macro which tests
whether an object is a UsrRPL-object and hence
user-decompilable on the HP49 *before* it is
passed over to that compiler or to ViewLevel1
which amounts more or less to the same. Who
can write such a test in SysRPL or Assembly
which should be
a) very fast, b) very short.
WARNING: For a program as input and would
think simply test whether its components are
EXTERNALS and so recursively down. But this
would fail already for the program
ViewLevel1
of which at least XEQTYPE tells you this is a
program. But INNERCOMP decomposes it to
ViewLevel1 ONE
So you are in a loop which never terminates.
Regards, Wolfgang
PS. On the HP49 I've seen for the first time
objects who contain itself as the single
element. The possible existence of such
objects was forecasted by Frege and Russell
already in 1900 but have never be found in
reality untill the year 2000 on the HP49!
Andrew Koenig
Wolfgang> of such objects was forecasted by Frege and Russell already
Wolfgang> in 1900 but have never be found in reality untill the year
Wolfgang> 2000 on the HP49!
I'm sorry to disappoint you, but the Icon programming language
(from the University of Arizona) has had that capability for years.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Werner Huysegoms
Wolfgang Rautenberg <ra...@math.fu-berlin.de> wrote:
> WARNING: For a program as input and would
> think simply test whether its components are
> EXTERNALS and so recursively down. But this
> would fail already for the program
> ViewLevel1
> of which at least XEQTYPE tells you this is a
> program. But INNERCOMP decomposes it to
>
> ViewLevel1 ONE
>
> So you are in a loop which never terminates.
>
> Regards, Wolfgang
>
> PS. On the HP49 I've seen for the first time
> objects who contain itself as the single
> element. The possible existence of such
> objects was forecasted by Frege and Russell
> already in 1900 but have never be found in
> reality untill the year 2000 on the HP49!
>
Ahh.. I need to check this, so either you or me will be mistaken!
But I think ViewLevel1 is a PCO - and even the new kind, addressing
a common prologue at 11111, where the code will figure out which
FlashPTR to call. The fact that XEQTYPE returns 8. and INNERCOMP
returns the program itself and a ONE is probably due to the fact that
XEQTYPE should only be used with 'real' objects (not PCO's which
should only be executed indirectly, and not put on the stack) and
that INNERCOMP does not check wether its argument is composite.
FYI: a 'normal' CODE object has the layout:
DOCODE
length
<machine language instructions>
where DOCODE is the address of the code that will run the machine
language instructions, and make sure the RPL pointers are correctly
set. For ROM routines that will only be called
indirectly (see rplman.doc for a discussion on direct/indirect),
this has been simplified to a Primary Code Object or PCO:
CON(5) (*)+5
<machine language instructions>
this means that the object is its own prologue. These are the objects
with the least amount of RPL 'overhead', but can only reside at
fixed addresses. The ROM is full of them.
ACO has further expanded this concept: remark that the pointer need
not necessarily point 5 nibbles further, but can point anywhere.
So you can have a fixed table of 5-nibble addresses pointing to the
code to be executed. If this code changes between ROM versions, it
is much easier to keep the table in place and let the various
instruction blocks float. They have even gone one step beyond:
In fact, there are hundreds of routines pointing to the same address
11111 which now acts as a new 'prologue' that is apparently
recognized by XEQTYPE as a 'program', and that allows to keep
many entry points stable with a minimum of RAM used. (one nibble
per entry instead of 5). Nice trick.
(there's a post somewhere by JYA explaining the trick in more detail)
--
Best Regards,
Werner Huysegoms
Sent via Deja.com http://www.deja.com/
Before you buy.
Wolfgang Rautenberg
> Actually, INNERCOMP has been patched on the HP49 to never generates an
> invalid object or to corrupt memory.
> On the HP48, INNERCOMP can be run only on a composite object.
> While on the HP49, if you run it on something else than a composite object,
> it will return the same object and ONE.
This is a highly important information for SysRPL programmers.
I believe the time has come to write a new and more complete
"Introduction to System RPL" by one of our top experts, e.g.
Werner Huysegoms. I believe that also some ACO members would
like to write something similar, but they are probably too
buisy. There should be a coauthor chosen by the main author
since the danger is too big to make mistakes in such a complex
matter. Clearly, the condition is that ACO provides all
necessary information (like the above one) and I believe
they would support such a project.
> Wolfgang Rautenberg wrote
> > PS. On the HP49 I've seen for the first time
> > objects who contain itself as the single
> > element. The possible existence of such
> > objects was forecasted by Frege and Russell
> > already in 1900 but have never be found in
> > reality untill the year 2000 on the HP49!
> As I've written above, it's not the case, it's just the new behavior of
> INNERCOMP that gives you this impression.
I guessed already something similar because an object O
satisfying the equation O = {O} cannot exist in reality
if equality is taken in the sense of Leibniz - things
are equal if they can mutually replaced by each-other
in every context. In abstract set theory, the existence
of an object O satisfying the above equation cannot be
disproved, however.
Independent on all this, the challenge remains.
- Wolfgang
Werner Huysegoms
> This is a highly important information for SysRPL programmers.
> I believe the time has come to write a new and more complete
> "Introduction to System RPL" by one of our top experts, e.g.
> Werner Huysegoms. I believe that also some ACO members would
> like to write something similar, but they are probably too
> buisy. There should be a coauthor chosen by the main author
> since the danger is too big to make mistakes in such a complex
> matter. Clearly, the condition is that ACO provides all
> necessary information (like the above one) and I believe
> they would support such a project.
>
The areas of SysRPL (or 48/49 in general) of which I know little or
nothing would fill a much larger book than the few things I've been
able to pick up over the years.
I believe it would be a much better thing if Eduardo's already
excellent book would be enlarged by a few chapters..
(and if the errata were included!)