<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>So..historically, with the gcc-backend, we don't have<br>much C code. Just thin wrappers, like:<br><br><br>int int Unix__open(const char* a, int b)<br>{<br>return open(a, b);<br>}<br><br><br>copying in the case of stat.<br><br><br>Errno constants are "instantiated" instead of "inline"<br>extern const Errno_EBADIF = EBADIF;<br><br><br>and we use if/else/else instead of switch on them.<br><br><br>So that we don't have to duplicate their values for every target,<br>like we used to (porting headache).<br><br><br><br>So I don't think the choice of C compiler made that big a difference.<br><br><br><br>Now we do have a C backend, that nobody is using.<br>So the C compiler becomes more interesting.<br><br><br><br>Also, for a long time, our gcc-backend made<br>every load and store volatile.<br>Hypothetically this tanked performance, but in reality<br>probably only Tony knew, and nobody noticed, then later<br>I noticed. And I fixed it.<br>I compiled with -O2 and -O3, which is noticably slower than<br>not optimizing, and where there were problems, I either fixed<br>them, or disabled a small number of specific optimizations.<br>I believe I found at least one gcc bug therein -- around use<br>of division/mod operator that we use but isn't exposed to C/C++ (maybe Ada??)<br>At least one optimization pass was acknowledged buggy by<br>the gcc maintainers and they removed it themselves (the one that<br>tries to convert structs to scalars, I think.)<br><br><br><br><br>Our NT386 backend always optimizes some, but never inlines anything.<br>(It is better than the volatized gcc backend.)<br><br><br>We are optionally safe, yet compile directly to native.<br>So we should be competitive.<br>We are probably faster in general than any interprter -- Ruby and Python and Perl.<br>Now, things that JIT -- JScript, Java, C# -- they have a good chance<br>of being close behind or ahead in performance.<br>Languages with no safety -- C and C++ -- they are likely faster in general.<br><br><br>And again, I do favor Sun cc.<br>Both because it might be faster and it gives me a chance<br>to make our C code portable by testing it on additional C compilers.<br><br><br><br>Our C code has also fairly recently been through the Tru64 compiler.<br>Some of it goes through Visual C++.<br>And maybe some others.<br><br><br>I tested the C backend with Sun cc I think.<br>And now Microsoft Visual C++.<br><br><br>I should get over to clang...<br><br><br>As to which build I produced how, the definitive information<br>is probably the config files in the releases.<br><br><br>As to the redundancy, well, people don't want to give up<br>the old names, and I want to provide the new names, so there<br>ends up both.<br><br><br>For SPARC instruction set we did bump up to something not ancient.<br>It was needed for atomics, at least, I think.<br>You can see in the config file.<br><br><br>https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common?rev=1.7;content-type=text%2Fplain<br><br><br>SunXArch = "v8plus"<br><br><br>It is difficult to find a balance among: <br> performance <br> convenience <br> prebuilt binaries that works for most everyone right out of the box <br> or easy to build source that works for most everyone <br> portability <br> test matrix (cost) <br> short command lines (convenience) <br> debuggability <br> time <br><br><br><br> but I tried. <br><br><br> - Jay<br><br><br><br><br><div>> Date: Wed, 18 Sep 2013 08:15:02 +0000<br>> From: microcode@zoho.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] 64bit big-endian<br>> <br>> On Tue, Sep 17, 2013 at 09:05:39PM +0000, Jay K wrote:<br>> > SPARC32_SOLARIS is a new name for SOLsun/SOLgnu.<br>> <br>> But which? Sun cc or gcc? And then it would seem from your comment there is<br>> at least one duplicate download. This is confusing.<br>> <br>> > Not sure if it should be PPC or PPC32, SPARC or SPARC32,<br>> > I386 or X86 or IA32 or what, but ok.<br>> <br>> With i386, x86, and IA32 everybody understands we're talking about a 32 bit<br>> version for Intel. It's just different names for the same thing and nobody<br>> expects a compiler other than gcc to have been used to build it. <br>> <br>> With Solaris SPARC there are a few different things that are important. One<br>> is you have a choice of Solaris Studio (cc) or gcc as we said. Then there is<br>> 32 v. 64 bit. Counterintuitively 32 bit is better in most situations.<br>> Then there is the option of V9 instruction extensions over V8 but still<br>> running 32 bit. This is normally the best performance option on 64 bit SPARC<br>> boxes. If you want to support V8 boxes then this is another variation, or<br>> maybe you build nominal 32 bit V8 and 64 bit V9 versions. That's suboptimal<br>> but then one or the other or both will work on most SPARC boxes still running.<br>> <br>> > The old names continue to be supported. <br>> > We don't really need/want to encode precise versions in the names.<br>> <br>> Understood and I am not questioning the naming conventions except for<br>> Solaris where there are really quite a few variations and options that have<br>> a big effect on performance and are meaningful when somebody is trying to<br>> pick the right one.<br>> <br>> > See, it used to be there was a roughly one to one processor to OS mapping.<br>> > So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86.<br>> <br>> Yeah, I know. Life was simpler in the old days ;-)<br>> <br>> > We have access to the opencsw machines for Solaris.<br>> <br>> That's good news. Thanks for the info. I'm glad to see how much opencsw does<br>> for the Solaris community. I keep finding things they help with.<br>> <br>> > There is actually very little target-dependent anywhere in the Modula-3 system at this point.<br>> > I removed all the rewritten Posix headers for example, replaced with a more portable layer.<br>> > (i.e. no need to know exact layout and sizes of things).<br>> <br>> Good news! I guess that means you are using libc instead of syscalls because<br>> I know Solaris syscalls are different from linux, etc. I don't know how<br>> closely Solaris libc is aligned to Linux or BSD libc...<br>> <br>> Thanks,<br>> <br>> Israel<br>> <br></div> </div></body>
</html>