Re: [MiNT] fVDI issues

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

> > I hope you'll talk to those of us who are involved in writing VDIs and
> > AESes before deciding on something overly general?
> 
> I don't have a concrete implementation in mind yet but performance is for
> sure one goal :-)

I'm very happy to hear that.

Perhaps it would be a good idea if the VDI and AES developers talked
a bit about what we want/need from this kind of functionality in MiNT?
And, of course, it would be good if the MiNT kernel developers could
describe what thoughts they have about this kind of interface.

> > For example, something like vsl_color is about a dozen instructions
> > of actual work in fVDI. Even with a minimal VDI dispatcher, there are
> > already two dozen instructions of 'overhead' on top of that (saving
> > only two registers on the stack).
> 
> Entering the kernel is an expensive operation, also for routines that just
> consist of one line (getpid and these things).

I'm well aware of that, and have complained about it before.  ;-)

So, at least for the VDI, fully entering the kernel (build_context etc)
is not really an option, IMHO. At least not unless deemed necessary
after return from the VDI code (for example if the time slice is up).
It doesn't really matter if getpid() takes a long time, since it's not
called often. And the same applies to most (all?) of GEMDOS/BIOS/XBIOS,
and probably the AES.
VDI usage can be quite different, though, with sometimes thousands of
calls per second.

Many often called VDI routines can make do with only a couple of
registers saved on the stack. None of them pass any parameters on the
stack. None of them, AFAICR, would have any reason to ever require a
process to suspend.

Does MiNT currently do anything about pointers passed to system calls
under memory protection, by the way? Or will for example an Fread to
memory not owned by the calling process succeed?
The VDI (and the AES) passes a bunch of pointers around for every single
call, and then there are things like the MFDBs.

Actually, it would make sense to make parts of the VDI actually execute
in user mode. It's unfortunate that we're stuck with the Trap #2.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |
                        | so hard to do |  WWW:      http://www.klockars.net
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)