From: gt8134b@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.sys.hp48
Subject: Shared library proposal - ideas
Date: 16 Oct 92 15:01:54 GMT
Organization: Georgia Institute of Technology


   Several people have been kind enough to respond to my request for ideas
so far.  I'm really pleased with the kind of input I'm getting, especially
since my proposal is such an abstract thing right now. 

   Since most of my responses have been mailed, I will repost my responses
to them here so that everyone may get a good idea of what's going on.

   I'm all ears now, so post!


Here's one from Joe Ervin (others to follow):

====================================================================
ervin@pinbot.enet.dec.com (Joe Ervin) writes:

[Joe]
> I can think of a few ML routines that would be nice to have in 
> a callable form.  One of them is a sprite drawer that I use
> in Vaders, and which will also be used in a upcoming game that

[me]
   Sure.  I plan on including a full display package (not just text).
How generalized is your routine?  I mean, is it just a BitBlt, or more
specific?  Something like the Amiga's autonomous (self-updating) sprites might
be overkill...I have the source for Vaders around somewhere, maybe
I should look at it.

[R:  He later replied that the sprite drawer was NOT a blitter, but
     a more intelligent routine that draws a sprite from a series
     of 1-pixel wide line commands and in specified modes (set, clear,
     and that most useful of all for spritely things: XOR)             ]

> There are probably other things as well.  Have you figured out how to
> call library routines from within an ML program?  Sounds non-trivial
> to me.

That was the very first thing I thought of.  It actually is the very
origin of the idea -- "I need a library of ML-callable routines."
The rest just spun off.  Non-trivially, to be sure.
   I didn't go into great detail in my proposal on purpose...I need to
keep the ideas fluid right now.  I'm sure I'll get many important
suggestions that I'll need to consider first.

The general idea is that your program will need some startup code
upon entering ML.  This would grab the library jump table base address
and save whatever routine addresses you need in a local table.  The
global jump table will be XLIB xxx 000 in the library, guaranteed.
Whenever you jump to a routine in the library, you'll grab the address
from the local table into register C.  Then you'll execute CPCEX, effectively
GOSUBbing to the appropriate routine, which only has to push C onto
the stack to make it possible to terminate with a normal RTN.
Fairly simple, I think, and not too much overhead.

Most of this will be implemented as a macro package, so you'll define
DRAWSPRITE as SHFUNC(1) or something, corresponding to entry number one
in your LOCAL jump table...of course, I could make macros that bypass
the local jump table, and you'd give the entry number as offsets
into the global (library-resident) jump table.  This is all to be decided,
so please contribute! 

> I'm not sure if the routine will run from ROM in it's current form, 
> since there is at least one RAM-based variable that it uses.

That's a good point.  I need to implement some sort of resource allocation
for such routines (at least sometime in the future...). In the meantime,
however, some of the routines may need some doctoring.  Perhaps they
might require that the calling program pass some pointer to a given
size data space in a register...saving overhead between calls and 
providing static data (i'm sure a sprite routine would need variable
that persist between calls.)
  Ah, if I don't watch out, I'll pe porting *NIX to the HP48.  :-)

> Also, Jan Brittenson is the original author of this routine, so he should
> be consulted.

I should consult him, anyway.  I'm sure he'll be a great help.
Without MLDL and STAR I never could have gotten this far.
By the way, the SHLIB programming package will support STAR as well
as the HP tools.

> Some other routines would be nice, like a routine to clear the display, or
> clear a specified region of the display.  There are lots of other routines
  ^^^^^^^^^^^^^^      already planned!  
> that I can think of, but I'll have to get back to you on those.  I'm really
> busy these days with work and my Japanese classes in the evening, so I
> don't have nearly as much time for my HP48 ventures as I'd like.

I understand. I'm STILL learning to play guitar (after 3 years of trying),
trying to develop my meager literary talents, learning about UNIX, C++,
FORTH, PERL, and in my spare time pursuing a degree.

> Take care, and please keep me informed as to the progress of your project.
> 
> It sounds like an interesting idea.  The only concern I have is that 
> this type of thing has a lot of inertia, and takes a really strong effort
> to make it "standard".  In other words, until developers (like myself) 
> have reason to believe that people will already have the shared library
> installed, it's hard to justify using the routines it contains rather than
> just coding them into the application.  Also, I'll be really curious to see
> just _how_ one calls these routines, and how much different is it than calling
> a local routine.
The difference will be invisible at the source level (at least unobtrusive).
 like this:
         call.a   BitBlt       ; transforms into
         libcall  BitBlt
or some such thing.  I might even implement some options in the calling
macro to save specified registers in a local space...like 
        libcall   BitBlt,b,d

On the real level, the macro will load the local table address that the
startup code saved (in some temp location), add the constant
offset into it, read THAT address, and do the CPCEX trick described 
above.  Not so bad, really.  
  On the other hand, every program  could have one subroutine that it calls
to call the library routine.  This subroutine would perform the calculation
described above, but not the CPCEX trick, as the return address would
already be on the stack!  This is probably better.  I'll have to start
counting nibbles and clock cycles.

You've hit the bullseye about inertia.  I will keep the newsgroup updated,
posting suggestions others have sent me as well as my own.  Such exposure
will at least make the idea familiar, if not tiresome :-).  As for
justifying using the routines, I plan to make the library memory overhead
as slim as I can, so a developer can distribute a SHLIB-ready application
(or game! etc.) with a version of SHLIB that contains ONLY the routines
the program needs. Either way, the user benefits:
     1) if he doesn't already have SHLIB48, he gets the program to work
        anyway at almost no overhead (with tight coding and a good design,
        I'm praying for <1K).
     2) If he uses more than one SHLIB48 program, he can combine the 
        necessary routines into a single SHLIB that has EXACTLY THE SAME
        OVERHEAD!  This stil gives him a net gain (almost assuredly) as
        the overhead for any fair-sized program should be far less than
        the cost of redundant code.

Your SOUNDER is a good example.  Your programs all call SOUNDER; if it's
not already there, the user gets a copy to install.  If it is, programs
share it.  You can't lose!

As for standardization, I'll just have to draft some sort of policy.
I'm sure users don't want the fate of ALL their programs in the hands
of one college student and his whims.  Hmmm... I'm not sure whims have
hands. Anyway, you know what I mean.

Can I post this response to the newsgroup so that people can see
the sort of dialogue going on?  I'm asking all those who wrote me this,
as their contribution should be recognized...

Thank you so much for your response!  It means a lot to me.
> 
> >>>Joe

Regards,
Robert

======================================================================

I've further refined the procedure for calling the routines in the
jump table, so look for that post later!

Robert

-- 
Howlin' Bob
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt8134b@prism.gatech.edu