Re: [MiNT] fVDI issues

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

> > I hope we all agree that the current situation is hm... unacceptable
> > in longer terms. I have no clear thoughts about VDI, but for the AES
> > I think that Atari have made a mistake hooking it onto trap #2. Or
> > any trap, to be strict. As a consequence we now have an AES running

Absolutely.

Even for the original ST, the current AES and VDI calling methods made
little sense due to the lack of efficiency. I suppose they made for
easier porting to the 68k, though.
Now with real operating systems on our Atari's (and "compatibles"), we
have another set of problem with the mechanisms.

It's been a while since I last looked at the AES, but the VDI would be
better off with a simple C function call like interface.
Actually, fVDI converts many non-trivial operations to such a format
internally already before jumping to the actual handling functions.
The trivial operations have dual code, one for the standard case, and one
C function call like version. The latter because that's how it would/will be
used under the Fenix OS (and fVDI still stands for Fenix/Free/Fast VDI ;-).

Here is one example (Called from the standard VDI dispatcher, returning
to the original caller. Note that while the most of the paremeters are put
on the stack, a pointer to them is sent in register a0, and the address of
the virtual workstation is in register a0):

	dc.b	0,"vqt_name",0
* vqt_name - Standard Trap function
* Todo:	?
* In:   a1      Parameter block
*       a0      VDI struct
vqt_name:
	uses_d1
	move.l	intin(a1),a2
	move.w	(a2),d0
	move.l	intout(a1),a1
	pea	2(a1)
	move.w	d0,-(a7)
	move.l	a7,a1
	bsr	lib_vqt_name
	addq.l	#2,a7
	move.l	(a7)+,a1
	move.w	d0,-2(a1)
	used_d1
	done_return

In general, the library version of a VDI call such as
vqt_name(handle, number, name) would be called from user code something
like this:
	move.l	name,-(a7)
	move.w	number,-(a7)
	move.l	handle,a0    ; Actual address rather than 16 bit index
	move.l	a7,a1
	jsr	lib_vqt_name
	addq.l	#8,a7

Or, if you wanted to have a trampoline that could take standard C VDI
calls, perhaps with standard indexes (created by the v_opnvwk trampoline,
for example):
vqt_name_trampoline:
	move.w	4(a7),d0            ; Fetch the VDI handle
	move.l	virtuals(pc,d0),a0  ; (Hmm, is that right?)
	lea	6(a7),a1            ; Point to the rest of the arguments
	jmp	lib_vqt_name

> VDI should be a kernel module. The main reason for this is speed.

It would be even faster if only the things that really need to be
in kernel mode actually are.
Mainly that would be hardware accesses (on systems where you need to be
in supervisor mode for that, but if you're going to be using memory
protection, you had better try to enforce that, anyway), but some
operations also need to modify global data.

> The other way could be having both VDI and AES as kernel modules, and 
> AES should call VDI directly (ie. without using traps). I think this 
> is the fastest solution (CPU wise) and also could save some work.

As I mentioned above, fVDI has most of the interface done for such
direct calling.
The original design document also describes how to do 'chained calls',
where several VDI functions can be called with a single jump into the VDI,
by creating a table of arguments.

-- 
  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)