How do you use an NDK?

[Quagliarulo]

Hello. How exactly do you use an NDK? Compilers already come with their sets of libs and includes. Am I supposed to discard them and replace them with those included in the NDK? In that case, I would expect some compatibility problems.

[SpeedGeek]

An NDK should be used similar to the way you would use the Amiga RKRM. The NDK typically (but not always completely) documents updates to specific AmigaOS versions released after the last RKRM was released.

I ran into problems with the fpsp.resource not being documented in this way. But nobody likes to hear complaints (even when they are true):

https://eab.abime.net/showthread.php?t=112729

[Olaf Barthel]

Originally Posted by Quagliarulo

Hello. How exactly do you use an NDK? Compilers already come with their sets of libs and includes. Am I supposed to discard them and replace them with those included in the NDK? In that case, I would expect some compatibility problems.

This is a good question

By way of introduction, "NDK" stands for "native development kit", which is different from the cross-development kits which existed in the early years of the Amiga in around 1985-1987. The first development kit which was intended for software development on Amigas was not released until 1988.

NDKs collect documentation, header files for 'C' and assembly language development, example code and even development and debugging tools. They are typically not as structured and organized as the Amiga ROM kernel reference manuals (ahem).

The operating system documentation in the form of the Autodocs is perhaps the most useful resource because it covers the actually implemented behaviour of the operating system API, including known bugs and workarounds. However, it is also common for this documentation to be incomplete or wrong in parts.

The header files for 'C' and assembly language development work tend to age poorly, and you should try to make use of the most recent collection of these files if your development environment does not already ship with a more modern version, or a version specifically adapted for it. Your development system may highlight any possible changes made in the documentation which ships with it. If you can, check what's in the "exec/types.h" 'C' header file, which contains an INCLUDE_VERSION macro, e.g. #define INCLUDE_VERSION 40 for the NDK 3.1 (1994). If you are developing software for the AmigaOS 1.x-3.x 68k platform, then the most recent version of NDK 3.2 will use INCLUDE_VERSION 47 (as of October 2, 2023).

That said, the Autodocs and the header files complement one another. You may find documentation in the header files which are not present in the Autodocs and the other way round. As with the Autodocs, the header file documentation may contain errors and there may be omissions which matter.

Beyond these files you may want to explore the material which is provided, such as the documentation and development tools, if any, which accompany it. While not all of it may be useful right now, you might lose out on something useful and/or important. You should be curious when exploring this material

[Olaf Barthel]

Originally Posted by SpeedGeek

An NDK should be used similar to the way you would use the Amiga RKRM. The NDK typically (but not always completely) documents updates to specific AmigaOS versions released after the last RKRM was released.

I ran into problems with the fpsp.resource not being documented in this way. But nobody likes to hear complaints (even when they are true):

https://eab.abime.net/showthread.php?t=112729

The Autodocs for fpsp.resource are not quite part of the Autodocs which make up the bulk of the NDK 3.2. Generally, the bulk consists of the documentation drawn from the operating system source code itself. This is not the case with fpsp.resource, which is not part of the Amiga operating system source code.

Still, no progress is made to raise the quality of the operating system documentation, be it part of a third party contribution such as the MMULib and its components or not, unless you listen to feedback and then act upon it. Nobody really likes negative feedback. But we wouldn't have had the recent NDK 3.2 releases without it.

[Thomas Richter]

Originally Posted by SpeedGeek

I ran into problems with the fpsp.resource not being documented in this way. But nobody likes to hear complaints (even when they are true):

https://eab.abime.net/showthread.php?t=112729

Sorry, I'm totally unclear what your issue is. The fpsp resource is along with everything else around the cpu libraries and the mmu library documented in the MuManual archive. It contains the LVOs and the autodocs you look for - so why that is inappropriate I do not know.


Note that there are no pragmas for the fpsp.resource because you cannot express the interface through the pragmas - this is simply because it takes the input and output in fp0 (and fp1), natural for something that is supposed to help the FPU, and not practical for a C compiler, of course. But the resource is not supposed to be used by high-level code. High-level code uses the math libraries and only implicitly use the resource.



You (clearly) find the mmu interface *along with pragmas* there, too, and example source code, and autodocs, and a manual in RKRM style.


If that's not enough, I do not know. Maybe you should be clearer of what you are missing.

[SpeedGeek]

Originally Posted by Olaf Barthel

The Autodocs for fpsp.resource are not quite part of the Autodocs which make up the bulk of the NDK 3.2. Generally, the bulk consists of the documentation drawn from the operating system source code itself. This is not the case with fpsp.resource, which is not part of the Amiga operating system source code.

Still, no progress is made to raise the quality of the operating system documentation, be it part of a third party contribution such as the MMULib and its components or not, unless you listen to feedback and then act upon it. Nobody really likes negative feedback. But we wouldn't have had the recent NDK 3.2 releases without it.

I wasn't the NDK 3.2 I was referring to, it was the NDK 3.9. The AmigaOS mathieee libraries have been part of AmigaOS since OS2.x. Those libraries were updated to support the fpsp.resource in OS3.9 and replace the OS3.1 versions.

Exactly, how and why these updated libraries became a 3rd party contribution to AmigaOS is another mystery to me. I suppose it's just another detail that H&P decided was unimportant at the time.

[Thomas Richter]

Originally Posted by SpeedGeek

Exactly, how and why these updated libraries became a 3rd party contribution to AmigaOS is another mystery to me. I suppose it's just another detail that H&P decided was unimportant at the time.

The math libraries never became third party contributions. They potentially *use* third party contributions, but that's not the same. They used the mathieee.resource before which had to be implemented by third parties, but during development of 3.9, H&P and myself (surprise, surprise) checked whether the mathieee.resource is worth keeping. The problem is that the overall execution speed of the 68882 included through the resource was as bad as executing the CPU code itself (due to the protocol overhead), so *this* resource was thrown out. The benefit was nearly null, the amount of devices available for it was nearly null, so this was a no-brainer.



Instead, the fpsp.resource came in (through myself, obviously) because it provided a measurable improvement and the design was tested (through FastFPSP). And yes, that was certainly with mutual discussions between H&P and myself.




Thus, yet again, I do not quite see where the problem is - the libraries offered third-party extensions before, and they still offer some other third party extensions now, and the fpsp interface is as open as the mathieee interface for everyone to implement.

[SpeedGeek]

Originally Posted by Thomas Richter

Sorry, I'm totally unclear what your issue is. The fpsp resource is along with everything else around the cpu libraries and the mmu library documented in the MuManual archive. It contains the LVOs and the autodocs you look for - so why that is inappropriate I do not know.

Note that there are no pragmas for the fpsp.resource because you cannot express the interface through the pragmas - this is simply because it takes the input and output in fp0 (and fp1), natural for something that is supposed to help the FPU, and not practical for a C compiler, of course. But the resource is not supposed to be used by high-level code. High-level code uses the math libraries and only implicitly use the resource.

You (clearly) find the mmu interface *along with pragmas* there, too, and example source code, and autodocs, and a manual in RKRM style.

If that's not enough, I do not know. Maybe you should be clearer of what you are missing.

After many years of frustration, I did find the documentation in your MUmanual archive as you already know. That point was already made in my fpsp.resource documentation and thread.

Your documentation did not provide the offsets for the 2 fpsp.resource functions (Monadic and Dyadic) but I was to determine what they were with some extra work. If you use the wrong function, it really does not matter because the Dyadic function doesn't use FP1 anyway.

BTW, the FPU dispatcher code doesn't use the extra bits for FP1 either. Possibly, if you are using SAS C you might have to use it to avoid compiler errors but I had no problem with Devpac assembling the few Dyadic functions with FP0 as the source and destination.

EDIT: Using the wrong function could actually matter be cause because the destination tag is not updated by the Monandic function.

[phx]

Originally Posted by Quagliarulo

How exactly do you use an NDK? Compilers already come with their sets of libs and includes.

Depends. Most compilers provide additions to the NDK, like pragmas and assembler-inlines for calling OS-functions directly. Some also include the full NDK, which was available at their time of release. A few even modified the included NDK, which is rather bad (you can neither easily upgrade or change the NDK, nor is it guaranteed that your sources compile in different environments).

Am I supposed to discard them and replace them with those included in the NDK?

I would expect that to be no problem if you need it, as the old NDKs rarely included anything compiler specific. Plain ISO-C headers and hunk-format linker libraries usually just work.
Modern NDKs (like 3.2) also include compiler-specific headers, for example for calling OS-functions. All common Amiga-compilers are supported.

In that case, I would expect some compatibility problems.

No. There shouldn't be any. The NDK is designed to work with all Amiga C compilers and assemblers.

[Thomas Richter]

Originally Posted by SpeedGeek

Your documentation did not provide the offsets for the 2 fpsp.resource functions

Of course it does. Look into the "lvo" directory. The offsets are usually part of the pragmas, but as the entry points cannot be expressed in pragmas, they are expressed as LVOs to use for an assembler directly. Similarly, an ".fd" file would not be well-formed, so the most appropriate representation was used.


Unlike what you say, fp1 may be used both by FPDynadic as input and is looked at by the dispatcher. There, for dyadic functions like fprem and fpmod, to give two examples.



Also FPMonadic makes use of fp1 for one function, namely fpsincos as result. Note that both functions need to be complete and emulate all fpu instructions, not just the ones used by the math libraries - the fpsp resource is used by MuRedox as well.


Just a final comment: If you had invested the energy in looking into the documentation or asking, instead of reverse engineering, you would be ready much faster. There is really nothing to hide.

[SpeedGeek]

Originally Posted by Thomas Richter

Of course it does. Look into the "lvo" directory. The offsets are usually part of the pragmas, but as the entry points cannot be expressed in pragmas, they are expressed as LVOs to use for an assembler directly. Similarly, an ".fd" file would not be well-formed, so the most appropriate representation was used.

Unlike what you say, fp1 may be used both by FPDynadic as input and is looked at by the dispatcher. There, for dyadic functions like fprem and fpmod, to give two examples.

Also FPMonadic makes use of fp1 for one function, namely fpsincos as result. Note that both functions need to be complete and emulate all fpu instructions, not just the ones used by the math libraries - the fpsp resource is used by MuRedox as well.

Just a final comment: If you had invested the energy in looking into the documentation or asking, instead of reverse engineering, you would be ready much faster. There is really nothing to hide.

I didn't look for LVO's because a resource is not a library or device. In the RKRM's there are function offsets listed for the other resources:

http://amigadev.elowar.com/read/ADCD.../node0550.html

Also, I didn't look for Pragmas because I used assembler for the whole project. The Motorola fpsp source code is in assembler anyway.

Apparently, you didn't look close at the FPU dispatcher code. It only uses the lower 7 bits of the instruction word on the 040 version and the lower 6 bits on the 060 version.

You know very well that, MuRedox has MMUlib dependances and can't function with an independent fpsp.resource. So, why do you want to confuse the users?

Also, Post #8 has been updated and corrected.

[Thomas Richter]

Originally Posted by SpeedGeek

You know very well that, MuRedox has MMUlib dependances and can't function with an independent fpsp.resource. So, why do you want to confuse the users?

Why can't it? You can use the MMULib on top of every other CPU library if you want to, and you can use MuRedox on top of any other fpsp.resource if you want to, either. MuRedox requires the mmu.library, but not the specific CPU libraries - there is no dependency.

[SpeedGeek]

Originally Posted by Thomas Richter

Why can't it? You can use the MMULib on top of every other CPU library if you want to, and you can use MuRedox on top of any other fpsp.resource if you want to, either. MuRedox requires the mmu.library, but not the specific CPU libraries - there is no dependency.

You seem to have very short memory for some of your recent posts:

https://eab.abime.net/showpost.php?p...3&postcount=19

https://eab.abime.net/showpost.php?p...31&postcount=7

As far as I'm concerned, if users want to try using my independent fpsp.resource to replace the existing MMUlib fpsp.resource it's unsupported and at their own risk!