Re: [MiNT] DATE/TIME cookies

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

> > > And why do I use DATE/TIME cookies instead of hooking on traps? It's
> > > simply easier to write, faster to execute (called once per second, not
> > > 200x as you thought for unknown reason), requires less code and does not
> > 
> > Um - There *is* no interrupt that is called once per second. What interrupt
> > do you hook into to update your time display?
> 
> VBL. Does it make any difference when it comes to including DATE/TIME
> cookies into FreeMiNT?

What the other poster failed to realize is that you don't call DATE/TIME
on every single interrupt, but rather every 100th or so.

Anyway, since the whole problem would go away if it was OK to call _some_
OS functions from an interrupt, and it would be very good in general to
cut down on the _immense_ system call penalty under MiNT, why don't we
try to do something about that?


For something as simple as gettime(), there should be no reentrancy or
interrupt call problem at all (no global data is modified), so it's 'only'
necessary to get rid of the MiNT 'baggage'.
IIRC, MiNT saves the process state, copies stack parameters to an internal
system stack, etc on almost every single OS call. IMO, this should only be
done when it's absolutely necessary.

getttime() should have no trouble running on whatever the supervisor stack
became when the Trap occurred (regardless of whether the process was
running in supervisor mode already or if it was an interrupt routine that
made the call).

Most system calls are perhaps not all that time critical, but the slow
calls are a problem when you're trying to do lots of inter-process
communication like in XaAES, for example.

If a process must block it's of course necessary to save state information,
but then don't do it until it's clear that a block is actually inevitable.
Using a special system stack may be necessary to be able to call device
drivers (you don't want them to crash an application just because it,
running in supervisor mode, tried to read a file and had a too small stack),
but many functions should be able to do their work using relatively little
space.
Even if you do have to use a new stack, there's really no need to copy all
parameters (MiNT currently always copies the maximum amount possible). You
could just send along a pointer instead.
Using a table with an entry per function (as Trapatch does) it's very
simple to direct all calls to an appropriate handler, which may or may not
do an 'expansive' OS entry.

Well, I think I'd better take a look at the MiNT internals again before
I get too deeply into this.


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