#785 C++-less compile

[rofl0r]

it's quite annoying that SDCC depends not only on C++, but even on the clusterfuck boost library.
when disabling ucsim, only 5 files actually use C++ (ralloc2.cc is seemingly compiled for different archs multiple times):

g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -Wall -Wno-parentheses -D_GNU_SOURCE  -I. -I.. -I./../support/util -I. -I.  -c -o SDCCbtree.o SDCCbtree.cc
g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -Wall -Wno-parentheses -D_GNU_SOURCE  -I. -I.. -I./../support/util -I. -I.  -c -o SDCClospre.o SDCClospre.cc
g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -Wall -Wno-parentheses -D_GNU_SOURCE  -I. -I.. -I./../support/util -I. -I.  -c -o SDCCnaddr.o SDCCnaddr.cc
g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -D_GNU_SOURCE -I./.. -I.. -I. -I../.. -I./../../support/util -I.  -c -o ralloc2.o ralloc2.cc
g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -D_GNU_SOURCE -I./.. -I.. -I. -I../.. -I./../../support/util -I.  -c -o ralloc2.o ralloc2.cc
g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -D_GNU_SOURCE -I./.. -I.. -I. -I../.. -I./../../support/util -I.  -c -o ralloc2.o ralloc2.cc
g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -D_GNU_SOURCE -I./.. -I.. -I. -I../.. -I./../../support/util -I.  -c -o ralloc2.o ralloc2.cc
g++ -std=gnu++11 -pipe -ggdb -Os -g0 -fdata-sections -ffunction-sections -fno-unwind-tables -fno-asynchronous-unwind-tables -Wa,--noexecstack -fno-math-errno -mtune=generic -D_GNU_SOURCE -I./.. -I.. -I. -I../.. -I./../../support/util -I.  -c -o ralloc2.o ralloc2.cc

i had to compile boost from source especially for this, and it takes 418 seconds (about 8 mins) to build using a bleeding-edge 16 core workstation. imagine the build times for someone using a 10 year old dual core pc. it also takes impressive amount of disk space:

$ du -h /opt/boost/ | tail -n 1
168.5M  /opt/boost/

these are the installed files after build.

it also requires a GB of space for build:

$ du -h /src/build/boost/boost_1_69_0/ | tail -n 1
901.8M  /src/build/boost/boost_1_69_0/

it would be highly appreciated if one could compile sdcc wihout C++/boost. using the old register allocator would already remove half of the above list. the use of these seriously raises the bar for people trying to pile this project from source.

[Benedikt Freisen]

ralloc2.cc is seemingly compiled for different archs multiple times

Those are the register allocators for the respective targets. They just share the same name.

i had to compile boost from source especially for this, and it takes 418 seconds (about 8 mins) to build using a bleeding-edge 16 core workstation. imagine the build times for someone using a 10 year old dual core pc. it also takes impressive amount of disk space:

I seriously doubt that you really had to compile the entire collection of boost libraries, while SDCC only uses a handful. This is where I see the biggest potential for optimizations.

it would be highly appreciated if one could compile sdcc wihout C++/boost. using the old register allocator would already remove half of the above list. the use of these seriously raises the bar for people trying to pile this project from source.

This is only realistically possible if you sacrifice all the targets that exclusively use the new register allocator. Since the resulting compiler would be severely crippled, I do not see that happening.

[Philipp Klaus Krause]

AFAIK, the only part of boost SDCC requires is the graph library.

[Maarten Brock]

Isn't the graph library only used as a set of include files? In other words there is no need to compile boost.

[Philipp Klaus Krause]

AFAIR there is some graph I/O stuff we link to, that is used for --dump-graphs only.

[Philipp Klaus Krause]

Maarten is right. With current boost, we use boost as a header library only. In current boost (and apparently for quite some years now, even graph output (though not graph input, which is not used by SDCC) is possible with just the headers.

[Philipp Klaus Krause]

Ticket moved from /p/sdcc/bugs/3338/

Can't be converted:

• _category: Build

[Philipp Klaus Krause]

This is not a bug. Moved to feature requests.

[Benedikt Freisen]

Looking at the discussion, this feature request appears to have been motivated by a misconception. When taking compiled boost libraries out of the equation, the use of C++ to simplify programming does not lead to any significant overhead, considering that all compiler solutions that are typically used to compile SDCC already come with a C++ compiler.