Re: [MiNT] XaAES / GEM memory issues

[Sven Karlsson <svenka@it.kth.se>]

Hi again,

> > Reading and filling out the parameterblock is still a problem.

Why? The user level portion could easily access and update the parameter
block and all other data structures in the calling AES. You can simply
send or receive the relevant fields from some central manager. Am I
missing something here?

Mind you the trap handler is essentially in user space as you don't ever
have to change _any_ MMU mapping or address space at all. 
	
Of course this means that the user level AES library must be in the the
calling process adressspace but that can be arranged with a proper
implementation even with the MiNT of today.

After the trap instruction you will of course end up in supervisor mode
which is not good either but that is trivially solved.

> that the traditional concept should be just thrown out to the trashcan,
> and we start with something else; according to Vincent, oAESis guys

I should say that a XaAES actually had a user level/kernel level
decomposistion from start.

Konrad, I think you are believing we are talking about a AES where most
of the work is done in kernel mode. We are not. At least I'm not. The
only thing in kernel is the very small part that keeps track on where
the windows are and handle the events. In practice, _all_ AES functions
are handled by the user level part within the calling process address
space execpt when the user level part needs some information from the
kernel part. This happens when some window is moved by the application,
when the application request permission to access the screen, or when
the application is waitin for events. Mind you, the user level part can
actually redraw the window titles and window borders and manage all
items in the window border, i.e., the scrollbars, and all icons, all by
itself.

If you look under the hood XaAES actually did this from the start IIRC.
It had several processes connected via pipes where the central process
that did very little but event and rectangle. That part could very well
be put in kernel mode as for instance a device driver. However the XaAES
implementation using pipes were way too slow.

I'll explain. The ACIA runs at 7812.5 baud. Each mouse packet is 3 bytes
and the keyboard processor keeps sending mouse packets whenever the
mouse is moved, i.e., you will get up to 325 packets per second if you
keeps moving the mouse as you usually do in a graphics application.
Clearly this is too much to be broadcast to applications. You will need
some kind of filtering. If you simply process the packets and send the
coordinates at given time intervals you will end up in a situation where
some applications gets events more seldomly than they need or too often.
Both will make you think the system is sluggish.
PS/2 and serial mouses produce information in more or less the same
number of packets per second as the keyboard processor.

Clearly you need some kind of intelligent filtering. However, doing this
outside the kernel or rather outside the interrupt handler or device
driver would yield too much overhead. Switching back and forth between
processes at a rate of over 300 context switches per second is quite a
lot especially if you change the MMU mapping and flush the caches!
Synchronization and context switches are always a performance bottleneck
when considering events at this rate.

When I get the time I'll make a simple mock-up with source code so
everyone can actually see exactly what I mean. However, beginning on
monday I'll be lecturing nearly 300 students and I must prepare the
lectures.

Best regards
 Sven