[M3commit] CVS Update: cm3
Jay K
jay.krell at cornell.edu
Mon Mar 15 16:15:12 CET 2010
diff attached, it is pretty simple
> Date: Mon, 15 Mar 2010 16:06:35 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
>
> CVSROOT: /usr/cvs
> Changes by: jkrell at birch. 10/03/15 16:06:35
>
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3
> Stackx86.m3
>
> Log message:
> Remove from one to three instructions from small functions.
> By tracking which non-volatile registers are used and only saving/restoring them.
> Unfortunately, until we are more sophisticated, we have to pay for the size
> for the push instructions, but we nop them out if they aren't needed,
> and only generating the needed pops. (We should look into two and three
> byte nops, but presently I just use one byte nops. The pushes are each
> one instruction. Theoretically, nop is faster than push, though I should check.
> Plus, nop saves us from doing a pop.)
>
> Also a much cleaner fix to the backup(5) vs. patch fix from before. No downside now.
>
> Register allocator should probably favor volatile registers over non-volatile.
> Even a simple PROCEDURE F(a,b:INTEGER) = BEGIN a:=b END F uses ebx. (see test p234, not commited yet)
>
> I noticed an ancient bug in doing this work.
> Functions with >4K frames need to call chkstk or equivalent.
> Specifically, stack pages must be touched in order. call naturally
> touches a page. Or, side motivation: match what the C compiler does. It is correct.
> (See, we also reserve room for sub esp,foo, for 32bit foo, even
> though many functions save save 3 bytes and use an 8bit value and
> some unusual functions can skip the entire thing (if foo = 0))
>
> We can issue errors for such functions and see if any turn up.
>
> See test case p234 (not commited yet).
>
> Use of the new proc_reguse is sprinkled in a bit unnecessarily much here.
> corrupt, set_reg, movop1, load_ind should suffice.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100315/d9f3d25c/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 1.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100315/d9f3d25c/attachment-0002.txt>
More information about the M3commit
mailing list