02 October 2023, 14:25 | #1 |
Registered User
Join Date: Mar 2010
Location: Napoli, Italia
Posts: 76
|
How do you use an NDK?
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.
|
02 October 2023, 15:17 | #2 |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
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 |
02 October 2023, 16:56 | #3 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
Quote:
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 Last edited by Olaf Barthel; 02 October 2023 at 17:10. |
|
02 October 2023, 17:01 | #4 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 537
|
Quote:
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. |
|
02 October 2023, 17:15 | #5 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
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. |
|
02 October 2023, 19:07 | #6 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
Quote:
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. |
|
02 October 2023, 19:29 | #7 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
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. |
|
02 October 2023, 19:34 | #8 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
Quote:
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. Last edited by SpeedGeek; 11 October 2023 at 16:25. |
|
02 October 2023, 21:54 | #9 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,553
|
Quote:
Quote:
Modern NDKs (like 3.2) also include compiler-specific headers, for example for calling OS-functions. All common Amiga-compilers are supported. Quote:
|
|||
02 October 2023, 22:40 | #10 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
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. |
|
03 October 2023, 14:57 | #11 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
Quote:
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. Last edited by SpeedGeek; 11 October 2023 at 16:28. |
|
04 October 2023, 10:23 | #12 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,331
|
Quote:
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. |
|
04 October 2023, 13:17 | #13 | |
Moderator
Join Date: Dec 2010
Location: Wisconsin USA
Age: 60
Posts: 846
|
Quote:
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! |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AmigaOS 3.2 NDK released | bubbob42 | News | 16 | 14 May 2024 18:17 |
3.1 and/or 1.3 NDK | marduk_kurios | request.Other | 5 | 17 February 2014 20:22 |
Programming on the A1200, NDK 3.1 ? | weiju | Coders. General | 2 | 20 August 2011 22:10 |
Amiga NDK | petemaxi | Coders. General | 4 | 23 May 2011 14:52 |
NDK for OS 3.9 | ramon.ortega | request.Apps | 8 | 17 March 2008 22:21 |
|
|