Re: [MiNT] Userdefs & MP

[Johan Klockars <rand@cd.chalmers.se>]

> [.. Fenix AES .. ]
> 
> Sounds very promising. Are these SLB's running as I described? In the APP's
> address space?

Since Fenix shared libraries are called using jsr's they'll of course
have to be in an address space accessible to the application. I don't
recall if they were supposed to be added to the local address space at
instantiation or if they are in a globally accessible space.

Speaking of address spaces, I don't see why there should be a problem
having a global virtual space. That way you'd have a logical 4 Gbyte space
where you could group together free physical blocks of memory, which should
help a lot with fragmentation even if it wouldn't be quite as good as
separate address spaces. It should be possible to restrict the actual
use of that large address space to the size of physical memory or swap.

> > This is a very neat way of doing it, but it will ofcourse not solve the
> > problem with other AESes...
> 
> Yep. And it proves that without a own free AES logical address spaces is very
> hard to do, if at all possible.

I don't quite see the problem here, I must say, but I might be forgetting
about something.
Due to the normal calling conventions used, any AES or VDI must have access
to the memory of the caller. Is there really any AES/VDI library that
allocates the control blocks and intin, intout etc, in globally accessible
memory? Loaded resource files is another thing that has similar problems.

Since the AES and VDI must be able to address those areas, there should be
no difference for user defined objects, right?
I'm not saying that this is a good idea in the first place, but that's
how it's currently done.

> XaAes should be a candidate.

Parts of XaAES does run as a separate process, which would require access
to the address space of another application if for example parameters were
to be fetched.
Usually, 'thanks' to the incredibly slow interprocess comunication in MiNT,
XaAES is run using something called 'direct calls', however, which doesn't
require any context switch. There's of course a Trap at the actual call,
but that only puts you in supervisor mode. So, XaAES itself needs to be
in globally accessible space, but will then run in the context of the
callee for most operations.
A userdef in the menu would cause problems since that is handled by the
XaAES process, but I don't think that's very common compared to userdefs
in dialogs, which are drawn using objc_draw from the application in question.

If we are to remain compatible with current programs, it doesn't matter
if there are userdefs or not. There are many other things that just won't
work, AFAICS, with separate address spaces.

It's just too bad that the object structures were documented. If there had
been no way to access them without going through the AES it might have been
possible to deal with this. There are similar problems with the VDI, where
it's very difficult (if at all possible, and then often with some risk of
erroneous behaviour) to make good use of modern graphics hardware.
I know some of you think the Windows way of handling these kinds of things
is silly, but from what I've seen of it so far (haven't done much Windows
programming yet) it actually seems to deal with these problems...

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)