Re: [MiNT] Shutdown() discussion

[Xavier Joubert <xavier.joubert@free.fr>]

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.

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.

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

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.

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.

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.

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


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