What's this code doing?

[Jherek Carnelia]

I'm having fun disassembling a C program (one of the RKM examples), anyway there's a bit of code that appears a few times and I don't know how to make sense of it. I guess it's pretty easy when you know, but I don't know where to look...

JSR _LVOSetSignal(A6)
MOVEA.L $114(A6),A3 <---- this bit. What's going on here?

Several times it gets AbsExecBase in A6 and then moves the value at offset $114. But what does that value represent? What include file do I need to look at?

[Leffmann]

It's part of the execbase, and is the pointer to your task. It's the value you get when you call FindTask with an argument of 0. You can find the info in the description of the execbase in execbase.h and execbase.i, and also with printed out offsets in the Structure.Offsets file in the Amiga NDK.

[hitchhikr]

It's actually ExecBase->ThisTask

[Jherek Carnelia]

Thank you chaps

[Thorham]

Hmm, shouldn't you use FindTask instead of reading directly? Seems cleaner that way, or is reading this value completely safe (as in theoretical future versions keeping this the same)?

[thor]

Kickstart does exactly the same when you call FindTask(0). (Well, it does move.l $114(a6),d0).

[Jherek Carnelia]

Originally Posted by Thorham

Hmm, shouldn't you use FindTask instead of reading directly? Seems cleaner that way, or is reading this value completely safe (as in theoretical future versions keeping this the same)?

That's what I thought too. I always believed it was bad practice, but this is the compiler output... Anyway, I guess that it's never going to change now!

If compilers are doing it there is no way the 68K version would be able to be changed as so much would break. I guess the compiler did it as an optimisation to save on the expense of going through the jumptable when it already has ExecBase to hand.

[StingRay]

Originally Posted by Thorham

Hmm, shouldn't you use FindTask instead of reading directly? Seems cleaner that way, or is reading this value completely safe (as in theoretical future versions keeping this the same)?

Originally Posted by Jherek Carnelia

That's what I thought too. I always believed it was bad practice, but this is the compiler output... Anyway, I guess that it's never going to change now!

There is absolutely nothing wrong doing it that way, it's a commented part of execbase so it can be used without any problems.

[Thorham]

Thanks guys

Originally Posted by StingRay

There is absolutely nothing wrong doing it that way, it's a commented part of execbase so it can be used without any problems.

Yep It says that most fields shouldn't be read or written (I thought none of the fields should be used directly), but it also says when it's fine to do so, and in this case it is

[Leffmann]

Generally it's better to ask the operating system for any value you need whenever you can. If any functionality gets patched or otherwise hooked then any code like this will just fall through.

The reason the compiler produced the above is because the source said exactly what Hitchhikr posted. Inlining a function call like this, for which the compiler doesn't have any corresponding source or object file for, would be prone to fail.

[StingRay]

Originally Posted by Leffmann

Generally it's better to ask the operating system for any value you need whenever you can.

And what is exec for you? Not a part of the OS?

Originally Posted by Leffmann

If any functionality gets patched or otherwise hooked then any code like this will just fall through.

I'd rather not use any patches that will make perfectly valid code "just fall through".

[Leffmann]

Originally Posted by StingRay

And what is exec for you? Not a part of the OS?

You don't understand, it's about asking the OS through function calls instead of getting stuff yourself by peeking inside system structures.

Originally Posted by StingRay

I'd rather not use any patches that will make perfectly valid code "just fall through".

These could be things like SetPatch, RTG, programs like SnoopDos, Scout, FBlit or anything. It's not necessarily about just reading some value from memory. The whole point is that if you use established interfaces your program is more likely to benefit from things like these.

[Thorham]

Originally Posted by Leffmann

You don't understand, it's about asking the OS through function calls instead of getting stuff yourself by peeking inside system structures.

Reading values directly should be fine if the docs say it's fine. In the case of execbase->ThisTask the include file says it's readable. Changing this can break things, and thus it wouldn't have changed in future versions.