[M3devel] "please confirm my understanding"

[Jay]

Thanks! It helps to know I'm understanding things correctly.
 
The backend isn't bad really, it's written by someone who very much knew what they were doing, which is necessary.
 
 > end interfaces. For example, it only ever stacks integer things as  > 32 or 64 bits, even if the integers have a memory representation that 
Understood.
 
Actually, btw, the front/middleend could do more easy optimizations, like some of the ones I already commited, and really, all the constant propagation that m3x86.m3 does, via its stack stuff and remembering if something is "immediate". I should look into that some time.......
 
 - Jay



> From: hosking at cs.purdue.edu> Date: Thu, 29 Nov 2007 10:59:26 -0500> To: jay.krell at cornell.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] "please confirm my understanding"> > > On Nov 29, 2007, at 6:15 AM, Jay wrote:> > > please confirm my understanding> >> > I don't feel great being a lone reader/changer of code esp. that I > > didn't write and that lacks> > sufficient documentation for my small brain/confidence. (I'm not > > stupid, but this isn't trivial stuff either.)> > If you are talking about the native x86 (non-gcc) backend then I > concur that it is pretty unreadable. Hence my lack of enthusiasm in > working on it myself.> > > I am bound to make mistakes.> > We all do!> > > In the context of Modula-3 code gen interfaces, and the word > > interfaces, which apparently are identical/analogous/whatever:> >> > There is:> >> > Shift (aka, my bad naming, "generic" shift)> > Yes, shift by n>0 is shift left. n<0 is shift right.> > > LeftShift> > RightShift> >> > LeftShift and RightShift allow only positive shift counts, 0 .. 31 > > or 0 .. 63 (given> > particular word sizes and depending on types..)> > The "front end" checks constants against these.> > The "front end" inserts checks for variables against these.> > The back end can assume 0 .. 31 or 0 .. 63.> > Yes, depending on word-size.> > > It looks like the x86 back end does redundant masks against 31, at > > least when shifting by a constant,> > only in its own data, not in the codegen. Just a small waste of > > time in the compiler, no negative affect on codegen.> >> > "generic" Shift accepts any number for a shift count.> > Negative numbers mean a right shift.> > Positive numbers mean a left shift.> > If the shift count is >31|63 or <-31|63, the result is not an > > error, but zero.> > Yes.> > > In all cases, right shifts are unsigned, zero filling.> > Yes.> > > There is no shift operation that propagates the sign bit.> > In the Modula-3 language even. Perhaps, yes, integer division. But > > the frontend does not optimize> > there and turn multiplication or division into shifts, I think, > > haven't read much of the frontend. The backend could.> > Correct. I think the thinking was that a decent back-end would turn > integer division by a power of 2 into an arithmetic right shift (the > gcc backend certainly does).> > > Rotate is presumably similar, but I have not looked at it.> > (LeftRotate, RightRotate, Rotate...)> > Weird thing with these is the way the high/low bits are rotated > around, so sign can change!> > > m3-sys\m3back\src\m3x86.m3 implements left_shift, and right_shift,> > very redundanty code, could be combined.> >> > The layering is /roughly/> > m3x86 on top> > stackx86 in the middle> > codex86 at the bottom> >> > However m3x86 does call through to codex86 directly.> > They are largely one layer. There is no strict division.> > "stack" is a simple way to implement some optimizations and stategies> > around constant propagation and register allocation.> >> > It is a stack of "operands", which may be constants, globals, or > > locals.> > If something is needed in a register, a register will be freed up.> > If something is later needed and the register hasn't been spilled, > > it will be> > reused. If not, not.> >> > Presently the operands are assumed to be of word size, 32 bits, > > register size.> > That is largely a convenience, and very convenient.> > I will expand it to allow two word operands.> > It could be expanded to arbitrarily, at least to "fill" "all" the > > registers, for some> > not particularly interesting but theoretically useful scenarios -- > > passing "medium"> > sized structs around by value or such. There are ABI concerns > > though, this could> > only be amongst local functions that aren't visible/used > > externally (aka "custom calling conventions").> > You can make some assumptions about how the front-end uses the middle- > end interfaces. For example, it only ever stacks integer things as > 32 or 64 bits, even if the integers have a memory representation that > is 8 bits, etc.> > > The "generic" shift (vs. left_shift, right_shift) is implemented in > > stackx86> > while left_shift, right_shift are in m3x86. All three functions are > > very similar,> > could be combined, and there is no good reason for some to be in > > one layer> > vs. the other and it's a just a pointless inconsistency.> >> > Granted, "generic" shift is a good bit different, it has to check > > the sign and the magnitude,> > whereas left and right can just blindly do the operation with no > > comparisons or branches.> >> > Some of this I gather from attempting to compile code with shifts > > -- esp. the frontend checking of stuff, which then lead me to look > > at word.i3> > which declares subranges for the parameters.> >> > Is Bill Kalsow around?> > Good question. Farshad Nayeri may know where he ended up.> > > Or the other original authors?> > I know Michel Dagenais had a student who adapted the native x86 > backend for use on Linux with PM3. I don't remember the student's name.> > > Everyone just figured stuff out from the code, comments, and > > "literature" (I ordered another copy of Nelson's good book. :) )> >> >> > - Jay> >> >> > Connect and share in new ways with Windows Live. Connect now!> 
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20071130/cc31f5ff/attachment-0002.html>