Re: STiNG, CAB, and Multitasking (strikes back)

[Konrad Kokoszkiewicz <draco@piwo.bl.pg.gda.pl>]

> > > Well, if this particular fix doesn't have any negative effects I can't
> > > see any reasons not to do it. But it's also a matter of time and
> > > resources, there are a lot of other things in MiNT that's more urgent
> > > to fix.
> > 
> > I have offered to Konrad in my first posting that I'd write up the code
> > and you only need to insert it into the MiNT code where necessary.
> 
> I'm all for it if it...
> 
> a) ...actually works and doesn't affect stability.
> b) ...doesn't affect performance negatively.
> c) ...doesn't introduce any security-problems.

I personally doubt if it could affect performance. And really, MiNT uses
XBRA for hooking into system vectors, but the problem with STiNG is that
STiNG needs to install own privilege violation handler. When the STiNG is
loaded before MiNT, then STiNGs handler gets patched by MiNT and from now
the whole thing causes a real, fully featured privilege violation
exception, with MiNT's attempt to kill STiNG etc. That's what I
understood.

The question is stability and security. Though I really doubt (sorry
Peter) if anybody could consider leaving the computer alone on the
network, running as a host without a superintendence, using STiNG and
STiNG software for this purpose, because we have MiNT-Net for it with all
the Unix environment which is reasonably hacker-proof and stable enough.

Peter's proposal is that MiNT would install its handlers at the end of
XBRA chain, not at the begin, as it does now. At the end, i.e. just after
TOS. This applies at least to the privilege violation exception vector,
and now go my questions:

- if we agree that the privilege violation exception vector should be
installed as Peter says, should MiNT install ALL its vectors the same way?

- if all MiNT vectors would be installed at the end of XBRA chain,
wouldn't it have the same effect as loading MiNT as the first program in
the AUTO folder?

- therefore, wouldn't it cause a lot of compatibility problems as we
  have now with programs, those can't be installed after MiNT (HSMODEM for
  example), because position of MiNT in the AUTO wouldn't matter anymore
  being virtually the very first one?

- at the other hand, if we agree that this fix applies only to the
privilege violation handler, how to substantiate the inconsistency with
other vectors?

Now, the other question is what the STiNG needs the privilege violation
exception vector for. As I understood from Peter's mails and referred it
once here, STiNG uses this vector to switch from user to supervisor mode.
OK, I can agree on everything Peter says, but I can't agree that using
or #0,sr and own exception handler is a _LEGAL_ way to switch the code to
supervisor mode (out of the control of the kernel, but that's another
question - i hope STiNG won't be used in multiuser setups). Peter claims
using Atari-approved programming methods as legal - so at this point I
don't think it is legal.

In other words, the question is not whether MiNT uses XBRA legally or not,
but if STiNG legally uses the exception vector. This time I would like,
that you Peter would consider a rewrite in your code to avoid using
privileged instructions in your code. Or at least group them in a
subroutine or something.

This reminds me my problem with the code of my XL emulator for Falcon. One
time it seemed to me that i need to use self-modifying code on 68030 to
get the maximum possible performance and I didn't believe that it could be
avoided. Of course this needed cache flushes and caused all sort of
problems whit Emu running on Petr's Stehlik Afterburner040. However Petr
Stehlik kept convincing me that this solution is dirty and finally forced
me to search for another solution. That I finally have found - now hte
Emu's code doesn't modify itself, there are no more cache flushes, it runs
smoothly on any processor from 020 to 040 (and I believe it will run on
060 as well) and the performance is even better than before.

As for speed.... let's look to timing tables. I easily believe, that
Supexec() is slower than Peter's solution, though I don't know details of
his handler. But I think using an unassigned trap (if a rewrite is
_really_ impossible what I hardly believe) would be at least the same, but
a lot of less dirty. According to the "68030 enhanced 32-bit
microprocessor user's manual" (Motorola), a trap takes 18 upto 20 cycles,
while an OR #0,SR plus privilege violation takes 30 upto 34 cycles (12-14
for OR #nn,SR and 18-20 for taken exception). 

Being back to the question of XBRA chain, I think, that the current MiNT
behaviour is probably not perfect, but the best in current circumstances. 
Yes, MiNT installs its handlers arbitrarily at the begin of the chain, but
it is at least user-tunable by the AUTO folder sorting (yes, this has also
some advantages!). If MiNT would install its vectors always just after
TOS, we couldn't tune anything by resorting the AUTO folder.

Gtx,

Konrad M.Kokoszkiewicz
mail:draco@bl.pg.gda.pl
http://www.orient.uw.edu.pl/~conradus/

** Quem Iuppiter vult perdere, dementat prius.
*******************************************************
** Kogo Jowisz chce zgubic, temu wpierw rozum odbiera.