14 March 2021, 18:53 | #1261 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 681
|
Quote:
plus I recommend using WSL instead of msys2 or cygwin! https://franke.ms/amiga/wsl2.wiki |
|
14 March 2021, 18:54 | #1262 |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 181
|
Unfortunately
I tried compile separate every .c file using MAKE like this, but the effect is still the same Code:
HEADERS = main.h BM_Bitmap.h BM_Bitmap_TGA.h EM_Engine_Main.h GP_Gameplay.h IO_In_Out.h LV_Level.h MY_Draw.h MY_Math.h MY_Typedefs.h RC_Raycaster.h TM_Timer.h CC = m68k-amigaos-gcc LIBS = -lm FLAGS = -pg -g -O3 -noixemul -m68060 -mhard-float -funroll-loops default: ray BM_Bitmap.o: BM_Bitmap.c $(HEADERS) $(CC) $(FLAGS) -c BM_Bitmap.c $(LIBS) -o BM_Bitmap.o BM_Bitmap_TGA.o: BM_Bitmap_TGA.c $(HEADERS) $(CC) $(FLAGS) -c BM_Bitmap_TGA.c $(LIBS) -o BM_Bitmap_TGA.o GP_Gameplay.o: GP_Gameplay.c $(HEADERS) $(CC) $(FLAGS) -c GP_Gameplay.c $(LIBS) -o GP_Gameplay.o LV_Level.o: LV_Level.c $(HEADERS) $(CC) $(FLAGS) -c LV_Level.c $(LIBS) -o LV_Level.o MY_Draw.o: MY_Draw.c $(HEADERS) $(CC) $(FLAGS) -c MY_Draw.c $(LIBS) -o MY_Draw.o MY_Math.o: MY_Math.c $(HEADERS) $(CC) $(FLAGS) -c MY_Math.c $(LIBS) -o MY_Math.o RC_Raycaster.o: RC_Raycaster.c $(HEADERS) $(CC) $(FLAGS) -c RC_Raycaster.c $(LIBS) -o RC_Raycaster.o TM_Timer.o: TM_Timer.c $(HEADERS) $(CC) $(FLAGS) -c TM_Timer.c $(LIBS) -o TM_Timer.o EM_Engine_Main.o: EM_Engine_Main.c $(HEADERS) $(CC) $(FLAGS) -c EM_Engine_Main.c $(LIBS) -o EM_Engine_Main.o main.o: main.c $(CC) $(FLAGS) -c main.c $(LIBS) -o main.o ray: main.o BM_Bitmap.o BM_Bitmap_TGA.o EM_Engine_Main.o GP_Gameplay.o LV_Level.o MY_Draw.o MY_Math.o RC_Raycaster.o TM_Timer.o $(CC) $(FLAGS) main.o BM_Bitmap.o BM_Bitmap_TGA.o EM_Engine_Main.o GP_Gameplay.o LV_Level.o MY_Draw.o MY_Math.o RC_Raycaster.o TM_Timer.o $(LIBS) -o ray |
14 March 2021, 19:01 | #1263 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,200
|
I think the linking stage needs different flags than the compiling stages.
|
15 March 2021, 00:48 | #1264 |
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Hi all!
First of all thanks Bebbo for the great toolchain, I am trying to build a datatype (and re-learning Amiga C-stuff after many years...). Starting from this example: http://aminet.net/package/dev/c/C_V44-DT I managed to go past the compilation phase after adjusting all the __saveds and inline registers stuff. However, I am now stuck with this error, tried lots of compiler/linker options, but I am not really sure what's wrong (also could not find it anywhere else, hence I decided to post it here): Code:
/opt/amiga/bin/m68k-amigaos-gcc -noixemul -nostartfiles -fbaserel -s -lm -pg -o samplePNM.datatype libfuncs.o StartUp.o LibInit.o -ldebug -lc -lamiga /opt/amiga/lib/gcc/m68k-amigaos/6.5.0b/../../../../m68k-amigaos/bin/ld: libfuncs.o: in function `ObtainPicClass': libfuncs.o:(.text+0x4): undefined reference to `__restore_a4' |
15 March 2021, 08:01 | #1265 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 681
|
Since you’re not linking the regular startfiles, you’ll have to provide your own implementation.
You can do this like shown here: https://github.com/mheyer32/dopus5al.../libinit.c#L62 |
15 March 2021, 12:49 | #1266 | |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 181
|
Quote:
Thanks for answer, I am using WLS, I build the setup/buildwin file, the installer was made but the output files like m68k-amigaos-gcc was not windows executable? Do you suggest using only Linux insted of Windows? If not, how can I make the windows bins myself? Thanks you in advance. |
|
15 March 2021, 15:07 | #1267 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 681
|
Quote:
I recommend using WSL to compile and debug. I even run Eclipse to develop C/C++ within WSL. You find all your windows drives at /mnt/c etc.p.p. so if you open a WSL bash you can cd and make also on your windows drives. Or create softlinks to folders on the Windows side, or ... or .... This way I copy created files into the WinUAE folder and run it there. For simple not hardware related stuff, also vamos is great to test these directly. I also mounted the linux drive as U: (like unix) to access all the Linux stuff from Windows too. If you want Windows executables you have to build these via Cygwin oder MSys2. But it's sooo slooooooooooow..... |
|
15 March 2021, 15:59 | #1268 | |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 181
|
Quote:
Thank You |
|
16 March 2021, 12:04 | #1269 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 681
|
Quote:
it's not related to the toolchain - but why do so many people use -fbaserel to create libraries, if you could store all your data in your library via a6? |
|
16 March 2021, 23:23 | #1270 | ||
Registered User
Join Date: Jul 2017
Location: Oxford
Posts: 107
|
Quote:
Quote:
@bebbo: I am basically re-learning AmigaOS, libraries, etc. etc... is there any documentation explaining what all these options do? I'd be glad to read it! I only tried to readapt that example (on Aminet) which in turn recommends looking at another example meant for libraries, and it seems it won't work without -fbaserel (there's a warning pointing at it for __saveds__) ... but as I said: I am relearning and might be doing many things wrong! Sorry about that! |
||
17 March 2021, 08:28 | #1271 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 681
|
Quote:
I stripped my library file to create a lib skeleton and attached it. (I also started with one of the examples). I also added a mathieeesingbas.library created this way, to support KICK 1.3... If you follow this recipe, you simply link the library with. Code:
m68k-amigaos-gcc -nostartfiles -o "your.library" f1.o ... All lib bases are kept in your mylib struct and are fetched into a local variable - or you provide defines to access the member... And in the resulting library there should be no data segment at all. Thus code generation and linking does not need any special stuff. Last edited by bebbo; 26 October 2023 at 13:18. |
|
17 March 2021, 14:09 | #1272 | |
Registered User
Join Date: Feb 2019
Location: Munich, Germany
Posts: 63
|
Quote:
https://github.com/BartmanAbyss/vsco...-debug#porting how I did it. (You would have to adapt to bebbo's toolchain) |
|
26 March 2021, 15:26 | #1273 | |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 181
|
Quote:
|
|
26 March 2021, 15:28 | #1274 |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 181
|
Hello,
Can we "fix it" somehow? 1. CyberGfxBase = OpenLibrary("cybergraphics.library", CYBERGFXVERSION); **** pointer targets in initialization differ in signedness [-Wpointer-sign] **** 2. OpenDevice("timer.device", 0, &TM_timer_request, 0); **** pointer targets in initialization differ in signedness [-Wpointer-sign] **** Thank you |
27 March 2021, 22:36 | #1275 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
You could configure your compiler to use the same char signedness as the prototypes for those functions, perhaps..
|
28 March 2021, 16:49 | #1276 | |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 725
|
Quote:
|
|
21 April 2021, 23:07 | #1277 |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 181
|
Hello @bebbo,
Could you please take a look at this asm sources generated by GCC 6.5.0b ? I am also adding interactive version from your website online compiler to see all the C code. This function draws floor and ceiling on fullscreen at 32bits. - the FAST variant have fixed constant index - the SLOW variant have variable index FAST Code:
u_int32 texture_current_pixel = level_textures[0].row[texture_pixel_x][texture_pixel_y]; Code:
if (is_floor) { texture_index = RC_level->map[curr_cell_x + (curr_cell_y << LV_MAP_SIZE_BITSHIFT)].floor_id; } else { texture_index = RC_level->map[curr_cell_x + (curr_cell_y << LV_MAP_SIZE_BITSHIFT)].ceil_id; } u_int32 texture_current_pixel = level_textures[texture_index].row[texture_pixel_x][texture_pixel_y]; The problem is, that difference in C code is very small, but the difference in ASM code and performace is hudge. So I just wonder if the SLOWER source is generated rigth or maybe are some not optimal instructions? for example: on V6, the FAST version is 70fps, and the SLOW is 37fps.. but on winuae as 060 the result is also the same.. I mean 2x slower This is comparision of the two sources generated direct from my compiler, You can see a big difference: https://www.diffchecker.com/1a3U053H and this is interactive full code version from Bebbos Online Compiler with the same flags: FAST: http://franke.ms/cex/z/bMTKj5 SLOW: http://franke.ms/cex/z/Wq1qz7 I can't say if outputs from my compiler and online compiler are the same.. I don't know assembler, but I have comments that there is an uneccesary use of bfext instead of simple masking which is 6 times slower.. ps. I was compiling using that preinstaled windows distro of gcc 6.5.0b Thank You in advance Last edited by mateusz_s; 21 April 2021 at 23:17. |
22 April 2021, 18:25 | #1278 | |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 681
|
Quote:
the slow variant has an inner loop whith 18 instead of 8 insns, also more memory lookups plus a multiplication - that sums up I guess the code could be better, but first you should start to use integer math whereever possible... Also use 32 bit for variables which are used as array index... ... try reducing shifts. And I doubt that bitfield insns are slower on 68080... |
|
22 April 2021, 20:55 | #1279 |
Registered User
Join Date: Jan 2020
Location: Poland
Posts: 181
|
Hi, Thank you for answer and hints..
|
23 April 2021, 08:58 | #1280 |
bye
Join Date: Jun 2016
Location: Some / Where
Posts: 681
|
if you group your statements you'll see what I mean:
Code:
u_int32 output_pixel_index = ry_x + ry_m_render_width; floor_x__fp += floor_step_x__fp; int32 curr_cell_x_fraction__fp = (floor_x__fp & FP_FRACTION_MASK_16) >> 8; int32 texture_pixel_x = (int32)((128 * 256 * curr_cell_x_fraction__fp) >> 16); int32 curr_cell_x = (floor_x__fp & FP_INTEGER_MASK_16) >> 16; curr_cell_x &= LV_MAP_SIZE_m1; curr_cell_x_fraction__fp is x>>8 and used with *256 which is <<8 ... for curr_cell_y you end up using it with a left shift. maybe all y calculation can be done with left shifted values -> no need to shift in the loop... ... and this belongs into a separated thread... |
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 |
|
|