RE: [MiNT] Proposal for SLB extension

["Konrad M. Kokoszkiewicz" <draco@obta.uw.edu.pl>]

> > JR>This can't be used, because there is no variable "basepage" to which
> > JR>the function call handler would have access to.
> > Well as the kernel already has to provide some user code, why not provide
> > some short application "specific" code?
> > Something like this:
> >
> > basepage: dc.l 0
> > local_slbexec:
> >     move.l basepage, d0
> >     jmp global_slbexec
> >
> > With this the variable basepage has to be filled while slb_open() and it's
> > content is automatically passed at each call of an slb function.
> > This will also speed up calls to libraries that need the pointer to the
> > basepage
> 
> Actually, it could be even shorter.
> 
> However it has the drawback that for every process that accesses an SLB, the
> kernel needs to allocate additional memory.
> 
> Konrad?

Exactly, and the smallest block to allocate (with mp) is 8k for my best
knowledge. So doing separate kmalloc() for each application which calls
Slbopen(), to hold one longword, would be pure waste of resources.

Allocating a continuous block of memory to hold all of the possible
basepage addresses for all processes would save more, eventhough this
block would be half free all the time. And still, such a table would have
been indexed by pid, which still means one GEMDOS trap per library call
(i.e. to Pgeteiud()).

I don't think this is worth the efforts (and possible waste). Defining the
lowest bit of flags so that the library gets 0 instead of the basepage
address is IMHO the best compromise. I.e. one saves the overhead (no trap
is necessary) not increasing the use of other resources (no additional
memory is necessary).

Also, I disagree with the argument that this creates two different types
of libs. Sure it does, but that's not any problem for an application that
is gonna use one, since the application sees no difference between these
'types'. It just calls a function, exactly the same way for 'normal' SLB
and such one with the flags set. This is the library itself which can see
the difference, but since flags are defined in the SLB header, they are
set appropriately at the SLB compile time. So, if an author thinks it does
not need the basepage address as a parameter, the SLB can be setup this
way for faster responsivity. If a lib requires basepage address for each
function (quite unlikely), it can leave flags = 0 and this still will
work as it did before.

In other words, I can't see why applications could have problems with
that, as long as the flags in the SLB header are setup according to the
real library's requirements.

--
Konrad M.Kokoszkiewicz
mail: draco@atari.org
http://draco.atari.org

** Ea natura multitudinis est,
** aut servit humiliter, aut superbe dominatur (Liv. XXIV,25)
*************************************************************
** Taka to juz natura pospolstwa, ze albo sluzy ono unizenie,
** albo bezczelnie sie panoszy.