Today, Sun is announcing the free availability of Sun Studio 12, the latest release of our set of optimizing C, C++, and Fortran compilers and tools, for the Solaris and Linux platforms:
http://developers.sun.com/sunstudio/downloads/
Here are a few key enhancements:
* Brand new IDE
* Compilers for Linux (first ever!)
* New multithreading/multicore tools, including the new Thread Analyzer
* Outstanding Performance- performance boosts on SPARC and x86/x64 platforms
* Improved GCC compatibility
What is Sun Studio? Previously known as the SunOS compilers, SPARCworks, Sun Workshop, Forte Developer, and Sun ONE Studio, Sun Studio 12 includes the following key components:
* Parallelizing C, C++, and Fortran compilers
* Next-generation IDE based on NetBeans 5.5.1
* Code-level debugger
* Memory debugger
* Performance profiler
* OpenMP v2.5 API support
* Optimized libraries, including Sun Performance Library
* Multithreading tools
In addition, Sun offers a range (from incident to contract) of support options and training:
http://developers.sun.com/services
Please continue to provide feedback through SDN forums and bugs.sun.com!
/kso
So, they didn't shoot marketing yet? Sad to hear.
lg, Bernd
Missed one: Teamworks...
>> includes the following key components:
>
> So, they didn't shoot marketing yet? Sad to hear.
>
> lg, Bernd
--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]
<snip>
If we build Linux and its tools using the Sun compiler, do we then
have to call it "Sun/Linux" ?
No, wait, I have it! "SUNG/Linux" - get it?!?!
Yes, slow work day...
Dan
I think Sun Studio is near record length for a compiler product name now
- 5 straight releases since the last name change (Sun Studio 8, 9, 10, 11,
12).
--
Alan Coopersmith * al...@alum.calberkeley.org * Alan.Coo...@Sun.COM
http://blogs.sun.com/alanc/ * http://people.freedesktop.org/~alanc/
http://del.icio.us/alanc/ * http://www.csua.berkeley.edu/~alanc/
Working for, but definitely not speaking for, Sun Microsystems, Inc.
--
Ian Collins.
Oh come on, let me have my harmless jabs.
School's not giving me much fun lately anyway.
lg, Bernd
> I think Sun Studio is near record length for a compiler product name now
> - 5 straight releases since the last name change (Sun Studio 8, 9, 10, 11,
> 12).
But you know the end is nigh. Somehow I can't see Sun Studio *13*
appealing to the marketing types.
> If we build Linux and its tools using the Sun compiler.
I in fact do wonder if someone tried to compile parts of the Linux
Kernel with Sun Studio 12 (is it called that today?). I think inline
assembler isn't possible with Sun Studio 12, is it?
Thomas
From:
/usr/src/linux/include/asm-i386/thread_info.h
/* how to get the current stack pointer from C */
register unsigned long current_stack_pointer asm("esp")
__attribute_used__;
We see this usage as atypical for most projects and applications, so
it was not prioritized high on the list. This prioritized approach to
gcc-specific extensions also highlights our effort to increase source
compatibility with code built with gcc.
/kso
On Jun 4, 3:17 pm, Thomas Glanzmann <sithg...@stud.uni-erlangen.de>
wrote:
>Bernd Haug <ha...@berndhaug.net> writes in comp.unix.solaris:
>|Thomas Glanzmann <sith...@stud.uni-erlangen.de> wrote:
>|> What is Sun Studio? Previously known as the SunOS compilers, SPARCworks,
>|> Sun Workshop, Forte Developer, and Sun ONE Studio, Sun Studio 12
>|> includes the following key components:
>|
>|So, they didn't shoot marketing yet? Sad to hear.
>I think Sun Studio is near record length for a compiler product name now
>- 5 straight releases since the last name change (Sun Studio 8, 9, 10, 11,
>12).
You just had to point that out in a public forum, didn't you? :-)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
>Hello,
It is, but not in the "gcc way".
Sun's compilers have always supported inlining in a, what I consider,
fairly clean way. You write an assembly routine and put this in
a separate (inline template) file. You then pass the inline templates
on the compiler command line and the compiler will insert the code
and optimize around it as needs be.
E.g., to get the caller of a function use:
! return caller
.inline caller,0
mov %i7, %o0
.end
.inline caller,0
movl 4(%ebp), %eax
.end
Casper
Nah, some of us had been pointing that out at work, on our own. :-)
I get to answer fun questions from management about: "Why do we need
product Y?" "It's the same thing as product X" "Really?" "Really." ;)
Then a few years later...
"We need product Z." "Why do we need product Z? Don't we have product
Y." "It's the same as Product Y." "Hmm. So you're telling me it's also
same as Product X, too?" "Yes, precisely."
Then repeat a few years later...
;)
-Dan
>
> "We need product Z." "Why do we need product Z? Don't we have product
> Y." "It's the same as Product Y." "Hmm. So you're telling me it's also
> same as Product X, too?" "Yes, precisely."
If only it were that simple.
"We need product Sun Storedge Q, look, here it is in the catalogue."
"No, we need product Sun StorageTeK Z, over here in the catalogue."
"But Sun Storedge Q is the new name for Product X, we need that, since
we have Product X." "Yes. So is Sun Storagetek Z. probably: neither
catalogue entry actually mentions Product X." "But Product X was just
Foonly Product G rebadged, couldn't we just get Foonly Product G?"
"erm. Perhaps we'll just not buy anything until they make the
catalogue comprehensible." "Good idea."
I mean, really.
> Sun's compilers have always supported inlining in a, what I consider,
> fairly clean way. You write an assembly routine and put this in
> a separate (inline template) file. You then pass the inline templates
> on the compiler command line and the compiler will insert the code
> and optimize around it as needs be.
It's not clear how this "inline template" file is different from
"plain assembly" file, or how it can be used in e.g. C source.
Could you please give an example, or provide a reference?
Thanks,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
>Casper H.S. Dik <Caspe...@Sun.COM> writes:
>> Sun's compilers have always supported inlining in a, what I consider,
>> fairly clean way. You write an assembly routine and put this in
>> a separate (inline template) file. You then pass the inline templates
>> on the compiler command line and the compiler will insert the code
>> and optimize around it as needs be.
>It's not clear how this "inline template" file is different from
>"plain assembly" file, or how it can be used in e.g. C source.
It is NOT used in C source; I thought that bit was clear; the C source is
unmodified.
So, you'd use:
extern uintptr_t caller(void);
c = caller();
and supply the .il template file on the command line; the compiler
then figures out that the caller function exists in the inline template
and substitutes it.
The name change from "Forte Developer" to "Sun ONE Studio"
happened with "Sun ONE Studio 7".
The name change from "Sun ONE Studio" to "Sun Studio"
happened with ""Sun Studio 8", but earlier, there
also was ""Sun ONE Studio 8, Compiler Collection" (no IDE).
Thomas
The Linux kernel isn't written in C (not any dialect, K&R, C89 or C90).
Rather it's more 'gnuc'. Some of those 'gnucisms' are spreading to Sun
Studio, to help porting OSS cruft^H^H^H^H^H software.
A bientot
Paul
can anybody tell me why the sparc edition is about twice the size of the
x86 version?
TIA,
Thomas
>can anybody tell me why the sparc edition is about twice the size of the
>x86 version?
Tons of specifically optimized additional libraries.
sparc sparcv8-fsmuld sparcv9
sparcv7 sparcv8plus sparcv9+vis
sparcv8 sparcv8plus+vis sparcv9+vis2
I don't think we've gone quite as far with optimized x86 libraries.
> can anybody tell me why the sparc edition is about twice the size of the
> x86 version?
x86 is 32 bit. sparc is 64 bit.
64 / 32 = 2.
So it's twice the size ;-)
>Thomas Maier-Komor wrote:
>> can anybody tell me why the sparc edition is about twice the size of the
>> x86 version?
>x86 is 32 bit. sparc is 64 bit.
Not quite; x86 comes with amd64 support as well.