[M3devel] CM3 status

Fri Dec 31 23:47:02 CET 2010

Oops, you can see the ambiguity?

So you'd rather leave Solaris/sparc32 back on gcc-4.3 for now, if the gcc-supported stack walking isn't imminent? 
   And possibly volatile on load/store a lot. (That was more out of laziness maybe, I remember if I tried removing it.)
   I don't like that, but I can do it.
   Or is it imminent, by someone other than me?

gcc-4.5 even without any optimizations and volatile everywhere didn't work with the Solaris/sparc32 stack walker.
I tried a fair amount to debug it but gave up at the time.

I continue to assume that Alpha/OSF is even much less interesting, given that it has extremely few users.
  The code continues to sit unused in CVS, same as it mostly ever did.

 > Last time I ran M3 on Alpha/OSF it did work.

I ran it in 2010 and it didn't work.
I don't remember though if that was with gcc 4.3 or 4.5.
I could try again with 4.3, but I don't know what the result would be -- we'd leave it back with 4.3 also?

  > I wasn't real happy about dropping stack walking for Solaris.  It should
 not be difficult to retain.  I thought you were going to try to fix 
m3cg 4.5 to handle it
  > ...modulo making sure that m3cg 4.5 could cope with it.

This was looking to be difficult. Even volatile everywhere and no optimization didn't work.
I could give it another try perhaps. Or maybe someone else can?
Getting it to work without any optimization and volatile on every load/store should be useful and easy, but it wasn't proving even easy.

I figure moving to 4.5 has a fair amount of value, and optimizing one platform Solaris/sparc32 uniquely beyond all others, is less so.

Or maybe I should look again more closely at the gcc stuff. Maybe it could be done imminently..
That would nicely remove a lot of target-dependent-ness out of the front/middle end!.

 - Jay

From: hosking at cs.purdue.edu
Date: Fri, 31 Dec 2010 17:01:27 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] CM3 status

I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking.

On Dec 30, 2010, at 7:01 AM, Jay K wrote:Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization.
  That was the last step in moving off of gcc 4.3 backend.

I wasn't real happy about dropping stack walking for Solaris.  It should not be difficult to retain.  I thought you were going to try to fix m3cg 4.5 to handle it.  My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it.
Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters.
  It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise
  it had been unused for several years I believe, and I don't see its use continuing much.

Last time I ran M3 on Alpha/OSF it did work.
Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5:

2010-10-13 11:18  jkrell

  * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common,
    m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt,
    m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile,
    m3-sys/m3middle/src/Target.m3,
    m3-libs/m3core/src/runtime/SOLgnu/m3makefile,
    m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old,
    m3-libs/m3core/src/runtime/SOLsun/m3makefile,
    m3-libs/m3core/src/runtime/SOLsun/m3makefile-old:

  disable Solaris/sparc32 stack walker
  switch Solaris/sparc32 to gcc 4.5 backend
  function.c: make failure to volatilize when setjmp/vfork present an error
    instead of a warning
  add missing volatilization
  pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were
    seen to hit internal compiler errors (assertion failures)
  remove the "all volatile" paths from parse.c (since they
    were only for Solaris/sparc32's stack walker)

Tony ok'ing (in my interpretation) the abandonment of our stack walker:

https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html

At least that was my interpretation.
Using gcc's exception handling support and *its* stack walker (libgcc/libunwind)
should provide the better and more portable functionality on many platforms.
I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris)
but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc.
"more portable" as in, across all architectures.

Perhaps I should have stuck back with 4.3 until implementing this however.

It is definitely a step backward to not have the stack walker on Solaris/sparc32,
but that is the only platform in years that has had one, and it is not terrible
to have every platform on gcc 4.5.2 and not sprinkling volatile around.
There are some backward steps but definitely a lot forward.
  I tried using 5.4.0 tonight and I didn't get far.

> o possibly unsafe OS calls in new C code (this may be a wrong deduction
> from my side)

I don't know what this is referring to.
The Enable/DisableScheduling? I all but undid that.
It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose.
Some of those it already is in. With OpenBSD moving to pthreads it matters less.
It only matters for user threads.

> o GUI input not working for BadBricks and other games (only on Darwin?)

Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server.
Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally.
Not understood.
It'd be good to get confirmation if/when they ever worked.

> o no clean way for exception handling with current gcc

This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32.
Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and
Alpha/OSF I really don't think is important.

Exception handling has always been very inefficient on all but approx. those two platforms.
It has always been desirable to fix.

The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp.
The inefficiency of the actual throw/catch is not as worrisome.

> o still alignment issues

Details?

> I'm concerned that things get tried out, don't work properly for all
> our target platforms, but are left then and not cleaned up and something
> else gets tried. I'm not sure this is correct, it is just me feeling
> unwell after reading all those mails.

Not really.

> Hudson and Tinderbox status seem to be mostly OK though, but I haven't
> checked in detail (FreeBSD failing was a disk failure on my system
> recently). But the tests don't cover all the things we should check.

Yep I try to remember to check Hudson fairly regularly.
I never look at Tinderbox though.

> I think it would be good to have an overview of the projects/work that
> is in progress or pending and its status. For example, we've imported
> a new gcc version, but that doesn't seem to work well on all targets,
> or does it? If not, how are we going to address this? Use older versions
> on some platforms? Can I read up on that somewhere?

All platforms (except NT386) use gcc 4.5.2 for the backend.
 (I did the upgrade after the release was made but before it was announced;
  they delay announcement while it propagates to mirrors.)

Ok, also ARM_DARWIN hypothetically uses 4.2.
Apple forks gcc fairly aggressively.
Perhaps we should merge the two forks. Perhaps.
ARM_DARWIN isn't really supported currently. Probably that should be worked on.
It'd also be interesting to see what Apple did to 4.2 for ppc/x86...

> I'd like to suggest to simply use our Trac WiKi to document the ongoing

Agreed but I'm lazy.
I just throw "bombs" around..

 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20101231/22707ef2/attachment-0002.html>