Exec exception handling and a time interval implementation...

[Piru]

As a result AllocVec()'s old behaviour was kept up for 68k code, but dropped for PPC code (AFAIK), just to avoid future usage of such hacks.

So you have asymmetrical system where PPC and 68k routines work in a different way? How is that "cleaned up"? I really wonder if it really was worth the trouble to change this behaviour in the end. Wouldn't it have been much more sensible to just keep the size in there? (I mean not being able to predict problems with this change is just incompetent).

That is only one very prominent example where it was easy to distinguish between old and new software. But that is not always possible. And if it breaks only some ancient software I prefer a cleaned up system with enforced adherence to the documented facts.

Well, that's the problem: You don't know what breaks (you never can test every application). There is no way of knowing what important and cool applications will break.

I can accept less cleaned up system if it works better with old applications.

But you shouldn't encourage usage of things like mp_Flags=3. This was also completely new to me.

Well, I see no problem in telling people about it. This way they will know about it, at least. Just telling about it doesn't mean you're encouraging use of it.

You know about the limitations and dangers. But others don't know about it and nobody can read about that anywhere, because it is undocumented.

That's why I explained in detail the limitations and usage.

Hence, better keep it secret.

I disagree. Better know about these things, at least then future OS coders won't break the compatibility for no reason.

[RWO]

@Piru

Whouldent you get in trouble if a 68k application used that tick and ended up is a PPC code function.

I can imagine that the Emulator jumping from a 68k function to another 68k function, but crossing over whould lead into trouble.

RWO

[Piru]

@RWO

Whouldent you get in trouble if a 68k application used that tick and ended up is a PPC code function.

No.

I can imagine that the Emulator jumping from a 68k function to another 68k function, but crossing over whould lead into trouble.

It does not. The code is always executed as 68k. If a PPC function is to be called, there needs to be a gate:

Code: [Select]


#include <emul/emulregs.h>
#include <emul/emulinterface.h>
#include <exec/ports.h>
#include <exec/libraries.h>
#include <clib/debug_protos.h>

void func(void)
{
  struct MsgPort *port    = (APTR) REG_A1;
  struct Library *SysBase = (APTR) REG_A6;
  kprintf(&quot;SysBase 0x%lx port 0x%lx\n&quot;, SysBase, port);
}

static const struct EmulLibEntry GATEfunc =
{
  TRAP_LIBNR, 0, func
};

...

mp->mp_Node.ln_Type = NT_MSGPORT;
mp->mp_Flags = 3;
mp->mp_SigTask = (APTR) &GATEfunc;
NEWLIST(&mp->mp_MsgList);


And no, it doesn't go thru m68k emulation there. MorphOS is smart enough to spot PPC->m68k->PPC call and skip over the emulation completely. So it's a direct PPC->PPC call in the end, with no performance penalty. This is the whole point of MOS: Have the old API while giving full PPC performance benefits for both old and new apps. Old m68k apps automagically benefit from native libraries, while new PPC apps can continue to use the same API, without performance losses. Naturally you can also create fully PPC native APIs if you wish.

[RWO]

@Piru

Yes I can understad that adding a Trap function in the mp_SigTask will work but I were thinking more in the lines like we have an old program 68k and an old system 68k.. now as time go by the system get upgraded to PPC, then the old program still has a direct address and not a Trap.. in that case I se it fail.

RWO

[Piru]

@RWO

we have an old program 68k and an old system 68k.. now as time go by the system get upgraded to PPC, then the old program still has a direct address and not a Trap.. in that case I se it fail.

Err, no. It won't. Naturally the OS still calls the routine as m68k one.

If there is any OS that will fail in that case, then the OS in question is broken beyond repair. You just can't change the way these things work.

[itix]

Yes I can understad that adding a Trap function in the mp_SigTask will work but I were thinking more in the lines like we have an old program 68k and an old system 68k.. now as time go by the system get upgraded to PPC, then the old program still has a direct address and not a Trap.. in that case I se it fail.

Trap instruction (0xff00 family instructions) is not needed for 68k code. It just only indicates start of PPC code and when there is not trap the stuff is executed in 68k emulation mode.

68k function pointer in the mp_SigTask is not different than 68k function pointer in the h_Entry of struct Hook for example.