[M3devel] bit field operations for insert/extract

[Jay K]

Fair enough, easy enough.
I'd want to double check that the existing use is wanting that interpretation.
 
 
Obviously for that matter, we can leave the code asis for big endian.
And just take your code as it was, but under if (target_is_little_endian).
Big endian is the minority anyway.
:)
(no, I won't do that)
 
 
It would be cool if the frontend never checked target endianness.
It does it very little as it is. But ok either way.
(I want to move the Target.m3 stuff to the config files -- endianness,
setjmp name, jmpbuf size/align, etc., though that's about all that is left)
 
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Tue, 23 Nov 2010 17:46:06 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] bit field operations for insert/extract
>
> If that's the case then I would argue for adjusting the offset accordingly in parse.c.
> extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively.
>
> On Nov 23, 2010, at 4:46 PM, Jay K wrote:
>
> >
> > Let me clarify.
> > Remember when you used bit field operations for extract_mn?
> > And they didn't work on any big endian system?
> > And I had to undo it? With your approval.
> >
> >
> > I believe the way to go:
> > the change you did in parse.c; it was correct, highly likely
> > removing those endian checks in m3front, which you didn't do at the time
> >
> >
> > Removing the endian checks will only affect big endian.
> > The code reads something like:
> > if little_endian extract_mn(offset, count)
> > else extract_mn(size - offset, size - count)
> >
> >
> > So just change it to:
> > extract_mn(offset, count)
> >
> >
> > And I strongly suspect it will affect it "in the right way".
> > But I'm going to try diffing assembly before/after to be sure.
> > And then watch the sparc and ppc hudson builds. :)
> > (and fix PPC_DARWIN beforehand as well)
> >
> >
> >
> > This is perhaps an interface change in m3cg, but there are no other big endian backends
> > and there are no other uses of extract_mn in the frontend, I think.
> > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc.
> >
> >
> > Anyway, still speculation at this point.
> > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible.
> > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations,
> > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend;
> > perhaps it is best to just leave everything asis...?)
> >
> >
> > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!]
> >
> >
> > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer))
> >
> >
> > - Jay
> >
> >
> > ________________________________
> >> Subject: Re: [M3devel] bit field operations for insert/extract
> >> From: hosking at cs.purdue.edu
> >> Date: Tue, 23 Nov 2010 16:34:25 -0500
> >> CC: m3devel at elegosoft.com
> >> To: jay.krell at cornell.edu
> >>
> >> Are they wrong? Seems strange that they worked previously!
> >>
> >> On Nov 23, 2010, at 1:46 PM, Jay K wrote:
> >>
> >> None yet. But notice the endian checks around the insert_mn or
> >> extract_mn uses in cg.m3.
> >> The change would be to remove those.
> >>
> >> - Jay
> >>
> >>
> >> ________________________________
> >> Subject: Re: [M3devel] bit field operations for insert/extract
> >> From: hosking at cs.purdue.edu
> >> Date: Tue, 23 Nov 2010 09:37:00 -0500
> >> CC: m3devel at elegosoft.com
> >> To: jay.krell at cornell.edu
> >>
> >> Refresh my memory. What m3front change did you make?
> >>
> >>
> >> On Nov 23, 2010, at 3:33 AM, Jay K wrote:
> >>
> >> Tony, I'm going to try again to use bitfield operations for extract_mn.
> >> And insert_mn.
> >> I think I know what went wrong before for extract_mn: just remove the
> >> endian check in m3front.
> >> But I'm going to be sure test p240 covers it well.
> >>
> >> The easy part, duh, your original extract_mn was correct I think, just,
> >> again, missing the m3front change.
> >>
> >> Insert_mn is less obvious.
> >> I started writing it... bitfield_ref..modify_expr...uh, seems
> >> suspicious, to be modifying an existing value.
> >>
> >> I guess it's more like, that, but with a temp that starts with the full
> >> value of x:
> >> create temp
> >> modify(temp, x)
> >> modify(bitfield_ref(temp, count, offset), y);
> >> m3_load(temp)
> >>
> >> ?
> >>
> >> I'll try something like that.
> >> It seems unfortunate.
> >> Maybe we can know if x is already a value and not a variable?
> >>
> >>
> >> - Jay
> >>
> >>
> >>
>