From: mheiskan@hut.fi (Mika Heiskanen)
Subject: Re: XLIB headers???
Reply-To: mheiskan@.vipunen.hut.fi
Organization: Helsinki University of Technology - Finland
Date: 20 Aug 92 03:37:29


After some more hacking here's some more info I've found out about the
headers. Please post if you have any additional info about these. I intend
to use most of the features described below.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The XLIBs in libraries are arranged as follows:

header XLIB-program object/pointer obj/pntr ...

The header:
~~~~~~~~~~~
The header is always 1 or 3 nibbles long. If flag xx8 is set, the header is
only one nibble long. This is used mainly to save 2 nibbles/XLIB.
Each flag set, except 008, also has a corresponding object after the XLIB.

Here's a list of all the flags, and the purpose of the corresponding object:

008:          @ 1-nibble marker. (This one causes no object after the XLIB.)
004: eqwr     @ Equation writer routine
002: speval.1 @ Same as 200 ??? Used if 008 flag is set ???
001: hex      @ A binary integer specifying an unusual display format
080: der      @ Derivation routine
040: rinv     @ Inversion routine (Used by ISOL)
020: make     @ An algebraic maker for routines having unusual arguments
010: spapply  @ ?? Used atleast by EXPAN to hinder APPLY command
800: rules    @ RULES menu (There are several different ones in memory.)
400: intg     @ Pattern matching for integration
200: speval   @ Used to go from stack args to algebraics?
100: repl     @ Used when exploding/imploding algebraics

Objects/pointers:
~~~~~~~~~~~~~~~~~
The above flags are used by various programs to indicate special display or
a special method for some operation. For instance, almost all the work of
ISOL is done by recalling the inversion routine stored after each XLIB
(which in turn call the next one).

The order of these objects is:
(header XLIB) eqwr speval.1 hex der rinv make spapply rules intg speval repl

Each of these 'objects' can be:
- a 'real', prologed object
- a system binary
- a pointer to some object (system binary too)

If the (pointed) object is a system binary, RclData (#C612) is used to
fetch the data at the address pointed by the system binary. RclData fetches
the data from hidden ROM, if the address is in the range 70000-7FFFF.

Here are some examples from ROM:

080               @ Derivation routine exists
:: PI program ;   @ The main program for PI
r_DROP%0          @ Pointer to DROP%0 (derivation of constants!)

CC0 :: SIN ;
rr_DERSIN         @ Pointer to a # that points to DERSIN in hidden ROM
rr_RINVSIN        @ .............. inversion routine .................
rr_RULESmenu9     @ ..........9th RULESmenu in the hidden ROM (has ->DEF etc)
r_INTGSIN         @ # that points to pattern matching in hidden ROM

One with the actual memory contents: (addresses inverted)
8C5 :: + ;
6BA97             @ 6BA97: EQWR+-* (Same routine for +,- and *)
02A4E 0000A 70107 @ Binary integer to specify priority and display format
56B91             @ 56B91: #7BAC0    @ 7BAC0: DER+ 
57455             @ 57455: #7B5F2    @ 7B5F2: RINV+
3F103             @ 3F103: #7DBBF    @ 7DBBF: RULESmenu1

If the 008 flag is set, there other flags can still be set. Examples:
A: speval.1 follows       @ Used by rpnXROOT (control passed to XROOT)
E: eqwr and speval follow @ Used by rpnDER, rpnINTG, rpn|

I have named all these references in entries4 file, which I will post
probably tonight to seq.uncwil.edu. (It has lots of other new entries too)

The 'hex' object
~~~~~~~~~~~~~~~~
The flag xx1 set means that there is a special display format for the XLIB.
The format is specified by the hex object after the XLIB.

If the flag is cleared, the XLIB in question will be assinged by the
fetching routines a hex integer according to it argument count as follows:
(By checking for CK<n>&Dispatch and similar structures.)

1 arg : 014050		@ X(a)
2 args: 01406050	@ X(a,b)
3 args: 0140606050      @ X(a,b,c)
4 args: 014060606050	@ X(a,b,c,d)
5 args: 01406060606050  @ X(a,b,c,d,e)
N args: 0140950		@ X(a,.....)   (Atleast one)
(The stack displays these binaries in reversed order)

By comparing these with some of the ones having special display formats it
is easy to see that each nibble has a meaning:

0 = argument    (a) @ Also serves as end mark?
1 = XLIB name   (N) @ The XLIB name will be put in that place
2 = argument    (s) @ The only difference I can think between 0 and 2 is
                    @ execution priority. Seems that 0 should be EVALed first
3 = global name (i) @ Only global name is accepted in this place by the parser
4 = "("             @ Left parentheses..
5 = ")"
6 = ","
7 = "="
9 = infarg repeater @ Repeats ",arg,arg...."
B = i=a repeater    @ Repeats ",id=arg,id=arg..."

Also the first/last nibble may mean algebraic priority depending on
argument counts. The ones causing me trouble are:

8 = ???? used by NEG to correct +/- ????
A = ????
C = ???? Special priority. See text later. ????

Some examples now:

90109: (^)
80108: *,MOD,(/)
70107: +,-
60106: ==,<>,<,>,<=,>=
50105: AND
40104: OR,XOR
00700: =                 (This one doesn't use XLIB_NAME since 7 is usable)

Those are clearly: (Priority arg XLIB_NAME arg Priority)
The reason why / and ^ are in parentheses is that they have another form
too. Here's the 'hex' object pointed to by /: (1AFE1) 

  :: Tst_7068D:1 hex_8014050 hex_80108 RPITE ;

Thus there are forms a/(b) and a/b. I don't know what the test is about
though. Similar tests are done by ^ and SQRT (NOT by +,-,*...).

Now some more complicated ones:

         P der id ( s ) end
DER    : 0 1   3  4 2 5 0

INTG   : 014060626350    @ INTEGRATE(a,a,s,id)
SUM    : 014370606250    @ SUM(id=a,a,s)
|      : 2214370B50      @ s|(id=a,.....)  B repeats ",id=a" ie 370
QUOTE  : 014250          @ QUOTE(s)
APPLY  : 014360950       @ APPLY(id,a,....) 9 repeats ",a" ie 60

!      : A010            @ a!     (Highest priority (A))
NOT    : 0105            @ NOT a  (5 is priority)
NEG    : 0108            @ 
SQRT   : 010C            @ C as priority seems weird, so it might have some
                         @ hidden meanings too

See the difference for ! and the rest?


repl flag
~~~~~~~~~
The repl flag is used by functions that take arguments in unusual ways.
The corresponding object is a list of programs/pntrs for
exploding/imploding and argument count checking:
{ imploder   @ Example: Der does   ID&Meta -> ALG_ID ALG(Meta)
  counter    @ Example: | uses DROPeven#? to check ID&arg pairs
                        INTEGRATE uses #4=
  exploder   @ Used by OBJ-> to get the exploded 'user' version
}
Some XLIBs have only the first 2 objects in the list.


What comes to the other objects, I'm still hacking.

Unsupported entries
~~~~~~~~~~~~~~~~~~~
These entry points are not supported, so they may work in rev E only.
The names are from entries4 file.

26B40 = CmdFlagSet? @ If bit xx8 is set then True (XLIB is a command)
                    @ seco -> seco TRUE/FALSE
26B73 = rpnSpEval?  @ Used to get the evaluation prg for args???
                    @ seco -> seco FALSE / seco' TRUE
26C47 = SpDispArgs? @ Gets argument count and the display hex
                    @ seco -> seco hex #args/#FFFFF TRUE  / seco FALSE
26F0D = DerDataGet  @ seco -> seco data TRUE / seco FALSE (same for the rest)
26F1B = RinvDataGet
26F37 = SpAppDataGet
26F45 = RulesDataGet
26F53 = IntgDataGet
26F61 = SpEvalDataGet
26F6F = ReplDataGet


That's about it. If you use these flags, then be careful. Lots of internal
programs use them, so make sure what you'll get and what you should put
back to the stack. I reckon the hex display number is the best place to
start experimenting with.

Currently atleast MAKEROM with RPLCOMP and STAR can be used to create
libraries using these flags. I'm sure Detlef will also come up with
something for the <-LIB-> library :)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
--> mheiskan@vipunen.hut.fi
From: stevewi@hpspdla.spd.HP.COM (Steve Witten)
Date: Wed, 19 Aug 1992 23:10:45 GMT
Subject: Re: Downloading PC-Hp48
Organization: HP Stanford Park - Palo Alto, CA