Exec exception handling and a time interval implementation...

[Piru]

2- Same as above but through a software interrupt, although here all other processes will be interrupted to process it so probably not as good.

This is my favorite.

You could also use the undocumented msgport feature: Setting mp_Flags to 3 will call routine in mp_SigTask when message arrives to msgport. System is in Disable(), and A6 points to execbase, A1 to the msgport in question (making assumptations about other registers is unwise). This is direct call from the context of the thing generating the signal (PutMsg() or ReplyMsg() call in 99% of cases).

[Piru]

The RKM's say timer.device is safe to use.

timer.device is, but exec exceptions are not.

"This is my favorite."
Why ?

It's well documented and easy to use. If you just SendIO() the timer ioreq again in the softint code it will create a nice loop.

If intervals get very short the other tasks running will come to an halt, or not ?

Yes. If you're worried about this use regular timer loop or so. Even that will trigger rescheduling a lot so that'll be quite slow aswell (but not as slow as softint flood, true).

"You could also use the undocumented msgport feature:
Setting mp_Flags to 3 will".

The RKM Libs (what I've read) talks about it.

No they don't. This feature is undocumented.

It's the PA_SOFTINT flag.

Code: [Select]

#define PA_SOFTINT  1


[Piru]

Well, it's fast, but indeed it has some problems. For timer.device it indeed gets called from interrupt, IIRC.

[Piru]

Uh. If task has done Forbid() or Disable() there won't be any rescheduling.

Of course it is instant.

[Piru]

@tboeckel

Do you really think this is a wise decision?

Probably not. I just presented it as an option, with obvious caveat about it being undocumented.

Hacking like this makes further development of AmigaOS so extremly hard.

It does? I haven't noticed any problems here.

Just because some very clever programmers think they are smarter than others exactly this kind of program will crash and burn in the future. One should have learned that lesson from history (OS1.x -> OS2.x, OS2.x -> OS3.x, etc)

Well, clealy any OS that breaks backwards compatibility in such a way sucks donkey b***s.

PS. All AmigaOS versions at least from 1.x to 3.9 support this mp_Flags = 3 trick. MorphOS supports it aswell.

BTW:

Code: [Select]

---------------------------------------------------------------------------
  PutMsg( port, message )
          A0    A1
---------------------------------------------------------------------------

FC1B34  move.b    #5,8(A1)          Make sure message node type is NT_MESSAGE
FC1B3A  move.l    A0,D1
FC1B3C  lea       $14(A0),A0        Compute address of port's message list

FC1B40  move.w    #$4000,DFF09A     Disable()
FC1B48  addq.b    #1,$0126(A6)

        ; Enqueue the message at the end of the port's message list

FC1B4C  lea       4(A0),A0          Point A0 at port's Tail field.
FC1B50  move.l    4(A0),D0          Save pointer to last node in list
FC1B54  move.l    A1,4(A0)          Make new node the last node
FC1B58  move.l    A0,(A1)           New node has no next node
FC1B5A  move.l    D0,4(A1)          Link new node back to old last node
FC1B5E  move.l    D0,A0
FC1B60  move.l    A1,(A0)           Link old last node to new node

        ; Do whatever needs to be done on message arrival.

FC1B62  move.l    D1,A1
FC1B64  move.l    $10(A1),D1        Get address of message port's task.
FC1B68  beq.s     FC1B9E            Exit if port has no task.

FC1B6A  move.b    $0E(A1),D0        Get port's flag bits.
FC1B6E  and.w     #3,D0
FC1B72  beq.s     FC1B8E            Decode the flag bits.
FC1B74  cmp.b     #1,D0
FC1B78  bne.s     FC1B82

        ; Processing for PA_SOFTINT

FC1B7A  move.l    D1,A1
FC1B7C  jsr       -$B4(A6)          Cause the software interrupt.
FC1B80  bra.s     FC1B9E

        ; If PA_IGNORE, do nothing.

FC1B82  cmp.b     #2,D0
FC1B86  beq.s     FC1B9E

        ; (Undocumented?) processing for mp_Flags = 3.  Apparently,
        ; calls a subroutine at mp_SigTask.

FC1B88  move.l    D1,A0
FC1B8A  jsr       (A0)
FC1B8C  bra.s     FC1B9E

        ; Processing for PA_SIGNAL

FC1B8E  move.b    $0F(A1),D0        Get SigBit.
FC1B92  move.l    D1,A1
FC1B94  moveq     #0,D1             Compute corresponding signal mask.
FC1B96  bset      D0,D1
FC1B98  move.l    D1,D0
FC1B9A  jsr       -$0144(A6)        Signal the task.

FC1B9E  subq.b    #1,$0126(A6)      Enable()
FC1BA2  bge.s     FC1BAC
FC1BA4  move.w    #$C000,DFF09A
FC1BAC  rts      

from dev/asm/ExecDis.lha

Thus, this mp_Flags 3 trick has been common knowlege at least from february 1989, that's for 17 years.

[Piru]

I know that argument too well. A very similar discussion was held about if and where AllocVec() stores the size of an allocation. Some very clever people are really convinced that the size must always be stored in a ULONG before the returned address. This was never documented and the fact that it was done that way upto OS3.9 made some programs crash when OS4 beta introduced its new memory system. This system doesn't need to store such a size at all, and hence all assumptions were bogus.

Well, I guess this is why MorphOS has better compatibility than OS4.

In MorphOS we don't break compatibility (even undocumented!) unless if it's absolutely needed. AllocVec stores the size as ULONG before the actual allocation, dos.library MatchPattern[NoCase] return value was not changed just because of "cleanup" and so on.

Just because MorphOS has a new highly optimized memory system, it doesn't break such undocumented things.

Ok, you might try to tell me to keep up this behaviour even with the new system. But why?

OK, supporting "undocumented" return values or features might seem silly, but IMO if supporting them is much more sensible than breaking them for no good reason. All these supported undocumented features add up to much greater software compatibility.

What I want to say is: NEVER rely on undocumented features.

I agree. But unfortunately this doesn't help with already existing applications that rely on these undocumented features (there are tons of apps that you can't fix/recompile). Thus, to get the best possible experience out of your OS, you need to support these things.

Sure, you're free to disagree, but this is what I think and try to maintain in my MorphOS work.

But what about making this mp_Signal=3 thing official?

Well, do what you like, I consider it official already.

[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.

[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.

[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.