English Amiga Board


Go Back   English Amiga Board > Coders > Coders. System

 
 
Thread Tools
Old 01 December 2020, 18:20   #1
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
DoSuperMethodA without amiga.lib

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 ?
meynaf is offline  
Old 01 December 2020, 18:50   #2
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,149
Quote:
Originally Posted by meynaf View Post
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.
Thomas Richter is offline  
Old 01 December 2020, 19:12   #3
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
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 :
Code:
 move.l $18(a0),a0		; cl_Super
 move.l 8(a0),-(a7)		; h_Entry
 rts
Correct or not ?
meynaf is offline  
Old 01 December 2020, 19:23   #4
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,149
Well, except that you should better "INCLUDE intuition/classes.i" and make this a "move.l cl_Super(a0),a0", yes.
Thomas Richter is offline  
Old 01 December 2020, 19:39   #5
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
Quote:
Originally Posted by Thomas Richter View Post
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 is offline  
Old 05 December 2020, 10:03   #6
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
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.
meynaf is offline  
Old 05 December 2020, 10:11   #7
lilalurl
Global Moderator
lilalurl's Avatar
 
Join Date: Aug 2001
Location: France
Posts: 3,289
Send a message via ICQ to 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.
lilalurl is offline  
Old 05 December 2020, 14:55   #8
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 360
Quote:
Originally Posted by meynaf View Post
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.
bloodline is offline  
Old 05 December 2020, 15:03   #9
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
Quote:
Originally Posted by bloodline View Post
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.


Quote:
Originally Posted by bloodline View Post
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.
meynaf is offline  
Old 05 December 2020, 17:46   #10
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 360
Quote:
Originally Posted by meynaf View Post
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!


Quote:
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.
bloodline is offline  
Old 05 December 2020, 18:13   #11
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
Quote:
Originally Posted by bloodline View Post
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.


Quote:
Originally Posted by bloodline View Post
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).


Quote:
Originally Posted by bloodline View Post
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.
meynaf is offline  
Old 05 December 2020, 18:28   #12
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 45
Posts: 3,232
Quote:
Originally Posted by meynaf View Post
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
Thorham is offline  
Old 05 December 2020, 18:36   #13
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 360
Quote:
Originally Posted by meynaf View Post
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.

Quote:
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?
bloodline is offline  
Old 05 December 2020, 18:55   #14
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,149
Quote:
Originally Posted by bloodline View Post
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.
Thomas Richter is offline  
Old 05 December 2020, 19:00   #15
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
Quote:
Originally Posted by bloodline View Post
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).


Quote:
Originally Posted by bloodline View Post
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.


Quote:
Originally Posted by bloodline View Post
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
meynaf is offline  
Old 05 December 2020, 19:22   #16
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,149
Quote:
Originally Posted by meynaf View Post
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.



Quote:
Originally Posted by meynaf View Post
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?
Thomas Richter is offline  
Old 05 December 2020, 19:31   #17
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
Quote:
Originally Posted by Thomas Richter View Post
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...


Quote:
Originally Posted by Thomas Richter View Post
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 !
meynaf is offline  
Old 05 December 2020, 19:42   #18
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 360
Quote:
Originally Posted by Thomas Richter View Post
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.

Quote:
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

Quote:
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!

Quote:
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!?
bloodline is offline  
Old 05 December 2020, 20:16   #19
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,149
Quote:
Originally Posted by bloodline View Post
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.


Quote:
Originally Posted by bloodline View Post
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.




Quote:
Originally Posted by bloodline View Post
You are really painting a bad picture here perhaps it’s time to replace it!?

Wrong man, wrong time.
Thomas Richter is offline  
Old 05 December 2020, 20:46   #20
bloodline
Registered User

bloodline's Avatar
 
Join Date: Jan 2017
Location: London, UK
Posts: 360
Quote:
Originally Posted by Thomas Richter View Post
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.
bloodline is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Where did sndfile.lib go? nikosidis support.Apps 6 19 June 2020 17:08
gcc .lib mritter0 Coders. C/C++ 13 27 October 2018 02:13
Wanted: P96 emulation.lib, rtg.lib autodocs, FD/LVO files PeterK Coders. System 6 01 January 2015 19:59
DoSuperMethodA mritter0 Coders. C/C++ 3 08 December 2014 06:56
Xadmaster lib registration Rod_cl support.Apps 4 24 August 2007 00:34

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 22:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.10906 seconds with 15 queries