Beta ptitSeb's Beta Lair


CLang is 2 days of build, at least, on the Pandora. And weight several hundreds of megabytes. So, not sure I'll do it for now (but it should be a straight forward compile using latest codeblocks beta, at least for the LLVM part, as it's part of Rust for example).
 
Magic Sam said:
@ptitSeb : yes I noticed that. I googled this issue, and it seems to be MinGW related (i.e people trying to compile the Multics simulator from Windows...). Since we're not (AFAIK) using MinGW on the Pandora, I thought maybe my little hacks to use GCC instead of Clang were responsible for that bug...

And one guy managed to compile this Multics simulator on his Raspberry Pi, so this should be ARM compatible IMHO...
Click to expand...
Mingw is a suite of tools ported to windows, including GCC, so building using mingw usually means building using gnu make and gcc. So any problems they had may well be transferable.

Also, the Pi's probably run hardfp versions of code. Compiling for other variants can introduce problems some times I would suspect (though I can't think of any legitimate reasons why it would fail).
 
Hi all :)

@ptitSeb and @levi : I received some replies from the multicians community:

Vince Scarafino (who ported the Multics simulator to the Raspberry Pi):
The ARM processor on my Raspberry Pi is 32-bit, so routines had to be created for
the 64-bit math instructions. It appears that is the issue here. I'll see if I can
get some help.
Click to expand...

and Charles Anthony (who actually wrote the simulator):
An explanation of what is going on, but not a solution:

The emulator requires the 128 bit integer type to do the DPS8/M 72 bit double precision math.

The 32 bit clang compiler recognizes the 128 bit integer type; the 32 bit GCC compiler does not.

I am not familiar with Open Pandora; would it be feasible to cross-compile from a clang supporting host? Perhaps building the object files on that host and doing the linking on the Open Pandora platform ?
Click to expand...

Opinions ? Any secret trick up GCC's sleeves to solve this issue ? What about ARM intrinsics ?

Cheers, Magic Sam
 
Magic Sam said:
Hi all :)

@ptitSeb and @levi : I received some replies from the multicians community:

Vince Scarafino (who ported the Multics simulator to the Raspberry Pi):


and Charles Anthony (who actually wrote the simulator):


Opinions ? Any secret trick up GCC's sleeves to solve this issue ? What about ARM intrinsics ?

Cheers, Magic Sam
Click to expand...
Use boost multiprecision maybe?
http://www.boost.org/doc/libs/1_57_...ml/boost_multiprecision/tut/ints/cpp_int.html

With cpp magic of overloaded operator, it might even be plug'n play?
 
Yes, I recall some issue with the way GCC defines longs and so on on ARM causing problems. I forget if NEON on the OMAP3 has 128-bit registers, but that might be worth investigating. Using NEON is pretty much the antithesis of a 'straight port' though, so I could understand if you'd prefer something that can be done with writing a C++ class to wrap up a 128-bit type using 32-bit variables.

Edit: Or using Boost's implementation, as Ptitseb ninja'd me with!
 
Last edited:
Magic Sam said:
@ptitSeb and @levi: thanks guys :)

I just found this wikipedia article about libraries serving a similar purpose:

https://en.wikipedia.org/wiki/List_of_arbitrary-precision_arithmetic_software

Is Boost the simplest one ? I'm not a developer, and I'm really bad at maths :p

EDIT: the Multics simulator is written in C, not C++. Maybe GMP would be better for the job ?

Cheers, Magic Sam
Click to expand...
Well, GMP is what GCC use. It's certainly stable and precise, but for ease of use, I guess C++ with it's overloaded operator cannot be beaten (you just write stuff naturaly, like "int128_t a = b * 2;", and boost/c++ will apply the correct operators. with GMP, you will have to rewrite every mathematical operation using gmp functions.
 
Hi all :)

@ptitSeb : I tried to compile (with cmake) clang 3.4 this afternoon, but failed miserably...

I set CLANG_PATH_TO_LLVM_BUILD to /mnt/utmp/codeblocks/usr, but cmake complained that "include could not find load file: AddLLVM". Same error message for "TableGen".

What did I do wrong ?

@levi : I told the author about the boost multiprecision library, and he seemed concerned about it being C++, while his simulator is written in C...

Cheers, Magic Sam

P.S: on a side note, I compiled the simulator on my Debian 8 x86_64 box, installed the latest Multics release, booted the system then logged in from my Pandora over telnet ! That was really fun :)
 
Magic Sam said:
Hi all :)

@ptitSeb : I tried to compile (with cmake) clang 3.4 this afternoon, but failed miserably...

I set CLANG_PATH_TO_LLVM_BUILD to /mnt/utmp/codeblocks/usr, but cmake complained that "include could not find load file: AddLLVM". Same error message for "TableGen".

What did I do wrong ?
Click to expand...
You need to compile LLVM too. the minimum is llvm+clang. There is no proper llvm build in codeblocks (the llvm part in rust are static libs already linked to rust, so not useable).
It would be better to not use libcxx, and try to use standard libstdc++ from the GNU suite if possible.
 
Hi all :)

@ptitSeb: I'm sorry to bother you with this again, but it looks like your wxWidgets package is no longer compatible with one of your latest Code::Blocks release (GCC 7.1) :(

I compiled a new version of Odamex this afternoon (git from April 12th 2017, forced SDL 1.2 with -DUSE_SDL12=1), and it failed to start with the following error message:
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1010,wx containers,compatible with 2.6,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1011,wx containers,compatible with 2.6,compatible with 2.8).
/usr/pandora/scripts/pnd_run.sh: line 528: 2342 Aborted "./$EXENAME" $ARGUMENTS "$@"
Click to expand...
Could you please have a look ?

EDIT: just tested the standalone SDL 1.2 odamex client (without the odalaucher which depends on wxWidgets), and it did run correctly with @notaz' improved SDL :) You can expect a new Odamex release as soon as this ABI issue is sorted out :)

Cheers, Magic Sam
 
Last edited:
Hi all :)

@ptitSeb : I stumbled on this error while recompiling Odamex with your latest Code::Blocks PND:
[ 93%] Building CXX object odalaunch/CMakeFiles/odalaunch.dir/__/odalpapi/net_packet.cpp.o
In file included from /mnt/utmp/codeblocks/usr/include/c++/7.1.0/vector:69:0,
from /media/Pandora1/dev/odamex-github/odamex/odalpapi/net_packet.h:33,
from /media/Pandora1/dev/odamex-github/odamex/odalpapi/net_packet.cpp:31:
/mnt/utmp/codeblocks/usr/include/c++/7.1.0/bits/vector.tcc: In member function ���void std::vector<_Tp, _Alloc>::_M_realloc_insert(std::vector<_Tp, _Alloc>::iterator, _Args&& ...) [with _Args = {const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&}; _Tp = std::__cxx11::basic_string<char>; _Alloc = std::allocator<std::__cxx11::basic_string<char> >]���:
/mnt/utmp/codeblocks/usr/include/c++/7.1.0/bits/vector.tcc:454:5: internal compiler error: Segmentation fault
}
^
0x66da73 crash_signal
/media/sda1/sources/gcc-6.2.0/gcc/toplev.c:337
0x52ab77 sparseset_bit_p
/media/sda1/sources/gcc-6.2.0/gcc/sparseset.h:147
0x52ab77 mark_pseudo_regno_live
/media/sda1/sources/gcc-6.2.0/gcc/ira-lives.c:289
0x52b61f process_bb_node_lives
/media/sda1/sources/gcc-6.2.0/gcc/ira-lives.c:1079
0x510843 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
/media/sda1/sources/gcc-6.2.0/gcc/ira-build.c:1806
0x52c44b ira_create_allocno_live_ranges()
/media/sda1/sources/gcc-6.2.0/gcc/ira-lives.c:1564
0x5122d3 ira_build()
/media/sda1/sources/gcc-6.2.0/gcc/ira-build.c:3422
0x50a443 ira
/media/sda1/sources/gcc-6.2.0/gcc/ira.c:5302
0x50a443 execute
/media/sda1/sources/gcc-6.2.0/gcc/ira.c:5613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
make[2]: *** [odalaunch/CMakeFiles/odalaunch.dir/build.make:116: odalaunch/CMakeFiles/odalaunch.dir/__/odalpapi/net_packet.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:290: odalaunch/CMakeFiles/odalaunch.dir/all] Error 2
make: *** [Makefile:150: all] Error 2
Click to expand...
I didn't have this issue before. Any idea what I'm doing wrong ?

Cheers, Magic Sam
 
It's an internal error of GCC. Not much you can do.
You can try to lower the optim level off that particular file it crashed on (net_packet.cpp) by adding "#pragma GCC optimize 0" as 1st line of the file.. It may solve the issue.
 
You must log in or register to reply here.

Similar threads

ptitSeb
Beta [beta] OGS Mahjong
Replies
11
Views
3K
matzesu
matzesu
Maquis196
Release The Ur-Quan Masters
2 3 4
Replies
79
Views
12K
klapse
klapse
ptitSeb
Beta [beta] Revenge of the Titans
Replies
10
Views
4K
dimag0g
dimag0g
pepone
Release Gngeo 0.8.2
4 5 6
Replies
102
Views
42K
yoshi41dragon
yoshi41dragon
quartercast
Beta Jagged Alliance 2 Stracciatella Beta!
2
Replies
26
Views
12K
shaddim
S
Back
Top