![]() |
Quote:
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 |
Quote:
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__ Code:
"defines": [ Code:
|
Quote:
Quote:
Quote:
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 |
Quote:
Maybe there is a future for the NDK 3.2 R4 header files in the gcc distribution after all. |
Quote:
Code:
#ifdef __clang__ |
Quote:
|
Quote:
|
I have a question: is there an equivalent of __LINE__ for current asm line number?
I'd like to set a register like Code:
move.l #__LINE__,d0 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. |
Quote:
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. Code:
/tmp$ cat test.S && m68k-amigaos-gcc -c test.S && m68k-amigaos-objdump -D test.o |
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.
|
Quote:
You can probably hack around it with another level of indirection, like: Code:
// before |
yes, with double macro layer it probably works. Well now it's so nonstandard that I don't want to go that route!
|
Quote:
Code:
.macro A Much less convenient than __LINE__ and care needs be taken for separate compilation units, but might do what you need in this case... |
All times are GMT +2. The time now is 04:16. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.