06 March 2024, 12:47 | #1541 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 548
|
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 |
|
06 March 2024, 13:07 | #1542 | |
Registered User
Join Date: Jul 2022
Location: Australia
Posts: 49
|
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 |
|
06 March 2024, 13:36 | #1543 |
Registered User
Join Date: Apr 2018
Location: Germany
Posts: 201
|
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": [ "__clang__" ], Code:
#ifdef __clang__ #include <clib/alib_protos.h> #include <clib/exec_protos.h> #include <clib/dos_protos.h> #include <clib/intuition_protos.h> #else #include <proto/alib.h> #include <proto/dos.h> #include <proto/exec.h> #include <proto/intuition.h> #endif |
06 March 2024, 14:06 | #1544 | |||
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 548
|
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. |
|||
07 March 2024, 05:14 | #1545 |
Registered User
Join Date: Jul 2022
Location: Australia
Posts: 49
|
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 |
07 March 2024, 12:16 | #1546 |
Registered User
Join Date: Jul 2022
Location: Australia
Posts: 49
|
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 |
07 March 2024, 17:33 | #1547 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 548
|
Quote:
Maybe there is a future for the NDK 3.2 R4 header files in the gcc distribution after all. |
|
07 March 2024, 21:03 | #1548 | |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 732
|
Quote:
Code:
#ifdef __clang__ #define __stdargs #define __aligned #include <clib/dos_protos.h> #include <clib/exec_protos.h> #else #include <proto/dos.h> #include <proto/exec.h> #endif |
|
08 March 2024, 09:33 | #1549 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 548
|
Quote:
|
|
08 March 2024, 10:48 | #1550 | |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 732
|
Quote:
|
|
01 May 2024, 17:25 | #1551 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,454
|
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. |
01 May 2024, 17:54 | #1552 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,310
|
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 nop move.l #__LINE__,d0 test.o: file format amiga Disassembly of section .text: 00000000 .text: 0: 4e71 nop 2: 7002 moveq #2,d0 |
|
01 May 2024, 18:42 | #1553 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,454
|
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.
|
01 May 2024, 19:12 | #1554 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,310
|
Quote:
You can probably hack around it with another level of indirection, like: Code:
// before .macro m x,y //.. .endm m x,y // after .macro _m x,y,line move.l #\line,d0 //.. .endm #define m(x,y) _m x,y,__LINE__ m(x,y) |
|
01 May 2024, 19:40 | #1555 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,454
|
yes, with double macro layer it probably works. Well now it's so nonstandard that I don't want to go that route!
|
01 May 2024, 19:56 | #1556 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,310
|
Quote:
Code:
.macro A move.l #100+\@,d0 .endm .macro B move.l #200+\@,d0 .endm A A B A Much less convenient than __LINE__ and care needs be taken for separate compilation units, but might do what you need in this case... |
|
19 August 2024, 19:53 | #1557 |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 182
|
rand()%2 is not working
Hey @bebbo,
I noticed a weird bug recently when using rand()%2 so I can get get 0 or 1. I mean the result is always 0 or always 1. I am using this function in my main program loop. For example using rand()%3 works as it should. When I put rand()%2 outside the main loop it also works as it should. - the srand(time(NULL)) is initialized (time(NULL) return correct values). - I tried with "-fbbb=-" and -O0 flags - tried to use volatile variable - I read that in some cases when the loop is executing very fast rand() with low modulo could not work. - I override this problem usign higer modulo like 20 and if < 10 is 0 and if >10 is 1, like for example: int a = ((rand()%20) & 1); Sending example code: (as mentioned rand()%2 only works correctly when is out of this loop) Code:
void SYS__run(void) { // Signal mask for window. ULONG signal_mask = ( 1 << SYS__window->UserPort->mp_SigBit ); char debug_string[32]; UBYTE current_buffer = 0; srand(time(NULL)); // Enter main loop. while (G_io__prefs.is_loop) { // Enter Window Message Loop - handle messages and events. if(SetSignal(0L, signal_mask) & signal_mask) { struct IntuiMessage *imsg; while( imsg = (struct IntuiMessage *)GetMsg(SYS__window->UserPort) ) { switch (imsg->Class) { case IDCMP_MOUSEMOVE: break; case IDCMP_RAWKEY: break; } ReplyMsg((struct Message *)imsg); } } // If using AGA make c2p conversion to the output buffer and display. if (SYS__is_aga) { // Rendering the game. G_run(); // Chunky to planar conversion. c2p1x1_8_c5_040(G_io__prefs.view_buffer, SYS__buffer[current_buffer]->sb_BitMap->Planes[0]); // Swap Buffers with sync. if (G_io__prefs.is_sync) { if (!SYS__safetochange) { while (!GetMsg(SYS__display_port)) WaitPort(SYS__display_port); SYS__safetochange = TRUE; } if (ChangeScreenBuffer(SYS__screen, SYS__buffer[current_buffer])) { SYS__safetochange = FALSE; } } // Switch buffers. current_buffer ^= 1; } else { // Puting into screen display the otherone bitmap. SYS__screen->RastPort.BitMap = SYS__buffer[current_buffer^1]->sb_BitMap; SYS__screen->ViewPort.RasInfo->BitMap = SYS__buffer[current_buffer^1]->sb_BitMap; // Sync with the monitor. if (G_io__prefs.is_sync) { RethinkDisplay(); } // Setting the game output buffer adress into one of the system bitmaps. // Now the geme will render directly into one of the system bitmaps. G_io__prefs.view_buffer = SYS__buffer[current_buffer]->sb_BitMap->Planes[0]; // Rendering the game. G_run(); // Switch buffers. current_buffer ^= 1; } // Show some debug info. if (G_io__prefs.is_debug) { sprintf(debug_string, "fps: %d dt: %.4f sync: %d", rand()%2, G_io__prefs.delta_time, G_io__prefs.is_sync); Move(SYS__window->RPort, 0,20); Text(SYS__window->RPort, (CONST_STRPTR)debug_string, strlen(debug_string)); } } } |
19 August 2024, 20:08 | #1558 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,310
|
What do you mean it doesn't work correctly? Does it always return the same value?
First thing I would try is to increase the size of debug_string - It seems small compared to potential output... (always use snprintf if you can) Regardless, you should try to reduce the testcase. |
Yesterday, 21:37 | #1559 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 693
|
Quote:
The random generator is poor and alternated even and odd numbers. If you game code also invokes rand() and the count of invocations is even, then %1 yields always the same number. rand() is slightly improved now, but still a pseudo random generator. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
New GCC based dev toolchain for AmigaOS 3.x | cla | Coders. Releases | 8 | 24 December 2017 10:18 |
Issue with photon/xxxx WinUAE Toolchain | arpz | Coders. Asm / Hardware | 2 | 26 September 2015 22:33 |
New 68k gcc toolchain | arti | Coders. C/C++ | 17 | 31 July 2015 03:59 |
Hannibal's WinUAE Demo Toolchain 5 | Bobic | Amiga scene | 1 | 23 July 2015 21:04 |
From gcc to vbcc. | Cowcat | Coders. General | 9 | 06 June 2014 14:45 |
|
|