|C Compilers which use full 486 capabilities firstname.lastname@example.org (Mick Carrick) (1991-03-13)|
|Re: C Compilers which use full 486 capabilities email@example.com (1991-03-15)|
|Re: C Compilers which use full 486 capabilities firstname.lastname@example.org (1991-03-15)|
|Re: C Compilers which use full 486 capabilities email@example.com (1991-03-16)|
|Re: C Compilers which use full 486 capabilities rex@aussie.COM (1991-03-17)|
|Re: C Compilers which use full 486 capabilities firstname.lastname@example.org (1991-03-18)|
|Re: C Compilers which use full 486 capabilities email@example.com (1991-03-19)|
|In-Reply-To:||firstname.lastname@example.org's message of 15 Mar 91 17:35:51 GMT|
|Keywords:||486, C, optimize|
|Date:||Sat, 16 Mar 91 18:05:01 -0500|
| [WRT the rather slow 486 XCHG instruction]
| Does anyone's compiler generate an exchange instruction? I can visualize
| uses, but I'm not sure how I'd recognize it. I can imagine peephole
| optimizers that could catch it, but generally, I dislike instructions with
| more than 1 result.
| How would it integrate with register allocation?
When I started working on the 88k code generator for the GNU C
compiler at Data General, it supported the xmem and xmem.bu
instructions through peepholes. The peephole checked for:
reg1 <- memory1
reg2 <- memory2
memory1 <- reg2
memory2 <- reg1
and converted it into the appropriate xmem instruction. The code
wasn't safe, in that it should have made sure reg1 and reg2 were dead
after the peephole, but it could have been made safe with an
appropriate check. This peephole did optimize the sort subtest in the
Stanford benchmarks. I eventually removed it, when we ran the
compiler on an actual 88k, and compared the times to another compiler.
The sort benchmark was an anomaly, in that ran much slower for GCC
compared to the other compiler. The reason of course is that xmem on
an 88k has to synchonize the machine before continuing.
Return to the
Search the comp.compilers archives again.