• Marcel Martin <mmar freenet.de> Dec 07 2004
• Oskar Linde <olREM OVEnada.kth.se> Dec 19 2004
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Dec 26 2004
• Oskar Linde <olREM OVEnada.kth.se> Dec 27 2004
• =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> Dec 27 2004
• "Thomas Kuehne" <thomas-dloop kuehne.cn> Dec 27 2004
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Dec 27 2004

Hello,
is anyone working on a port of GDC to Sun Solaris running on a Sparc
(sparc-sun-solaris2.9)?
The website doesn't mention Sun Solaris explicitly so I didn't expect it to
work, but I tried anyway.
I used GCC 3.4.3 and GDC 0.8 and followed the installation instructions.
There were a lot of warnings and in the gcc/d/dmd/ subdirectory I had to
add #include <alloca.h> to the files that use alloca(). Apart from that,
everything compiled fine and a "gdc" binary was created. However, when
trying to compile a simple "hello world" program, the fresh compiler
crashed.
The processor is 64-bit, but it can run 32-bit code. I've guessed that from
the fact that the regular GCC which is installed creates working 32-bit
code by default, unless you specify the -m64 option.

My naive idea now is that it might be easier to get an initial version of
GDC to work on Solaris that only supports the creation of 32-bit code.
Perhaps someone has already succeeded in this.

Marcel

Marcel Martin wrote:

 Hello,
 is anyone working on a port of GDC to Sun Solaris running on a Sparc
 (sparc-sun-solaris2.9)?
 The website doesn't mention Sun Solaris explicitly so I didn't expect it
 to work, but I tried anyway.
 I used GCC 3.4.3 and GDC 0.8 and followed the installation instructions.
 There were a lot of warnings and in the gcc/d/dmd/ subdirectory I had to
 add #include <alloca.h> to the files that use alloca(). Apart from that,
 everything compiled fine and a "gdc" binary was created. However, when
 trying to compile a simple "hello world" program, the fresh compiler
 crashed.
 The processor is 64-bit, but it can run 32-bit code. I've guessed that
 from the fact that the regular GCC which is installed creates working
 32-bit code by default, unless you specify the -m64 option.
 
 My naive idea now is that it might be easier to get an initial version of
 GDC to work on Solaris that only supports the creation of 32-bit code.
 Perhaps someone has already succeeded in this.
 


on x86 but not on the sparc architecture.) Not too hard to fix thou.

Oskar Linde wrote:

 The crashes are because some functions doing unaligned reads (which is fine
 on x86 but not on the sparc architecture.) Not too hard to fix thou.


FYI:
PowerPC does unaligned reads slower than aligned, but it does not crash.
In fact, haven't heard a CPU crash like that since the old 68000... :-)

--anders

Anders F Björklund wrote:

 Oskar Linde wrote:
 
 The crashes are because some functions doing unaligned reads (which is
 fine on x86 but not on the sparc architecture.) Not too hard to fix thou.


 FYI:
 PowerPC does unaligned reads slower than aligned, but it does not crash.
 In fact, haven't heard a CPU crash like that since the old 68000... :-)


On the sparc architecture a unaligned read results in an exception being
raised by the cpu. SunOS handles this in about the same way as an attempt
to read an illegal page, i.e. the program crashes with a "bus
error" (SIGBUS) instead of a "segmentation fault" (SIGSEGV).

/Oskar

Oskar Linde wrote:

 On the sparc architecture a unaligned read results in an exception being
 raised by the cpu. SunOS handles this in about the same way as an attempt
 to read an illegal page, i.e. the program crashes with a "bus
 error" (SIGBUS) instead of a "segmentation fault" (SIGSEGV).


On the ppc arch, a unaligned read of a 64-bit double (64-bit int too?)
causes a hardware exception which is handled automatically but takes
like 10-100 times longer to handle than an unaligned 32-bit int does...

For AltiVec operations things must be 128-bit aligned, but it only
gives "undefined" results - it doesn't call out any distress signals.
Anyway, aligning things properly does make everything faster = preferred

--anders

 On the sparc architecture a unaligned read results in an exception being
 raised by the cpu. SunOS handles this in about the same way as an attempt
 to read an illegal page, i.e. the program crashes with a "bus
 error" (SIGBUS) instead of a "segmentation fault" (SIGSEGV).


 On the ppc arch, a unaligned read of a 64-bit double (64-bit int too?)
 causes a hardware exception which is handled automatically but takes
 like 10-100 times longer to handle than an unaligned 32-bit int does...

 For AltiVec operations things must be 128-bit aligned, but it only
 gives "undefined" results - it doesn't call out any distress signals.
 Anyway, aligning things properly does make everything faster = preferred


Any ideas how to check instruction alignment on x86 from within D or C?

Thomas

Thomas Kuehne wrote:

 Any ideas how to check instruction alignment on x86 from within D or C?


Instruction alignment should be pretty automatic, I suppose ?
(at least on risc chips where instructions are equal length)

Data alignment is checked for using &1, &3, &7, &127 or whatever...
(on the pointer to the data, that is. same goes for code pointers?)
If the pointer is "even", it's aligned. (i.e above bit-and is zero)

Or did you mean how to check for optimal alignment on X86 ? (No idea)

--anders