For some reason I am surpised by this and I am not sure why.
Looking through the adtools code I have seen it many times before and just never thought about it. In the code, the address of the Exec library is sought from address 0x4 - just like on classic machines.
This has to work when going through Petunia, but this is PPC. For AmigaOS there is the ability to use __NO_INLINE__ and all the other stuff, but it really gets translated to the AmigaOS interface-new-age style.
Maybe I am just having a mind-blank!
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
Contrary to the old system, AmigaOS 4 has a slightly different way of calling library functions. The old system used to call a library function by making a relative jump into a jump table located directly in front of the library base. AmigaOS 4 keeps these jump tables for backwards compatibility only - only 68k functions are still called this way. The new OS now keeps jump tables in a separate pointer called the "Interface Pointer", or short "interface". Basically an interface is a structure with a bit of housekeeping information and a lot of inline function pointers. A library may export more than one interface pointer (it usually exports at least two).
I guess it is a combination of that and the use of Quote:
#define __NOLIBBASE__ #define __NOGLOBALIFACE__
If liberty means anything at all, it means the right to tell people what they do not want to hear. George Orwell.
Of course, it does, JMP table is not gone, its need ed for 68K programs, but is slow to use for Native programs, as all calls end up function that has translate 68K register table into native function call, this functions are called stubs. you don't want call stubs when you don't need to.
The __USE_INLINE__ thing has nothing to do with legacy, in the sense, your compiled program will use modern function pointer calls, instead of 680x0 JSR / JMP and 68K registers. When compiled for PowerPC. Of course make your code compile on 680x0 systems as well, but main point is to be able to migrate legacy code to AmigaOS4.x.
Only when you have a 68K library, do want call the JMP table, and in that case only do that from PowerPC program is make 1.main stub file, or call EmulateTags on address see AutoDocs / exec.library.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Everything starts with Exec.library. If you want the address of foo.library, you have to call Exec's OpenLibrary() to get it. If you want to print something, you need to Open() a device. So you must have the address of exec.library first of all.
Since it can change at any time (could be loaded in a different place since it's not in ROM any more), the address is stored in a known place, ie 0x4.
tonyw wrote:@rjd324 So you must have the address of exec.library first of all.
Since it can change at any time (could be loaded in a different place since it's not in ROM any more), the address is stored in a known place, ie 0x4.
It's always possible to write things in such a way that this is never necessary. Libraries/Devices get SysBase as param in init call and can store it somewhere else for future use. Similiar thing when creating new processes. There's always some way to pass knowledge about SysBase along.
In AROS/hosted for example there is no SysBase at 0x4. Instead trying to access that address causes segfault (AROS/hosted is really just a normal linux process/program but still 99% identical to the native version).
Looking through the adtools code I have seen it many times before and just never thought about it. In the code, the address of the Exec library is sought from address 0x4 - just like on classic machines.
SysBase isn't (or may not be) stored at 0x4, the zero page isn't mapped, but there is an exception handler for old m68k software returning SysBase when doing a 32 bit read from 0x4. Of course getting SysBase that way is very slow.
Accessing 0x4 in adtools is obviously a bug in the AmigaOS 4.x versions that has to be fixed, not only because it's slow and SysBase is provided as global variable by the C library startup code and available in _start() as well if you don't use a C library, but because it's completely useless. For calling the exec.library functions you need IExec (provided by the C library startup code as well) instead of SysBase, and you must not access any of the obsolete struct ExecLibrary contents on AmigaOS 4.x either.
@Georg Quote:
In AROS/hosted for example there is no SysBase at 0x4. Instead trying to access that address causes segfault (AROS/hosted is really just a normal linux process/program but still 99% identical to the native version).
It's the same on AmigaOS 4.x, no SysBase in 0x4, the difference is just that the "segfault handler" ("DSI" on PowerPC CPUs) returns a fake SysBase on 0x4 reads. That's for making old m68k software work, but any 32 bit read access from address 0x4 returns this SysBase, i.e. native PPC software can get it that way as well, even if it isn't required and shouldn't be used by native PPC software.
Edited by joerg on 2023/1/26 16:24:49 Edited by joerg on 2023/1/26 16:28:41 Edited by joerg on 2023/1/26 17:33:06 Edited by joerg on 2023/1/26 17:34:50
Sadly some stuff marked hidden or obsolete, has no alternative method of being retrieved,
For example if you want find process that command name x is running, there is no longer a way to query this list, without using obsolete or hidden tables.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
For example if you want find process that command name x running, there is no longer a way to query this list, without using obsolete or hidden tables.
Should be possible with dos.library.
Using obsolete SysBase contents will fail at least with multi core exec versions, for example SysBase->ThisTask has to be different on the different cores, and especially when getting a global SysBase from 0x4 through the exception handler that can't work...
Looking through the adtools code I have seen it many times before and just never thought about it. In the code, the address of the Exec library is sought from address 0x4 - just like on classic machines.
Yes I've seen that a bit in OS4 code. Some in system examples. It's unnecessary as in all cases I checked ExecBase is already supplied, such as binary startup and interrupt entry. Not sure about library vectors.
Obviously $4 is still in place for 68K. But PPC shouldn't use it directly. This goes against the advice of caching ExecBase. Once we were told to cache it. Now there is still code that causes a hit by reading it instead of a pointer.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
(You don't need this if you are doing a normal exe).
