English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 22 February 2020, 22:22   #1221
Paul1962
Registered User

 
Join Date: Feb 2020
Location: NOTTINGHAM
Posts: 2
Hi,
I've been using this toolchain for a while now for my Amiga, the enhancements by bebbo are really useful.
I have other 68k/coldfire boards which I'm using gcc for but obviously without the enhancements.
Just wondered if anyone had got this toolchain to compile for m68k-elf ?
Tried it myself but binutils fails to build and if I get past that gcc fails with various undefines etc.
Happy to put in the work, just didn't want to reinvent the wheel.
Or maybe the mods are so amigaos specific that compiling for m68k-elf while keeping the improvements isn't on ?

If this is deemed off topic please delete.

Paul
Paul1962 is offline  
Old 22 February 2020, 22:34   #1222
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 45
Posts: 1,418
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by Paul1962 View Post
Hi,
I've been using this toolchain for a while now for my Amiga, the enhancements by bebbo are really useful.
I have other 68k/coldfire boards which I'm using gcc for but obviously without the enhancements.
Just wondered if anyone had got this toolchain to compile for m68k-elf ?
Tried it myself but binutils fails to build and if I get past that gcc fails with various undefines etc.
Happy to put in the work, just didn't want to reinvent the wheel.
Or maybe the mods are so amigaos specific that compiling for m68k-elf while keeping the improvements isn't on ?

If this is deemed off topic please delete.

Paul
AROS uses ELF binaries but not Bebbo's GCC except for some AmigaOS 68k compatibility. Look into that instead. Bebbo's GCC is Hunk formatted, not ELF.
Samurai_Crow is offline  
Old 23 February 2020, 00:53   #1223
Paul1962
Registered User

 
Join Date: Feb 2020
Location: NOTTINGHAM
Posts: 2
Quote:
Originally Posted by Samurai_Crow View Post
AROS uses ELF binaries but not Bebbo's GCC except for some AmigaOS 68k compatibility. Look into that instead. Bebbo's GCC is Hunk formatted, not ELF.
Thanks for your reply.
I’ll take a look at AROS and see what it produces.
I’m currently using GCC 9.2 built for m68k-elf but the code generated by Bebbo’s gcc is considerably more efficient.

Paul
Paul1962 is offline  
Old 23 February 2020, 11:59   #1224
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 456
Quote:
Originally Posted by Samurai_Crow View Post
AROS uses ELF binaries but not Bebbo's GCC except for some AmigaOS 68k compatibility. Look into that instead. Bebbo's GCC is Hunk formatted, not ELF.

the binutils are using hunk not gcc. gcc generates asm source code.
bebbo is offline  
Old 01 March 2020, 15:17   #1225
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 49
Posts: 532
I am trying to compile lua for A500 1.3.
Exe comes out fine, works on A1200. On A500 needs locale.library. What triggers the autoinit for locale.library? Does 1.3 have a locale.library? Any tricks/switches to exclude locale.library?
alkis is offline  
Old 25 March 2020, 13:46   #1226
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 456
Quote:
Originally Posted by alkis View Post
I am trying to compile lua for A500 1.3.
Exe comes out fine, works on A1200. On A500 needs locale.library. What triggers the autoinit for locale.library? Does 1.3 have a locale.library? Any tricks/switches to exclude locale.library?

provide dummy functions for setlocale(...) and friends or create a dummy locale.library for 1.3^^
bebbo is offline  
Old 29 March 2020, 13:08   #1227
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,799
Is it possible to have KS 1.x compatibility and use compiler's softfloat math libraries?

I implemented FPU support to my cpu tester and I need to print floating point values (scientific notation is fine). It needs to support Motorola 80-bit extended (long double) format, including very very very large and very very very small numbers (larger and smaller than double can support) and NaNs and infinities. Performance does not matter, this code is only used to output error reports.

Library is allowed to use FPU but only if FPU is used when calling (s)printf() (Which is unlikely, some init code surely executes some FPU instructions?). Program must still run normally in non-FPU test mode. Separate FPU version is out of the question.

It is also allowed to require KS 3.0+ when calling (s)printf() when printing floating point values.

Another option is to use custom code but printing human readable floating points is painfully boring to do.. (And most likely most existing code uses Intel extended doubles which don't have exactly same format as Motorola. Extended unfortunately is not IEEE standard) Also use of Amiga math libraries directly is not possible, program must be mostly portable.

(Yes, I know. Weird special requirements again..)
Toni Wilen is offline  
Old 29 March 2020, 21:52   #1228
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 456
Quote:
Originally Posted by Toni Wilen View Post
Is it possible to have KS 1.x compatibility and use compiler's softfloat math libraries?

I implemented FPU support to my cpu tester and I need to print floating point values (scientific notation is fine). It needs to support Motorola 80-bit extended (long double) format, including very very very large and very very very small numbers (larger and smaller than double can support) and NaNs and infinities. Performance does not matter, this code is only used to output error reports.

Library is allowed to use FPU but only if FPU is used when calling (s)printf() (Which is unlikely, some init code surely executes some FPU instructions?). Program must still run normally in non-FPU test mode. Separate FPU version is out of the question.

It is also allowed to require KS 3.0+ when calling (s)printf() when printing floating point values.

Another option is to use custom code but printing human readable floating points is painfully boring to do.. (And most likely most existing code uses Intel extended doubles which don't have exactly same format as Motorola. Extended unfortunately is not IEEE standard) Also use of Amiga math libraries directly is not possible, program must be mostly portable.

(Yes, I know. Weird special requirements again..)

have you tried to modify the linkers lib path order to pick the libgcc's libm.a first?
bebbo is offline  
Old 31 March 2020, 17:24   #1229
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,799
Quote:
Originally Posted by bebbo View Post
have you tried to modify the linkers lib path order to pick the libgcc's libm.a first?
Details and command line please. I don't want to know gcc details too much, because they usually don't make much sense..
Toni Wilen is offline  
Old 18 April 2020, 19:17   #1230
thyslo
Registered User
 
Join Date: Apr 2018
Location: Germany
Posts: 72
A quick question. I'm compiling a C++ project with these settings:

Code:
-noixemul -fomit-frame-pointer -fno-exceptions -fno-rtti -Wall -Os -s
Then thinking about using some exceptions here and there. Removing the -fno-exceptions and throwing one exception to test it. Exception handling works great but binary size increased from about 50K to 150K.

I've read somewhere that turning on C++ exceptions increases the binary size by about 10%. So I'm confused why I got this big increase instead. What could be the reason?
thyslo is offline  
Old 18 April 2020, 20:32   #1231
jotd
This cat is no more
jotd's Avatar
 
Join Date: Dec 2004
Location: FRANCE
Age: 48
Posts: 4,066
probably because everything is statically linked here. On "modern" platforms, the C++ run time is dynamic (DLL/.so) by default.
jotd is offline  
Old 19 April 2020, 10:57   #1232
thyslo
Registered User
 
Join Date: Apr 2018
Location: Germany
Posts: 72
Yeah this could be the reason.

When I compile the same project with old StormC4 (gcc 2.95) the use exceptions blows the binary from about 77K to 83K so I was hoping the modern gcc6.5 would act in the same overhead area.
thyslo is offline  
Old 22 April 2020, 20:07   #1233
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 456
Quote:
Originally Posted by thyslo View Post
Yeah this could be the reason.

When I compile the same project with old StormC4 (gcc 2.95) the use exceptions blows the binary from about 77K to 83K so I was hoping the modern gcc6.5 would act in the same overhead area.

the main difference is the exception kind.


gcc 2.95 is using sjlj = setjump longjump, which means that on every try/catch block setjump is used to snapshot the state and affects the runtime


gcc 6.5 is using seh = structured exception handling, which has no runtime overhead unless an exception is thrown. Then some additional structures + some code are used to figure out what do and how to set the state correctly.


So there is a one time malus from the seh functions plus the (maybe) 10% overhead to provide the static info to reconstruct the state.


Try a loop containing a try catch block and you can measure the performance difference.
bebbo is offline  
 


Currently Active Users Viewing This Thread: 2 (0 members and 2 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:56.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.11588 seconds with 15 queries