[M3devel] "please confirm my understanding"

[Jay]

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.)
I am bound to make mistakes.
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)LeftShiftRightShift
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.
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.
In all cases, right shifts are unsigned, zero filling.
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 optimizethere and turn multiplication or division into shifts, I think, haven't read much of the frontend. The backend could.
Rotate is presumably similar, but I have not looked at it.(LeftRotate, RightRotate, Rotate...)
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 stategiesaround 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").
The "generic" shift (vs. left_shift, right_shift) is implemented in stackx86while 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 layervs. 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.i3which declares subranges for the parameters.
Is Bill Kalsow around?Or the other original authors?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.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20071129/3bfa5009/attachment-0001.html>