[M3devel] 64bit big-endian

[Jay K]

So..historically, with the gcc-backend, we don't have
much C code. Just thin wrappers, like:


int int Unix__open(const char* a, int b)
{
return open(a, b);
}


copying in the case of stat.


Errno constants are "instantiated" instead of "inline"
extern const Errno_EBADIF = EBADIF;


and we use if/else/else instead of switch on them.


So that we don't have to duplicate their values for every target,
like we used to (porting headache).



So I don't think the choice of C compiler made that big a difference.



Now we do have a C backend, that nobody is using.
So the C compiler becomes more interesting.



Also, for a long time, our gcc-backend made
every load and store volatile.
Hypothetically this tanked performance, but in reality
probably only Tony knew, and nobody noticed, then later
I noticed. And I fixed it.
I compiled with -O2 and -O3, which is noticably slower than
not optimizing, and where there were problems, I either fixed
them, or disabled a small number of specific optimizations.
I believe I found at least one gcc bug therein -- around use
of division/mod operator that we use but isn't exposed to C/C++ (maybe Ada??)
At least one optimization pass was acknowledged buggy by
the gcc maintainers and they removed it themselves (the one that
tries to convert structs to scalars, I think.)




Our NT386 backend always optimizes some, but never inlines anything.
(It is better than the volatized gcc backend.)


We are optionally safe, yet compile directly to native.
So we should be competitive.
We are probably faster in general than any interprter -- Ruby and Python and Perl.
Now, things that JIT -- JScript, Java, C# -- they have a good chance
of being close behind or ahead in performance.
Languages with no safety -- C and C++ -- they are likely faster in general.


And again, I do favor Sun cc.
Both because it might be faster and it gives me a chance
to make our C code portable by testing it on additional C compilers.



Our C code has also fairly recently been through the Tru64 compiler.
Some of it goes through Visual C++.
And maybe some others.


I tested the C backend with Sun cc I think.
And now Microsoft Visual C++.


I should get over to clang...


As to which build I produced how, the definitive information
is probably the config files in the releases.


As to the redundancy, well, people don't want to give up
the old names, and I want to provide the new names, so there
ends up both.


For SPARC instruction set we did bump up to something not ancient.
It was needed for atomics, at least, I think.
You can see in the config file.


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


SunXArch = "v8plus"


It is difficult to find a balance among: 
  performance  
  convenience   
  prebuilt binaries that works for most everyone right out of the box  
  or easy to build source that works for most everyone  
  portability  
  test matrix (cost) 
  short command lines (convenience)  
  debuggability 
  time 



 but I tried. 


 - Jay




> Date: Wed, 18 Sep 2013 08:15:02 +0000
> From: microcode at zoho.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] 64bit big-endian
> 
> On Tue, Sep 17, 2013 at 09:05:39PM +0000, Jay K wrote:
> > SPARC32_SOLARIS is a new name for SOLsun/SOLgnu.
> 
> But which? Sun cc or gcc? And then it would seem from your comment there is
> at least one duplicate download. This is confusing.
> 
> > Not sure if it should be PPC or PPC32, SPARC or SPARC32,
> >  I386 or X86 or IA32 or what, but ok.
> 
> With i386, x86, and IA32 everybody understands we're talking about a 32 bit
> version for Intel. It's just different names for the same thing and nobody
> expects a compiler other than gcc to have been used to build it. 
> 
> With Solaris SPARC there are a few different things that are important. One
> is you have a choice of Solaris Studio (cc) or gcc as we said. Then there is
> 32 v. 64 bit. Counterintuitively 32 bit is better in most situations.
> Then there is the option of V9 instruction extensions over V8 but still
> running 32 bit. This is normally the best performance option on 64 bit SPARC
> boxes. If you want to support V8 boxes then this is another variation, or
> maybe you build nominal 32 bit V8 and 64 bit V9 versions. That's suboptimal
> but then one or the other or both will work on most SPARC boxes still running.
> 
> >  The old names continue to be supported. 
> > We don't really need/want to encode precise versions in the names.
> 
> Understood and I am not questioning the naming conventions except for
> Solaris where there are really quite a few variations and options that have
> a big effect on performance and are meaningful when somebody is trying to
> pick the right one.
> 
> > See, it used to be there was a roughly one to one processor to OS mapping.
> > So "HPPA" implied HPUX, NetBSD/Linux/FreeBSD implied x86.
> 
> Yeah, I know. Life was simpler in the old days ;-)
> 
> >  We have access to the opencsw machines for Solaris.
> 
> That's good news. Thanks for the info. I'm glad to see how much opencsw does
> for the Solaris community. I keep finding things they help with.
> 
> > There is actually very little target-dependent anywhere in the Modula-3 system at this point.
> > I removed all the rewritten Posix headers for example, replaced with a more portable layer.
> > (i.e. no need to know exact layout and sizes of things).
> 
> Good news! I guess that means you are using libc instead of syscalls because
> I know Solaris syscalls are different from linux, etc. I don't know how
> closely Solaris libc is aligned to Linux or BSD libc...
> 
> Thanks,
> 
> Israel
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130918/3539d807/attachment-0002.html>