[M3devel] random notes: gcc 4.5, sparc, etc.

[Jay K]

This is a really tough one to figure out.
I've tried making everything as returns_twice. No luck.
I'm not doing any optimization anyway.
  Though it looks like some optimizations might be done anyway,
  like converting jumps to jumps to single jump.
  I did some work to make 4.3 and 4.5 match, but not completely, and no luck so far.
 
 
I believe the problem isn't MxConfig per se. It is just that the 4.3
version doesn't use $l7 after calling M3File__IsReadable, so
is ok if $l7 isn't restored correctly.
 
 
I have to figure out, perhaps, where save/restore/return/ta3 store/load
the registers from and if that is getting corrupt.
I had trouble finding details on the SPARC stuff. (too much skimming by me) 
e.g. that the register windows are 16 registers in size,
that every non-leaf function must therefore have a frame of at least 64 bytes.
Er, the windows are actually 24 in size, but they overlap by 8, so 16 registers
might be saved/restored at each frame.
(Aside: I believe one of the flaws here is not register windows per se, but
fixed size register windows; I believe Itanium has effectively
variably sized register windows).
 
 
There's still stuff I don't understand -- how setjmp/longjmp/setcontext work.
 wrt SPARC specifically. I understand them otherwise.
 In a CS class in college I was actually tricked on a test by
 the "implement setjmp/longjmp for SPARC" question. I had implemented
 setjmp/longjmp for 65816 so I was overconfident, and just
 did simple register save/load. The trick at the time
 was explained to be "restore in a loop until the register window
 lines up". However that's not how SPARC longjmp looks wherever I checked
 in the past few days.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: random notes: gcc 4.5, sparc, etc.
> Date: Fri, 8 Oct 2010 11:44:57 +0000
>
>
> For the record:
> Still, no luck. Replacing MxConfig.ms from 4.3 seems to let it get further.
> Or maybe it was M*.
> Problem seems to be that when M3File__IsReadable returns, $l7 gets zeroed.
>
> But I'm going to try another hack.
>
> - Jay
>
> ----------------------------------------
> > From: jay.krell at cornell.edu
> > To: m3devel at elegosoft.com
> > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > Date: Thu, 7 Oct 2010 11:22:28 +0000
> >
> >
> > oh darnit, I wasn't actually applying volatile like mad, at all, in solgnu/4.5. Duh.
> >
> > - Jay
> >
> >
> > ----------------------------------------
> > > From: jay.krell at cornell.edu
> > > To: m3devel at elegosoft.com
> > > Subject: RE: random notes: gcc 4.5, sparc, etc.
> > > Date: Thu, 7 Oct 2010 09:45:49 +0000
> > >
> > >
> > > Unoptimized SOLsun gcc 4.5: exception handling does jump to the right place.
> > > I suspect we are underusing volatile.
> > > e.g.: we don't make all the types/variables volatile, we merely mark MOST of the load/stores volatile.
> > > The ones going through m3_load/m3_store, but not all the other uses of MODIFY_EXPR.
> > >
> > > I think solution is to volatize all decls if we are volatizing all load/store and/or also volatize
> > > all MODIFY_EXPR. There is probably redundancy here.
> > >
> > > Notice that even the original volatization was incomplete.
> > > It volatized current function's current temporaries/locals, but not others declared after
> > > any call to setjmp. I fixed that at some point.
> > >
> > > - Jay
> > >
> > > ----------------------------------------
> > > > From: jay.krell at cornell.edu
> > > > To: m3devel at elegosoft.com
> > > > Subject: random notes: gcc 4.5, sparc, etc.
> > > > Date: Wed, 6 Oct 2010 13:30:00 +0000
> > > >
> > > >
> > > > some random notes
> > > >
> > > > Solaris/sparc32 using gcc 4.3 backend, -O3 breaks exception handling
> > > > Easy test is to run cm3 without a neighboring cm3.cfg and the error
> > > > is that cm3.cfg didn't define BUILD_DIR, rather than couldn't find cm3.cfg
> > > >
> > > > Solaris/sparc32 using gcc 4.5, exception handling is broken, without optimization
> > > > Same easy test, but it crashes upon first attempt to raise an exception.
> > > >
> > > > Solaris/sparc32 using gcc 4.3 is broken by the typeinfo and/or stabilize_reference + O3.
> > > > NULL derefence in backend. Unless you go down to -O2, which parse.c does now.
> > > >
> > > > Linux/sparc32 using gcc 4.5 is very broken, I think without optimization.
> > > > Actually doesn't seem to crash but exit(0) before it finishes initializing all modules.
> > > >
> > > > Meanwhile I think many other targets are working ok with 4.5.
> > > > Hudson doesn't use -O2 or -O3 but I use them fairly often, at least on Darwin.
> > > >
> > > > - Jay
> > > >
> > >
> >
>