🚀 go-pugleaf

I have been comparing some of the code gcc generates with what
/lib/c2 uses.  Here are a few things I caught:

------------
code is
	a &= ~(1 << b())
gcc produces
	ashl r0,$1,r0
	mcoml r0,r0
	mcoml _a,r1
	bicl3 r1,r0,_a
which is more simply
	ashl r0,$1,r0
	bicl2 r1,_a
------------
code is
	struct { ... short a; ... } *p;
	... p->a & 0xff ...
gcc produces
	movw 30(r1),r4
	bicl3 $-256,r4,r1
which is more simply
	movzbl 30(r1),r1
although the latter does a byte reference rather than a longword.
If nothing else, the sequence should be movw+movzbl.
------------
code is something complex
gcc produces
	movl -4(fp),r2
	bitl *40(r10)[r2],$-2147483648
	jeql Lxxx
	movl -4(fp),36(r10)
which is more simply
	movl -4(fp),r2
	bitl *40(r10)[r2],$-2147483648
	jeql Lxxx
	movl r2,36(r10)
That is, it seems to have forgotten that it already has -4(fp) in r2.
[incidentally, why not `jbc $31,*40(r10)[r2]', while we are at it?]
------------
code is
	f() { int b; g(&b); }
gcc produces
	subl3	$4,fp,-(sp)
which is more simply
	mova[bwl] 4(fp),-(sp)
------------
code is
	f(volatile int a) { if (a & 1) g(); }
gcc produces
	jbc	$0,4(ap),Lxxx
which is more simply
	jlbc	4(ap),Lxxx
Note that the latter does a longword reference; the former is
technically incorrect, although gcc does the right thing if the
situation is really such that a could be in I/O space.  (It would
be valid to use jlbc on a volatile int.)

Chris