Which version/release of the AmigaOS 3.2 NDK are you currently using, exactly? The most recent release is still AmigaDOS 3.2 NDK R4, with R5 still being in the works.

R5 features further interface header file changes which render them more robust if the compiler environment claims to be the GNU 'C' compiler, but is really clang. The interface header files assumed that if gcc was showing its hand, it was a native or cross compiler targeted for AmigaOS 68k. With the current work-in-progress, you can actually use these header files directly with VSCode, for example, and no local changes required to even narrowly avoid tripping the code completion up. One of these days we might even had helpful code comments in the <clib/#?_protos.h> header files :)

R4 was still focused on getting the gcc 68k and vbcc interface header files into shape. That there was more trouble on the horizon with cross-compilation, etc. had yet to be discovered and addressed :shocked

TBH, I'm not sure... at least as it relates to the cross-compilation toolchain. I run Bebbo's install and it downloads NDK automatically; I just checked the header files and they appear to be dated mid-2021?!). On my real-Amiga I use R4.

Now I'm eagerly awaiting R5! :) My goal is to use (neo)vim with something like YCM as the auto-completion plugin. If I can get that going with 3.2 NDK R5 I'll be super happy.

Thanks for the update. :)

-M

Thanks for showing the CMakeLists file, I'll have a look at it.

For autocomplete when programming in VSCode I have a workaround. In vscode setting file c_cpp_properties.json I define __clang__

And in the .c/.cpp files I include the library proto headers like:
With this, autocomplete works quite well here.

That likely makes them part of AmigaOS NDK 3.2 R3. The R4 header files should be dated early February 2022 (and we didn't manage to release R5 in 2023).

:great

Happy to whet your appetite ;) It's been taking longer than expected to get the next release "into orbit" because of the bug fixes applied to header files and much expanded documentation for the dos.library in the form of the now largest Autodoc file ever. Questions will be answered which managed to elude explanation and context for more than 30 years.

Just this month we kindly received fixes for the assembly language header files found in the "datatypes" drawer: they had been broken since at least 1993. The dos.library 'C' header files have been thoroughly reworked for perhaps the first time since 1989.

There's plenty to look forward to and, hopefully, make it easier to unlock what was previously hard to find in the documentation, if at all.

Thanks Thyslo! I think there are other non-proto files that use __stdargs and ASM registers that clang refuses to work with. However, this might be a good stop-gap to eliminate a good chunk of errors!

-M

Ok, I replaced the NDK version installed as part of the toolchain with R4 and clang complains much less, like much less. So for now I can probably live with this until R5 is made available! Thanks again.

-M

Hey, progress after all :)

Maybe there is a future for the NDK 3.2 R4 header files in the gcc distribution after all.

For emacs + eglot I had to do it like that
With those two defines I think I stopped getting errors.

Careful about that __aligned keyword. The code which needs it may have to be rewritten. Accidentally removing it through the preprocessor can have unforseen and really annoying consequences. The stack may get trashed, which is always hard to detect as the cause of unexpected trouble.

No. See this is only for __clang__ (which emacs' eglot uses). When you do the actual compile with gcc, __clang__ is not defined.

I have a question: is there an equivalent of __LINE__ for current asm line number?

I'd like to set a register like

in case of an error for instance

BTW I had a lot of issues with PC-relative LEA which weren't in the same unit. I got a warning when linking (using long... for ...) but the address was still PC relative and it read at the wrong location.

Great assembler no matter what. Using it for 15+ projects now.

The exact snippet you wrote does work as intended if you enable preprocessing and use the gcc frontend (i.e. not as, otherwise preprocess manually).


This happens automatically if the input file is called ".S" rather than ".s" (yes, bad convention on case-insensitive file systems). Alternatively you can add "-x assembler-with-cpp" on the command line.

that's good and it works. But not in macros (.macro) where it's very useful. Maybe with #define... but multi-line defines with "" don't seem to work either. Oh damn.

Ahh, new requirements :)


You can probably hack around it with another level of indirection, like:
Not tested, but you get the idea... Maybe there is some GCC magic to get line in another way in .macro, but I doubt it..

yes, with double macro layer it probably works. Well now it's so nonstandard that I don't want to go that route!

Understandable. I'm not a GNU as wizard (and this is maybe venturing a bit OT), but perhaps you can use \@ to accomplish what you want:

Much less convenient than __LINE__ and care needs be taken for separate compilation units, but might do what you need in this case...