x86 backend update

[Matthew Fluet]

> Sorry to be dense, but what is the notion behind using
> 	MEM(l)[???]
> for access to memory at location ??? (is that right)?  Ah, is the (l) for the
> size of the memory operand?
> In the actual implementation, it might be worth burning a register to point
> to the base of the block of memory used for the pseudo-registers.  The code
> generator would know that this doesn't alias any other memory.


Right, MEM(s)[X] indicates the contents of memory at location X, of size s.  
Again, I'm following Intel "syntax" in calling a 4 byte quantity a "long."
Obviously, this isn't anything that the assembler accepts, but it's a
useful abstraction because I can do equality checks on memory locations.

In the actual implementation, I'm hoping not to have to use a register to
point to the base of the pseudo-registers.  At compile time, we'll know
how many of each type of pseudo-register is needed.  So, if we determine
that we'll need 5 integer pseudo registers, I'll dump out

.data                  | Or, for a slightly smaller executable, we can
localI:                | allocate in the .bss section with
	.long 0        |
	.long 0        | .lcomm localI, (5*4)
	.long 0        |
	.long 0        | or something similar.
	.long 0        |
                       |
Then, 

RI(2) = Int_add(RI(1),5)

becomes

movl MEM(l)[(localI+(1*4))],MEM(l)[(localI+(2*4))]
addl $5,MEM(l)[(localI+(2*4))]

becomes

movl (localI+(1*4)),%eax
addl $5,%eax
movl %eax,(localI+(2*4))

or something similar depending on how registers are allocated. The
assembler/linker will resolve (localI+(1*4)) into an absolute memory
address.