[M3devel] bit field operations for insert/extract

[Jay K]

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
>
>
>