DoSuperMethodA without amiga.lib

[meynaf]

Well, the title says it all. This function is in amiga.lib but i don't want to include that in my program - would force me to use a linker and i wouldn't be able to just type "phxass source.s" to make everything. Duh.
Having been deceived by bare intuition, then by gadtools, and not wanting to depend on external libraries, i had a look to see if i couldn't fill in the blanks with boopsi gadgets.
But it appears i can't even create a class, due to the lack of a way to forward a message to the parent class...
So, how to do it ? Why didn't intuition.library implement that directly ?

[Thomas Richter]

Originally Posted by meynaf

Why didn't intuition.library implement that directly ?

Most likely because there is not much to implement. All it does is that it takes the superclass pointer cl_Super from the class and forwards the call to its own hook. The class interface is documented in <intuition/classes.h>, and the class structure is "struct IClass" in this file.

[meynaf]

So all i have to do is to grab the pointer to parent class and call the routine from the hook ?

Assuming a0,a1,a2 are like when i got called, it would then just be :

 move.l $18(a0),a0		; cl_Super
 move.l 8(a0),-(a7)		; h_Entry
 rts

Correct or not ?

[Thomas Richter]

Well, except that you should better "INCLUDE intuition/classes.i" and make this a "move.l cl_Super(a0),a0", yes.

[meynaf]

Originally Posted by Thomas Richter

Well, except that you should better "INCLUDE intuition/classes.i" and make this a "move.l cl_Super(a0),a0", yes.

I prefer to always use the numbers. Makes debugging easier because it does only know numbers and this better matches the source, which in turn does not depend on anything external and assembles faster. But that's just me

Anyway, thanks for your help. I'm really a boopsi noob

[meynaf]

Once and for all...

All the routines provided by my lib are designed to augment the programming language.
They have nothing to do with the way libraries are used in C !

Actually, if i could have done this in a 100% transparent manner, i wouldn't include any file at all !
So while alas necessary, includes must be as discrete as possible. Not doable if there are many of them, one per internal module of the lib !
Programs just call the routines as if they were regular instructions. Whatever internal library module they are in, is none of their business.
There is no fundamental difference in f.e. my square root routine and a new instruction added to 68k that would compute integer 64-bit sqr.
Whether something is an external call or a macro or a basic instruction does not matter much anymore.
Pushing the concept, any high level feature can be added (screens, windows, files, etc).

This all makes asm a higher level language retaining the advantages of the low level.
And this is a good thing, as it removes most of the asm programming burden while keeping performance and code density.

Forcing user programs to use a linker - a necessary step to hide the OS away while still using its includes - would destroy the concept completely.
It is hard to explain, but for once please trust me.

[lilalurl]

I ended up moving the other posts to another (locked) thread:
http://eab.abime.net/showthread.php?t=104904

Please keep this one on topic and avoid calling other members names. I'll let Photon, as he is more competent on coding matters than me, review the other posts to see if some posts should be brought back in this very thread or not.

[bloodline]

Originally Posted by meynaf

I prefer to always use the numbers. Makes debugging easier because it does only know numbers and this better matches the source, which in turn does not depend on anything external and assembles faster. But that's just me

Anyway, thanks for your help. I'm really a boopsi noob

Personally I think you should use the includes, as the function offset might change in a future OS version, and you would only need a simple recompile to work again, if you use the include.

Also what about porting your software to a system which is source compatible with AmigaOS (but not necessarily binary compatible)? Though I appreciate that if you have written in 68k assembly then that’s probably nothing you would care about.

[meynaf]

Originally Posted by bloodline

Personally I think you should use the includes, as the function offset might change in a future OS version, and you would only need a simple recompile to work again, if you use the include.

Function offsets can't change without breaking binary compatibility. No decent OS version should do that.
Anyway, this is OT. Please don't resurrect that flame war.

Originally Posted by bloodline

Also what about porting your software to a system which is source compatible with AmigaOS (but not necessarily binary compatible)? Though I appreciate that if you have written in 68k assembly then that’s probably nothing you would care about.

Which system ? I can't see any that's worth porting code to and doesn't have a 68k compatibility layer.
Anyway, this is OT as well. If you want to discuss that, PM me.

[bloodline]

Originally Posted by meynaf

Function offsets can't change without breaking binary compatibility. No decent OS version should do that.
Anyway, this is OT. Please don't resurrect that flame war.

There will be no flame war, you are welcome to your opinion and I have no intention of changing your mind. I was just offering an alternative view incase you hadn’t considered it.

I’m not sure it is off topic to discuss design decisions as to how AmigaOS’s original designers implemented their runtime OOP system. As you asked in your original question, which I think you were right to ask, and I was also curious!

It is not unheard of (certainly in the Apple world), for an OS update to break binary compatibility, usually offering developers a grace period where their software will still work, but expecting developers to update their software... often it needs little more than a recompile!

Which system ? I can't see any that's worth porting code to and doesn't have a 68k compatibility layer.
Anyway, this is OT as well. If you want to discuss that, PM me.

Ok. That’s fine.

[meynaf]

Originally Posted by bloodline

There will be no flame war, you are welcome to your opinion and I have no intention of changing your mind. I was just offering an alternative view incase you hadn’t considered it.

I'm glad you see things this way.
Everyone's free to code like they want, right ?
Btw. It has already been more than considered : see link at post #7. Flame war ended up with thread split in half and the other half closed.

Originally Posted by bloodline

I’m not sure it is off topic to discuss design decisions as to how AmigaOS’s original designers implemented their runtime OOP system. As you asked in your original question, which I think you were right to ask, and I was also curious!

Well, Boopsi looks great at first sight, and its objects are very easy to create and use. However existing objects look more like proofs of concept rather than actual objects designed for use in actual apps...

And creating a new object type does not look straightforward at all (merely creating it is, but the hook function is another story).

Originally Posted by bloodline

It is not unheard of (certainly in the Apple world), for an OS update to break binary compatibility, usually offering developers a grace period where their software will still work, but expecting developers to update their software... often it needs little more than a recompile!

It has at least happened on AmigaOS already once, when OpenLibrary became OldOpenLibrary. But older programs should still work... unless they've been assembled with the name rather than the numeric value and got reassembled since. Nothing's fool proof in our big bad world.

It is unlikely, however, that a new AOS version will come that breaks compatibility. It would be rejected by the community.

[Thorham]

Originally Posted by meynaf

It is unlikely, however, that a new AOS version will come that breaks compatibility. It would be rejected by the community.

It's an outright impossibility seeing how many programs have no source code available. Any OS developer who even considers this ain't firing on all thrusters

[bloodline]

Originally Posted by meynaf

Well, Boopsi looks great at first sight, and its objects are very easy to create and use. However existing objects look more like proofs of concept rather than actual objects designed for use in actual apps...

And creating a new object type does not look straightforward at all (merely creating it is, but the hook function is another story).

Like many things in AmigaOS, the idea is brilliant... but the implementation is a bit “off”... I can’t help but feel BOOPSI would have been better if it had been implemented at a language level like the NeXTStep engineers did with Obj-C. I seem to remember Andy Finkel waxing lyrical over NeXT in an interview once, so that is clearly what they wanted to do.

It has at least happened on AmigaOS already once, when OpenLibrary became OldOpenLibrary. But older programs should still work... unless they've been assembled with the name rather than the numeric value and got reassembled since. Nothing's fool proof in our big bad world.

It is unlikely, however, that a new AOS version will come that breaks compatibility. It would be rejected by the community.

AmigaOS is somewhat unusual as the basic operating system remained unchanged for 30 years... only now is AmigaOS 3.1 being updated. As such the API/ABI is literally etched in stone. Make a change now and you burn 30 years of legacy rather than maybe five years...

But if something is updated, and you do recompile you program, you would perhaps rather the newer function was used... giving the developers a chance to deprecate poor design decisions?

[Thomas Richter]

Originally Posted by bloodline

Like many things in AmigaOS, the idea is brilliant... but the implementation is a bit “off”... I can’t help but feel BOOPSI would have been better if it had been implemented at a language level like the NeXTStep engineers did with Obj-C. I seem to remember Andy Finkel waxing lyrical over NeXT in an interview once, so that is clearly what they wanted to do.

It's a small-talk like "message" passing system. For this to happen at language level, you would have to have a language that supports it. ANSI-C does not, so all the message handling has to be done manually.

Well, as far as the design is concerned.... I'm not so happy about it. First of all, boopsi messages are handled in the input.device task, as part of the intuition input handler to be precise. This means that any long-going activity blocks the mouse and the responsiveness of the system. Instead, the system would have been much better if the activity would be off-loaded to a side-task, and standard exec message communication would have been used. The way how it is done right now means that it is the responsibility of the boopsi to off-load an activity to a potential side task, and intuition is of little help.



Second, the message dispatch system requires each boopsi to go through a big "switch-case" statement, for each layer, at worst up to the root class, so this is not ideal. Hence, there is a lot of almost-identical decisions made multiple times, in each layer of the system. Having particular entry points in the boopsi library would have been better, but there would have been a need to register them somehow.


Third, the system is not ideally documented, so which message is handled exactly how often remains opaque to the user, and incompatible boopsis have been created as a side effect of this.


As messages are "dynamically dispatched" by the message ID only, message IDs will and have been added, so this is a case for better using their symbolic names. There are too many of them, and the set changes and is extensible.

[meynaf]

Originally Posted by bloodline

Like many things in AmigaOS, the idea is brilliant... but the implementation is a bit “off”... I can’t help but feel BOOPSI would have been better if it had been implemented at a language level like the NeXTStep engineers did with Obj-C. I seem to remember Andy Finkel waxing lyrical over NeXT in an interview once, so that is clearly what they wanted to do.

Well, they could have done better, regardless of the language.
Why, there isn't even a way to limit graphical operations of gadgets inside their area. Start drawing something, even with provided RastPort, and you get something relative to the window and not to the gadget.
Try to use any gadgetclass derived class (like buttongclass or strgclass) and see that there is nothing to provide a nice, standard imagery like gadtools does. You have to do it yourself.
And when you try to draw a box with frameiclass you suddenly discover it's totally useless because it's drawn incorrectly, far away from "nice" buttons of gadtools.
However ability to draw everything out of the calling task's context is better than what gadtools does (window refreshing fails when the task is busy).

Originally Posted by bloodline

AmigaOS is somewhat unusual as the basic operating system remained unchanged for 30 years... only now is AmigaOS 3.1 being updated. As such the API/ABI is literally etched in stone. Make a change now and you burn 30 years of legacy rather than maybe five years...

Being unchanged is one of the things that can paradoxically make it attractive : it's very well known, even at its internal level. No bad surprise here.

Originally Posted by bloodline

But if something is updated, and you do recompile you program, you would perhaps rather the newer function was used... giving the developers a chance to deprecate poor design decisions?

The problem with "upgrades" is that often poor design decisions get replaced by even poorer ones

But i can adapt. Even to a totally new design : only thing to change is my system framework, all programs using it would then work again as if by magic. Of course a few numbers to change here and there are far from being an issue

[Thomas Richter]

Originally Posted by meynaf

Why, there isn't even a way to limit graphical operations of gadgets inside their area. Start drawing something, even with provided RastPort, and you get something relative to the window and not to the gadget.

That, however, holds for all of intuition. Nothing prevents you to draw over the window decorations either. Well, except for GIMMEZEROZERO windows, where the clipping is solved in the "most convoluted" way (instead of installing an offset and a cliprect).


You get the coordinates in the DrawInfo, though.

Originally Posted by meynaf

And when you try to draw a box with frameiclass you suddenly discover it's totally useless because it's drawn incorrectly, far away from "nice" buttons of gadtools.
However ability to draw everything out of the calling task's context is better than what gadtools does (window refreshing fails when the task is busy).

Err... the way how gadtools renders frames is through the frameiclass. How else?

[meynaf]

Originally Posted by Thomas Richter

That, however, holds for all of intuition. Nothing prevents you to draw over the window decorations either. Well, except for GIMMEZEROZERO windows, where the clipping is solved in the "most convoluted" way (instead of installing an offset and a cliprect).

You get the coordinates in the DrawInfo, though.

Yes but at least normal intuition gadgets have the position of the gadget itself as coordinate reference, not the window.
Simple coordinate computation will work, until the gadget is anchored to right and/or bottom edge of window...

Originally Posted by Thomas Richter

Err... the way how gadtools renders frames is through the frameiclass. How else?

There are several possible ways. Regular Image structures, or draw it directly by code.
If the frameiclass is used, really i'd like to know how because it's not at all what i got !

[bloodline]

Originally Posted by Thomas Richter

It's a small-talk like "message" passing system. For this to happen at language level, you would have to have a language that supports it. ANSI-C does not, so all the message handling has to be done manually.

Yes, exactly! I was really put off BOOPSI in the ‘90s with all these convoluted function calls... I was young, I didn’t understand it, and avoided it. Had they just implanted it using a language with supported small-talk like message passing, I’m sure I would have picked it up. I seem to be one of the few people on Earth who actually likes Obj-C (certainly I think 2.0 is a really good language), and I found NeXTStep a breeze to understand.

Well, as far as the design is concerned.... I'm not so happy about it. First of all, boopsi messages are handled in the input.device task, as part of the intuition input handler to be precise. This means that any long-going activity blocks the mouse and the responsiveness of the system. Instead, the system would have been much better if the activity would be off-loaded to a side-task, and standard exec message communication would have been used. The way how it is done right now means that it is the responsibility of the boopsi to off-load an activity to a potential side task, and intuition is of little help.

I perhaps shouldn’t be surprised, but it does upset me to hear of such poor implementation! It explains why MUI was much maligned on the slower CPUs.

Perhaps you are in a position to think about it, moving forward

Second, the message dispatch system requires each boopsi to go through a big "switch-case" statement, for each layer, at worst up to the root class, so this is not ideal. Hence, there is a lot of almost-identical decisions made multiple times, in each layer of the system. Having particular entry points in the boopsi library would have been better, but there would have been a need to register them somehow.

Given my (limited) understanding of BOOPSI, I can’t think how it could be implemented any other way, using ANSI C? Again, without moving to a different language, like Obj-C, where I believe the runtime is able to cache dynamically dispatched method calls and perform other optimisations to speed method calls...

I could be totally wrong here, this goes far outside of my experience of Operating System design!

Third, the system is not ideally documented, so which message is handled exactly how often remains opaque to the user, and incompatible boopsis have been created as a side effect of this.

As messages are "dynamically dispatched" by the message ID only, message IDs will and have been added, so this is a case for better using their symbolic names. There are too many of them, and the set changes and is extensible.

You are really painting a bad picture here perhaps it’s time to replace it!?

[Thomas Richter]

Originally Posted by bloodline

Perhaps you are in a position to think about it, moving forward

No. And even if, it would be far too late to fix that.

Originally Posted by bloodline

Given my (limited) understanding of BOOPSI, I can’t think how it could be implemented any other way, using ANSI C?

At least the most common methods like OM_NEW, OM_DELETE, OM_GET, OM_SET or OM_DRAW should have been mapped to standard LVOs of the boopsi class which would help already to streamline the dispatch mechanism. There would be still a way for a "generic" dispatcher entry in case none of the above match, or a smart "hash" algorithm that derives from the method ID the entry. Or make the method ID the offset to the entry point (even easier). This is how C++ virtual function calls work. Replace the vtable with the library vector entries, and you have a possible design with less overhead.

Originally Posted by bloodline

You are really painting a bad picture here perhaps it’s time to replace it!?

Wrong man, wrong time.

[bloodline]

Originally Posted by Thomas Richter

No. And even if, it would be far too late to fix that.

At least the most common methods like OM_NEW, OM_DELETE, OM_GET, OM_SET or OM_DRAW should have been mapped to standard LVOs of the boopsi class which would help already to streamline the dispatch mechanism. There would be still a way for a "generic" dispatcher entry in case none of the above match, or a smart "hash" algorithm that derives from the method ID the entry. Or make the method ID the offset to the entry point (even easier). This is how C++ virtual function calls work. Replace the vtable with the library vector entries, and you have a possible design with less overhead.

Wrong man, wrong time.

Thank you for taking the time to explain all this, I find it really interesting! I appreciate it.