Re: [MiNT] Shutdown() discussion

[Odd Skancke <ozk@atari.org>]

On Thu, 11 Dec 2003, Xavier Joubert wrote:

> Hello !
>
> Selon Konrad Kokoszkiewicz <draco@obta.uw.edu.pl>:
> > Great. But - what for? How many user programs will have to shutdown the
> > system? It will be one, and you request MiNT to allocate yet another 8k of
> > RAM to keep NF in it for EACH application? For your information, a single
> > program, except its own TEXT/DATA/BSS and stack, takes about 16k for process
> > structure, at least 8k for environment, and 8k for the trampoline, and God
> > knows what else I forgot. 8k is the pagesize. Yet one page now for NF?
>
> Mmmm... We could as well allocate space for the private cookie jar and the
> private natfeat structure at the same time. Even if the natfeat structure would
> eat 2 ko, this would still allow space for 767 cookies (6 ko / 8 byte for each
> cookie, minus one to mark the end) with 8 ko. That's more than any system would
> ever need (Who needs more that 640 ko, anyway ? ;) ).
>
> Seriously, when we will need that much cookies, we won't care about allocating
> 8 more ko per process, as our systems will offer some gigabytes of ram.

 This attitude is dangerous. Dont think like that just because you have a
beast of a PC to run ARAnyM on. There are cleaners ways of adding support
for different things.

>
> I don't mean I want to implement this. Read below.
>
> > You need speed? How move.w #xxxx,$yyyy.w is slower than an illegal
> > instruction or a JSR?
>
> Because this means doing a check for every RAM access.
>
> For now, ARAnyM emulate hardware chips so we have to do this anyway. But well
> conceived virtual systems just replace this by native calls to allow a huge
> acceleration of processing.

 What chips does ARAnyM emulate? With FreeMiNT and a decent set of
XDD/XIFs, the only thing ARAnyM needs to emulate would be the 68k itself.
Other hardware (serial, parallel, mouse, kbd etc, etc,) should have
drivers (XDD drivers). This is ofcourse, seen from the FreeMiNTs point of
view, which is what I'm taken by right now. Ofcourse some applications go
to hardware directly, which needs emulation. Point is, FreeMiNT should not
be made to use hardware (or any other devices) directly, but via XDDs.

>
> We could, in the future, imagine dropping any hardware emulation from aranym
> and use everything through natfeat.

 Via natfeat via XDD.

>
> Again, this is theorical. Please read below for something more real.
>
> > I still remember a bit of the discuss on the Aranym list at the begin of
> > this year. You (I mean the list members who participated in the discussion)
> > sorta agreed, that the current solution is misconcepted and something must
> > be done with it. The discuss has ended then and you did nothing about it.
>
> I agree there's a problem with the current natfeat. But the discussion did not
> end like this. In fact, it ended because nobody was able to give a better
> implementation than the current one.
>
> Personnaly, I would have directly used illegal opcodes, without using the
> cookie jar. That would be a lot cleaner, OS-wise.
>
> But some people disagree with this because ColdFire uses this opcode (or could
> in the future, I don't remember). I personnaly do not believe in the ColFifre
> for TOS clone. I would use PPC for this as I already wrote many times.

 Again, this dangerous attitude. Please....

>
> But, anyway, here is a proposal that would be CF friendly :
>
> I think we could do something like using some opcode already used on ColdFire.
> To test for the natfeat existence, we could call this opcode and :
> - If a illegal instruction trap is taken, we're on a real m68k,
> - If the opcode do what it is supposed to do on a ColdFire (let's say it update
> a register), we're on a CF,
> - Then we could check the natfeat response.
>
> Of course, only the OS have to check this. It could then set a cookie
> indicating that natfeat is available (along with a version number).
>
> This way natfeat would be MP fiendly.
>
> I know Petr won't like this because it means changing Natfeat again. This means
> a lot of work. And no other emulator would use such a moving target.

 Ok, you are talking about detecting NF here. A cookie may exist for that.
As Conrad pointed out, cookies are good to indicate features. Like flags
for different availabilities. In a perfect world, the BIOS would set such
things up. In this case, I would think it would be EmuTOS's job to detect
and setup this cookie. I think best way would be having NATFEAT.XDD do
this check. If NF present, stay, if not the XDD is not loaded. This is the
best cleanest way.

>
> I'm really sorry for this inconveniences, but, as Konrad, I'm not happy with
> current natfeat. And I think it is very important to clean it.

 And using cookies to store info about NF is NOT clean :-)

>
> I have yet to find some suitable opcode for this. Will look at my Coldfire docu
> and try to give a complete proposal ASAP.

 If you absolutely have to find an 68k opcode for this, look at the Line
A. Very few applications use them, and only 0xa000 up to 0xa00f is
currently in use. (I dont know if 0xa010, for example, is considered a
Line A, tho).

>
>
> > > ?? what real machines are going to accept it?
> > See Xavier's mail.
>
> That was only a bad joke. I don't want to add support for natfeat on the CT60.
> Although it can technically be done, there's no point in doing it.
>
> Please excuse me for adding more confusion in this discussion. :(
>
>
> Regards,
>
>
> Xavier
>
>

-- 
 Regards,

 Odd Skancke - ozk.atari.org - http://assemsoft.atari.org