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