🚀 go-pugleaf

In article <JSP.90Nov19154628@glia.biostr.washington.edu> jsp@glia.biostr.washington.edu (Jeff Prothero) writes:
>Why are the xlftab.c:funtab[] entries so carefully numbered?

For function calls, the funtab index is necessary, but there are other ways
of doing it -- xlisp/xlinit.c:initwks() just calls:

|     /* install the built-in functions and special forms */
|     for (i = 0, p = funtab; p->fd_subr != NULL; ++i, ++p)
| 	if (p->fd_name)
| 	    xlsubr(p->fd_name,p->fd_type,p->fd_subr,i);
| 

which sets up a subr node, with a name, FSUBR/SUBR kind, function pointer,
and offset (index into funtab) for each entry in funtab. A brief peruse of
the code shows that xlisp/xlprin.c:putsubr() and
xlisp/xlimage.c:xlirestore() are the only things that access the index into
funtab. The former is used to get the name of the function, and the latter
is used to retrieve the C function pointer assocd w/ a subr node from
funtab...

#ifdef ADVERTIZING_MODE_ON
   FYI, for perusing XLISP/WINTERP/MOTIF sources, I strongly encourage the
   use of powerful static analysis tools. AT&T's software toolchest has
   something called CSCOPE, and HP has a whizzy X11/Motif-Look-And-Feel
   programming environment (for C C++, Common Lisp, etc) called SOFTBENCH
   with a very nice static analysis tool... Much more useful than grep
   for answering questions like "list every use of this identifier", "show
   me the definition of this identifier", etc. Ask your friendly HP Sales
   rep for details.
#endif

Getting back to the point... Methods are added via xladdmsg(), which
requires the index into the function table rather than a function pointer
or somesuch.

Example: in xlisp/xlobj.c:
|     xladdmsg(class,":NEW",FT_CLNEW);
|     xladdmsg(class,":ISNEW",FT_CLISNEW);
|     xladdmsg(class,":ANSWER",FT_CLANSWER);
|     xladdmsg(object,":ISNEW",FT_OBISNEW);
|     xladdmsg(object,":CLASS",FT_OBCLASS);
|     xladdmsg(object,":SHOW",FT_OBSHOW);

Where FT_* are defined in xlisp/xlisp.h:
| /* function table offsets for the initialization functions */
| #define FT_RMHASH	0
| #define FT_RMQUOTE	1
| #define FT_RMDQUOTE	2
| #define FT_RMBQUOTE	3
| #define FT_RMCOMMA	4
| #define FT_RMLPAR	5
| #define FT_RMRPAR	6
| #define FT_RMSEMI	7
| /* #define xxxxxx       8 */
| /* #define yyyyyy       9 */
| #define FT_CLNEW	10
| #define FT_CLISNEW	11
| #define FT_CLANSWER	12
| #define FT_OBISNEW	13
| #define FT_OBCLASS	14
| #define FT_OBSHOW	15


And xlisp/xlftab.c contains corresponding:
|     xladdmsg(class,":NEW",FT_CLNEW);
|     xladdmsg(class,":ISNEW",FT_CLISNEW);
|     xladdmsg(class,":ANSWER",FT_CLANSWER);
| 
|     /* finish initializing 'object' */
|     setivar(object,SUPERCLASS,NIL);
|     xladdmsg(object,":ISNEW",FT_OBISNEW);
|     xladdmsg(object,":CLASS",FT_OBCLASS);
|     xladdmsg(object,":SHOW",FT_OBSHOW);


>What is going to break if the numbering is changed?  Primarily the
>image save/restore stuff?  

The main reason is because you have to make sure that the number of an
entry into funtab[] corresponds to the number in the #define FT_* in
xlisp.h. If these get out of sync, then you end up calling the wrong method
associated with a message, which isn't Good.

If you restore into a system in which funtab[]'s entries are differently
numbered, you'll pick up the wrong C function call...

Since I added HUNDREDS of methods to implement WINTERP, I had to worry
about funtab numbering alot. I didn't want to change XLISP extensively,
because then it wouldn't be the same old standard xlisp that we're all used
to (and patching it for updates would become harder).  To avoid explicitly
renumbering things, I did the ugly hack visible in src-server/w_funtab.c
src-server/w_funtab.h (do not look at these after eating lest you want to
lose your lunch). This hack/technique is also known as "C preprocessor
abuse"....

>
>Why can't/shouldn't those things which will break key off the function
>names instead of the table offsets?
>

Note that 'union ninfo' is a 2 element union. If you wanted to put the
name, C fn ptr, SUBR/FSUBR info into the union, all value nodes would take
up an extra 4 bytes. By keeping the static information in a table to be
looked up when needed, and only keeping the C fn ptr and index in the value
node, value nodes are kept small, and yet function calls don't require
extra indirection.

Your solution of keying off the function names sounds like it would require
extra indirection, even with hashing.

Other solutions and tradeoffs are obviously possible. The one we're
discussing happens to be the way David Betz decided to do it.

>Why are extra slots reserved at the end of funtab[]?
>

So you can add more functions easily.

>What's the point of image save/restore? 

Faster startup times.

>Should saved images be
>portable between machines or versions?

I don't think that's possible if different machines/versions have different
primitives. You could define indexes 0 thru N to be common/shared
functions, and have restore retrieve xnotdef() for all others.

>
>Would it be hard/pointless to write code to convert the xlisp
>state into initialized C header files, so that the xlisp state
>could be portably compiled into an application?

???

Perhaps you'd be better off looking at what gnuemacs and (I think) KCL do
w/r/t dumping (akin to core dumping) an executable image and then
"undumping" it to restore the executable and memory image created by
loading and initializing files.

Undumping is very nice when it works, but can create massive headaches when
it doesn't. In the case of gnuemacs, these undumped images cannot be
debugged with the manufacturer's supplied debugging tools. You could
compile with gcc and debug with gdb. However, for HPUX HP's product
compilers supposedly produce better/faster code.

>{...YOYOYOY...:-}

Indeed!

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *