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.
> 
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.

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