[M3commit] CVS Update: cm3

[Jay K]

> mostly resolve the double shift source vs. dest problem


Clarification, I don't know of any bug here, just that 

 - the code looked wrong but acted right  

 - the debug output was probably wrong and definitely a little bit missing (I'm sure nobody ever runs cm3 -debug

   and looks at NT386/foo.molog, but I've been doing that a lot lately, it is similar

   to cm3cg -y, but shows the generated code as well, interleaved).

 

 

The actual generated code seemed ok, based on stuff in m3-sys/m3tests.

"mostly resolve" as in, the code reads more sensibly now, though

there is too much code duplication, build_modrm isn't as useful as it should be..

 

Also "double shift" doesn't mean "extra shift", but "double precision shift" -- 64bit shift.

x86 has the instructions shld and shrd, shift left double, shift right double.

You shift a register "into" another a register, instead of shifting in zeros or sign bits.

 

 - Jay
 
> Date: Sun, 28 Feb 2010 00:52:38 +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/02/28 00:52:37
> 
> Modified files:
> cm3/m3-sys/m3back/src/: Codex86.m3 M3x86.m3 M3x86Rep.i3 
> Stackx86.m3 
> 
> Log message:
> mostly resolve the double shift source vs. dest problem
> the underlying helper function sometimes reverses dest and src, in the
> interest of getting reg, mem
> These helper functions need cleanup and unification.
> build_modrm, load_like_helper, etc.
> 
> abtract out some assumptions of 32bit sizes to be type-based
> so that we might inline some shift/insert/extract
> no actual bug here, only 32bit types get here currently, the
> rest generate function calls
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20100227/966f8fb7/attachment-0002.html>